linux-cve-announce - CVE-2025-37889: ASoC: ops: Consistently treat platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025051039-CVE-2025-37889-f248@gregkh>
Date: Sat, 10 May 2025 16:08:40 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-37889: ASoC: ops: Consistently treat platform_max as control value

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2025-37889 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.15.148 with commit c11fc224e58e7972ffd05b8f25e9b1d6a0b8d562 and fixed in 5.15.180 with commit c402f184a053c8e7ca325e50f04bbbc1e4fee019
	Issue introduced in 6.1.74 with commit a50562146d6c7650029a115c96ef9aaa7648c344 and fixed in 6.1.132 with commit 694110bc2407a61f02a770cbb5f39b51e4ec77c6
	Issue introduced in 6.6.7 with commit 395e52b7a1ad01e1b51adb09854a0aa5347428de and fixed in 6.6.84 with commit 544055329560d4b64fe204fc6be325ebc24c72ca
	Issue introduced in 6.7 with commit fb9ad24485087e0f00d84bee7a5914640b2b9024 and fixed in 6.12.20 with commit a46a9371f8b9a0eeff53a21e11ed3b65f52d9cf6
	Issue introduced in 6.7 with commit fb9ad24485087e0f00d84bee7a5914640b2b9024 and fixed in 6.13.8 with commit 296c8295ae34045da0214882628d49c1c060dd8a
	Issue introduced in 6.7 with commit fb9ad24485087e0f00d84bee7a5914640b2b9024 and fixed in 6.14 with commit 0eba2a7e858907a746ba69cd002eb9eb4dbd7bf3

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-37889
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	include/sound/soc.h
	sound/soc/soc-ops.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/c402f184a053c8e7ca325e50f04bbbc1e4fee019
	https://git.kernel.org/stable/c/694110bc2407a61f02a770cbb5f39b51e4ec77c6
	https://git.kernel.org/stable/c/544055329560d4b64fe204fc6be325ebc24c72ca
	https://git.kernel.org/stable/c/a46a9371f8b9a0eeff53a21e11ed3b65f52d9cf6
	https://git.kernel.org/stable/c/296c8295ae34045da0214882628d49c1c060dd8a
	https://git.kernel.org/stable/c/0eba2a7e858907a746ba69cd002eb9eb4dbd7bf3