<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 09:29:30 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-10369</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-10369</link>
      <description>bdu:2024-10369</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-10369</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52736</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-52736</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-52736</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0496 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</link>
      <description>certfr-2024-avi-0496</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</guid>
    </item>
    <item>
      <title>EUVD-2026-311650</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311650</link>
      <description>EUVD-2026-311650</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311650</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52736</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52736</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: hda: Do not unset preset when cleaning up codec&lt;/p&gt;
&lt;p&gt;Several functions that take part in codec&amp;#39;s initialization and removal
are re-used by ASoC codec drivers implementations. Drivers mimic the
behavior of hda_codec_driver_probe/remove() found in
sound/pci/hda/hda_bind.c with their component-&amp;gt;probe/remove() instead.&lt;/p&gt;
&lt;p&gt;One of the reasons for that is the expectation of
snd_hda_codec_device_new() to receive a valid pointer to an instance of
struct snd_card. This expectation can be met only once sound card
components probing commences.&lt;/p&gt;
&lt;p&gt;As ASoC sound card may be unbound without codec device being actually
removed from the system, unsetting -&amp;gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&amp;gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver&amp;#39;s module reloading may
occur several times throughout the lifetime of an audio stack.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: hda: Do not unset preset when cleaning up codec&lt;/p&gt;
&lt;p&gt;Several functions that take part in codec&amp;#39;s initialization and removal
are re-used by ASoC codec drivers implementations. Drivers mimic the
behavior of hda_codec_driver_probe/remove() found in
sound/pci/hda/hda_bind.c with their component-&amp;gt;probe/remove() instead.&lt;/p&gt;
&lt;p&gt;One of the reasons for that is the expectation of
snd_hda_codec_device_new() to receive a valid pointer to an instance of
struct snd_card. This expectation can be met only once sound card
components probing commences.&lt;/p&gt;
&lt;p&gt;As ASoC sound card may be unbound without codec device being actually
removed from the system, unsetting -&amp;gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&amp;gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver&amp;#39;s module reloading may
occur several times throughout the lifetime of an audio stack.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-52736</guid>
    </item>
    <item>
      <title>GHSA-gpvh-jcjq-x69v</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gpvh-jcjq-x69v</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: hda: Do not unset preset when cleaning up codec&lt;/p&gt;
&lt;p&gt;Several functions that take part in codec&amp;#39;s initialization and removal
are re-used by ASoC codec drivers implementations. Drivers mimic the
behavior of hda_codec_driver_probe/remove() found in
sound/pci/hda/hda_bind.c with their component-&amp;gt;probe/remove() instead.&lt;/p&gt;
&lt;p&gt;One of the reasons for that is the expectation of
snd_hda_codec_device_new() to receive a valid pointer to an instance of
struct snd_card. This expectation can be met only once sound card
components probing commences.&lt;/p&gt;
&lt;p&gt;As ASoC sound card may be unbound without codec device being actually
removed from the system, unsetting -&amp;gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&amp;gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver&amp;#39;s module reloading may
occur several times throughout the lifetime of an audio stack.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: hda: Do not unset preset when cleaning up codec&lt;/p&gt;
&lt;p&gt;Several functions that take part in codec&amp;#39;s initialization and removal
are re-used by ASoC codec drivers implementations. Drivers mimic the
behavior of hda_codec_driver_probe/remove() found in
sound/pci/hda/hda_bind.c with their component-&amp;gt;probe/remove() instead.&lt;/p&gt;
&lt;p&gt;One of the reasons for that is the expectation of
snd_hda_codec_device_new() to receive a valid pointer to an instance of
struct snd_card. This expectation can be met only once sound card
components probing commences.&lt;/p&gt;
&lt;p&gt;As ASoC sound card may be unbound without codec device being actually
removed from the system, unsetting -&amp;gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&amp;gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver&amp;#39;s module reloading may
occur several times throughout the lifetime of an audio stack.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gpvh-jcjq-x69v</guid>
    </item>
    <item>
      <title>OESA-2024-1693 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1693</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
mptcp: ensure tx skbs always have the MPTCP ext&#13;
&#13;
Due to signed/unsigned comparison, the expression:&#13;
&#13;
	info-&amp;amp;gt;size_goal - skb-&amp;amp;gt;len &amp;amp;gt; 0&#13;
&#13;
evaluates to true when the size goal is smaller than the
skb size. That results in lack of tx cache refill, so that
the skb allocated by the core TCP code lacks the required
MPTCP skb extensions.&#13;
&#13;
Due to the above, syzbot is able to trigger the following WARN_ON():&#13;
&#13;
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Modules linked in:
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 &amp;amp;lt;0f&amp;amp;gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
mptcp: ensure tx skbs always have the MPTCP ext&#13;
&#13;
Due to signed/unsigned comparison, the expression:&#13;
&#13;
	info-&amp;amp;gt;size_goal - skb-&amp;amp;gt;len &amp;amp;gt; 0&#13;
&#13;
evaluates to true when the size goal is smaller than the
skb size. That results in lack of tx cache refill, so that
the skb allocated by the core TCP code lacks the required
MPTCP skb extensions.&#13;
&#13;
Due to the above, syzbot is able to trigger the following WARN_ON():&#13;
&#13;
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Modules linked in:
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 &amp;amp;lt;0f&amp;amp;gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1693</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2008-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2008-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:2008-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52736</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52736</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 138 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Do not unset preset when cleaning up codec Several functions that take part in codec&amp;#39;s initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component-&amp;gt;probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting -&amp;gt;preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -&amp;gt; load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver&amp;#39;s module reloading may occur several times throughout the lifetime of an audio stack.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 138 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Do not unset preset when cleaning up codec Several functions that take part in codec&amp;#39;s initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component-&amp;gt;probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting -&amp;gt;preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -&amp;gt; load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver&amp;#39;s module reloading may occur several times throughout the lifetime of an audio stack.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52736</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1197 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1197</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder unspezifische Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder unspezifische Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1197</guid>
    </item>
  </channel>
</rss>
