https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 16:21:53 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-07853 bdu:2025-07853 https://cve.radiocsirt.org/vuln/bdu:2025-07853 https://cve.radiocsirt.org/vuln/bell-cve-2024-56685 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-56685 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152 certfr-2025-avi-0152 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152 https://cve.radiocsirt.org/vuln/euvd-2026-313802 EUVD-2026-313802 https://cve.radiocsirt.org/vuln/euvd-2026-313802 https://cve.radiocsirt.org/vuln/fkie_cve-2024-56685 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe</p> <p>Following commit 13f58267cda3 (&#34;ASoC: soc.h: don&#39;t create dummy Component via COMP_DUMMY()&#34;), 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&#39;s probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior.</p> <p>This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card&#39;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.</p> <p>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.</p> <p>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 = &#34;snd-soc-dummy-dai&#34;. In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs&#39; fields but still check for the codec&#39;s dai name against &#34;snd-soc-dummy-dai&#34; as needed.</p> <p>While at it, also drop the check that dai_name is not null in the mt8…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe</p> <p>Following commit 13f58267cda3 (&#34;ASoC: soc.h: don&#39;t create dummy Component via COMP_DUMMY()&#34;), 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&#39;s probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior.</p> <p>This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card&#39;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.</p> <p>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.</p> <p>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 = &#34;snd-soc-dummy-dai&#34;. In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs&#39; fields but still check for the codec&#39;s dai name against &#34;snd-soc-dummy-dai&#34; as needed.</p> <p>While at it, also drop the check that dai_name is not null in the mt8…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-56685 https://cve.radiocsirt.org/vuln/ghsa-54qc-m2ph-jw4r <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe</p> <p>Following commit 13f58267cda3 (&#34;ASoC: soc.h: don&#39;t create dummy Component via COMP_DUMMY()&#34;), 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&#39;s probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior.</p> <p>This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card&#39;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.</p> <p>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.</p> <p>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 = &#34;snd-soc-dummy-dai&#34;. In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs&#39; fields but still check for the codec&#39;s dai name against &#34;snd-soc-dummy-dai&#34; as needed.</p> <p>While at it, also drop the check that dai_name is not null in the mt8…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe</p> <p>Following commit 13f58267cda3 (&#34;ASoC: soc.h: don&#39;t create dummy Component via COMP_DUMMY()&#34;), 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&#39;s probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior.</p> <p>This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card&#39;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.</p> <p>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.</p> <p>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 = &#34;snd-soc-dummy-dai&#34;. In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs&#39; fields but still check for the codec&#39;s dai name against &#34;snd-soc-dummy-dai&#34; as needed.</p> <p>While at it, also drop the check that dai_name is not null in the mt8…</p> https://cve.radiocsirt.org/vuln/ghsa-54qc-m2ph-jw4r https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-56685 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 104 more</p> <p>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 (&#34;ASoC: soc.h: don&#39;t create dummy Component via COMP_DUMMY()&#34;), 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&#39;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&#39;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 = &#34;snd-soc-dummy-dai&#34;. In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs&#39; fields but still check for the codec&#39;s dai name against &#34;snd-soc-dummy-dai&#34; as needed. While at it, also drop the check that dai_name is not null in the mt8192 dr…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 104 more</p> <p>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 (&#34;ASoC: soc.h: don&#39;t create dummy Component via COMP_DUMMY()&#34;), 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&#39;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&#39;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 = &#34;snd-soc-dummy-dai&#34;. In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs&#39; fields but still check for the codec&#39;s dai name against &#34;snd-soc-dummy-dai&#34; as needed. While at it, also drop the check that dai_name is not null in the mt8192 dr…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-56685 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3762 <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht näher beschriebene Effekte zu erzielen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht näher beschriebene Effekte zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3762