CVE-2025-37889

  1. OpenCVE
  2. Vulnerabilities (CVE)
  3. CVE-2025-37889
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 makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max. Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches.
CVSS

No CVSS.

References
Link Resource
https://git.kernel.org/stable/c/0eba2a7e858907a746ba69cd002eb9eb4dbd7bf3
https://git.kernel.org/stable/c/296c8295ae34045da0214882628d49c1c060dd8a
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
Configurations

No configuration.

History

10 May 2025, 15:15

Type Values Removed Values Added
References
  • {'url': 'https://git.kernel.org/stable/c/2e3ad60b8f72a95e3a32ddd9d70ea129aa3fcfb7', 'source': '416baaa9-dc9f-4396-8d5f-8c081fb06d67'}
  • {'url': 'https://git.kernel.org/stable/c/3ece3e8e5976c49c3f887e5923f998eabd54ff40', 'source': '416baaa9-dc9f-4396-8d5f-8c081fb06d67'}
  • {'url': 'https://git.kernel.org/stable/c/46d357520934eef99fa121889f8ebbf46a6eddb8', 'source': '416baaa9-dc9f-4396-8d5f-8c081fb06d67'}
  • () https://git.kernel.org/stable/c/0eba2a7e858907a746ba69cd002eb9eb4dbd7bf3 -
  • () https://git.kernel.org/stable/c/296c8295ae34045da0214882628d49c1c060dd8a -
  • () 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 -
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/MSI: Manejo correcto del indicador NOMASK para todos los backends PCI/MSI. La conversión de la variable global específica de XEN pci_msi_ignore_mask a un indicador de dominio MSI pasó por alto los siguientes hechos: 1) Las arquitecturas heredadas no proporcionan un dominio de interrupción. 2) Los dominios MSI principales no necesariamente tienen información de dominio adjunta. Ambos casos resultan en una desreferencia de puntero NULL incondicional. Desafortunadamente, esto se pasó por alto en la revisión y las pruebas lo revelaron tarde. Solucione esto utilizando el asistente pci_msi_domain_supports() existente, que maneja todos los casos posibles correctamente.
Summary (en) 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: 1) Legacy architectures do not provide a interrupt domain 2) Parent MSI domains do not necessarily have a domain info attached 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. (en) 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 makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max. Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches.

09 May 2025, 07:16

Type Values Removed Values Added
New CVE
Information

Published : 2025-05-09 07:16

Updated : 2025-05-12 17:32

NVD link : CVE-2025-37889

Mitre link : CVE-2025-37889

CVE.ORG link : CVE-2025-37889

JSON object : View

Products Affected

No product.

CWE

No CWE.