CVE-2024-56685

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe<br /> <br /> Following commit 13f58267cda3 ("ASoC: soc.h: don&amp;#39;t create dummy<br /> Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero<br /> length, and only gets populated with the dummy struct after the card is<br /> registered. Since the sound card driver&amp;#39;s probe happens before the card<br /> registration, accessing any of the members of a dummy component during<br /> probe will result in undefined behavior.<br /> <br /> This can be observed in the mt8188 and mt8195 machine sound drivers. By<br /> omitting a dai link subnode in the sound card&amp;#39;s node in the Devicetree,<br /> the default uninitialized dummy codec is used, and when its dai_name<br /> pointer gets passed to strcmp() it results in a null pointer dereference<br /> and a kernel panic.<br /> <br /> In addition to that, set_card_codec_info() in the generic helpers file,<br /> mtk-soundcard-driver.c, will populate a dai link with a dummy codec when<br /> a dai link node is present in DT but with no codec property.<br /> <br /> The result is that at probe time, a dummy codec can either be<br /> uninitialized with num_codecs = 0, or be an initialized dummy codec,<br /> with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to<br /> accommodate for both situations, check that num_codecs is not zero<br /> before accessing the codecs&amp;#39; fields but still check for the codec&amp;#39;s dai<br /> name against "snd-soc-dummy-dai" as needed.<br /> <br /> While at it, also drop the check that dai_name is not null in the mt8192<br /> driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192:<br /> Check existence of dai_name before dereferencing"), as it is actually<br /> redundant given the preceding num_codecs != 0 check.