Message-ID: <2024122833-CVE-2024-56685-f49e@gregkh>
Date: Sat, 28 Dec 2024 10:45:37 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-56685: ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe

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

In the Linux kernel, the following vulnerability has been resolved:

ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe

Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy
Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero
length, and only gets populated with the dummy struct after the card is
registered. Since the sound card driver's probe happens before the card
registration, accessing any of the members of a dummy component during
probe will result in undefined behavior.

This can be observed in the mt8188 and mt8195 machine sound drivers. By
omitting a dai link subnode in the sound card's node in the Devicetree,
the default uninitialized dummy codec is used, and when its dai_name
pointer gets passed to strcmp() it results in a null pointer dereference
and a kernel panic.

In addition to that, set_card_codec_info() in the generic helpers file,
mtk-soundcard-driver.c, will populate a dai link with a dummy codec when
a dai link node is present in DT but with no codec property.

The result is that at probe time, a dummy codec can either be
uninitialized with num_codecs = 0, or be an initialized dummy codec,
with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to
accommodate for both situations, check that num_codecs is not zero
before accessing the codecs' fields but still check for the codec's dai
name against "snd-soc-dummy-dai" as needed.

While at it, also drop the check that dai_name is not null in the mt8192
driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192:
Check existence of dai_name before dereferencing"), as it is actually
redundant given the preceding num_codecs != 0 check.

The Linux kernel CVE team has assigned CVE-2024-56685 to this issue.


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

	Issue introduced in 6.8 with commit 13f58267cda3d6946c8f4de368ad5d4a003baa61 and fixed in 6.11.11 with commit 376f4800f34a28def026ff5c5d4fc5e54e1744ff
	Issue introduced in 6.8 with commit 13f58267cda3d6946c8f4de368ad5d4a003baa61 and fixed in 6.12.2 with commit 550279449ff54c5aa28cfca5c567308cbfb145f0
	Issue introduced in 6.8 with commit 13f58267cda3d6946c8f4de368ad5d4a003baa61 and fixed in 6.13-rc1 with commit 2f2020327cc8561d7c520d2f2d9acea84fa7b3a3

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-2024-56685
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:
	sound/soc/mediatek/mt8188/mt8188-mt6359.c
	sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c
	sound/soc/mediatek/mt8195/mt8195-mt6359.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/376f4800f34a28def026ff5c5d4fc5e54e1744ff
	https://git.kernel.org/stable/c/550279449ff54c5aa28cfca5c567308cbfb145f0
	https://git.kernel.org/stable/c/2f2020327cc8561d7c520d2f2d9acea84fa7b3a3

Powered by blists - more mailing lists