Описание
In the Linux kernel, the following vulnerability has been resolved:
PCI/MSI: Handle the NOMASK flag correctly for all PCI/MSI backends
The conversion of the XEN specific global variable pci_msi_ignore_mask to a MSI domain flag, missed the facts that:
Both cases result in an unconditional NULL pointer dereference. This was unfortunatly missed in review and testing revealed it late.
Cure this by using the existing pci_msi_domain_supports() helper, which handles all possible cases correctly.
In the Linux kernel, the following vulnerability has been resolved:
PCI/MSI: Handle the NOMASK flag correctly for all PCI/MSI backends
The conversion of the XEN specific global variable pci_msi_ignore_mask to a MSI domain flag, missed the facts that:
Both cases result in an unconditional NULL pointer dereference. This was unfortunatly missed in review and testing revealed it late.
Cure this by using the existing pci_msi_domain_supports() helper, which handles all possible cases correctly.
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2025-37889
- https://git.kernel.org/stable/c/0eba2a7e858907a746ba69cd002eb9eb4dbd7bf3
- https://git.kernel.org/stable/c/296c8295ae34045da0214882628d49c1c060dd8a
- https://git.kernel.org/stable/c/2e3ad60b8f72a95e3a32ddd9d70ea129aa3fcfb7
- https://git.kernel.org/stable/c/3ece3e8e5976c49c3f887e5923f998eabd54ff40
- https://git.kernel.org/stable/c/46d357520934eef99fa121889f8ebbf46a6eddb8
- https://git.kernel.org/stable/c/544055329560d4b64fe204fc6be325ebc24c72ca
- https://git.kernel.org/stable/c/694110bc2407a61f02a770cbb5f39b51e4ec77c6
- https://git.kernel.org/stable/c/a46a9371f8b9a0eeff53a21e11ed3b65f52d9cf6
- https://git.kernel.org/stable/c/c402f184a053c8e7ca325e50f04bbbc1e4fee019
EPSS
CVE ID
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation m...
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation make...
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation make
In the Linux kernel, the following vulnerability has been resolved: A ...
EPSS