<?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 08:16:32 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-03659</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-03659</link>
      <description>bdu:2024-03659</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-03659</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-26635</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-26635</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-26635</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0381 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;le noyau Linux de Debian&lt;/span&gt;. Elles permet…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0381</link>
      <description>certfr-2024-avi-0381</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0381</guid>
    </item>
    <item>
      <title>EUVD-2026-312519</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312519</link>
      <description>EUVD-2026-312519</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312519</guid>
    </item>
    <item>
      <title>fkie_cve-2024-26635</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-26635</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;llc: Drop support for ETH_P_TR_802_2.&lt;/p&gt;
&lt;p&gt;syzbot reported an uninit-value bug below. [0]&lt;/p&gt;
&lt;p&gt;llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.&lt;/p&gt;
&lt;p&gt;write$tun(r0, &amp;amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, &amp;#34;90e5dd&amp;#34;}}}}, 0x16)&lt;/p&gt;
&lt;p&gt;llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().&lt;/p&gt;
&lt;p&gt;However, the initialisation is done only when skb-&amp;gt;protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.&lt;/p&gt;
&lt;p&gt;The missing initialisation existed prior to commit 211ed865108e
(&amp;#34;net: delete all instances of special processing for token ring&amp;#34;).&lt;/p&gt;
&lt;p&gt;It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation.&lt;/p&gt;
&lt;p&gt;[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
 __llc_lookup_established+0xe9d/0xf90
 __llc_lookup net/llc/llc_conn.c:611 [inline]
 llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
 netif_receive_skb_internal net/core/dev.c:5727 [inline]
 netif_re…&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;llc: Drop support for ETH_P_TR_802_2.&lt;/p&gt;
&lt;p&gt;syzbot reported an uninit-value bug below. [0]&lt;/p&gt;
&lt;p&gt;llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.&lt;/p&gt;
&lt;p&gt;write$tun(r0, &amp;amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, &amp;#34;90e5dd&amp;#34;}}}}, 0x16)&lt;/p&gt;
&lt;p&gt;llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().&lt;/p&gt;
&lt;p&gt;However, the initialisation is done only when skb-&amp;gt;protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.&lt;/p&gt;
&lt;p&gt;The missing initialisation existed prior to commit 211ed865108e
(&amp;#34;net: delete all instances of special processing for token ring&amp;#34;).&lt;/p&gt;
&lt;p&gt;It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation.&lt;/p&gt;
&lt;p&gt;[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
 __llc_lookup_established+0xe9d/0xf90
 __llc_lookup net/llc/llc_conn.c:611 [inline]
 llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
 netif_receive_skb_internal net/core/dev.c:5727 [inline]
 netif_re…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-26635</guid>
    </item>
    <item>
      <title>GHSA-xhm6-wpwj-qm56</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xhm6-wpwj-qm56</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;llc: Drop support for ETH_P_TR_802_2.&lt;/p&gt;
&lt;p&gt;syzbot reported an uninit-value bug below. [0]&lt;/p&gt;
&lt;p&gt;llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.&lt;/p&gt;
&lt;p&gt;write$tun(r0, &amp;amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, &amp;#34;90e5dd&amp;#34;}}}}, 0x16)&lt;/p&gt;
&lt;p&gt;llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().&lt;/p&gt;
&lt;p&gt;However, the initialisation is done only when skb-&amp;gt;protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.&lt;/p&gt;
&lt;p&gt;The missing initialisation existed prior to commit 211ed865108e
(&amp;#34;net: delete all instances of special processing for token ring&amp;#34;).&lt;/p&gt;
&lt;p&gt;It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation.&lt;/p&gt;
&lt;p&gt;[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
 __llc_lookup_established+0xe9d/0xf90
 __llc_lookup net/llc/llc_conn.c:611 [inline]
 llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
 netif_receive_skb_internal net/core/dev.c:5727 [inline]
 netif_re…&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;llc: Drop support for ETH_P_TR_802_2.&lt;/p&gt;
&lt;p&gt;syzbot reported an uninit-value bug below. [0]&lt;/p&gt;
&lt;p&gt;llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.&lt;/p&gt;
&lt;p&gt;write$tun(r0, &amp;amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, &amp;#34;90e5dd&amp;#34;}}}}, 0x16)&lt;/p&gt;
&lt;p&gt;llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().&lt;/p&gt;
&lt;p&gt;However, the initialisation is done only when skb-&amp;gt;protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.&lt;/p&gt;
&lt;p&gt;The missing initialisation existed prior to commit 211ed865108e
(&amp;#34;net: delete all instances of special processing for token ring&amp;#34;).&lt;/p&gt;
&lt;p&gt;It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation.&lt;/p&gt;
&lt;p&gt;[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
 __llc_lookup_established+0xe9d/0xf90
 __llc_lookup net/llc/llc_conn.c:611 [inline]
 llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
 netif_receive_skb_internal net/core/dev.c:5727 [inline]
 netif_re…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xhm6-wpwj-qm56</guid>
    </item>
    <item>
      <title>gsd-2024-26635</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2024-26635</link>
      <description>gsd-2024-26635</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2024-26635</guid>
    </item>
    <item>
      <title>ICSA-25-226-15 — Siemens SINEC OS</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-25-226-15</link>
      <description>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-25-226-15</guid>
    </item>
    <item>
      <title>OESA-2024-1566 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1566</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;
scsi: core: Fix scsi_mode_sense() buffer length handling&#13;
&#13;
Several problems exist with scsi_mode_sense() buffer length handling:&#13;
&#13;
 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.&#13;
&#13;
 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&amp;amp;gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.&#13;
&#13;
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.&#13;
&#13;
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&amp;amp;gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.&#13;
&#13;
While at it, also fix the folowing:&#13;
&#13;
 *…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;
scsi: core: Fix scsi_mode_sense() buffer length handling&#13;
&#13;
Several problems exist with scsi_mode_sense() buffer length handling:&#13;
&#13;
 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.&#13;
&#13;
 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&amp;amp;gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.&#13;
&#13;
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.&#13;
&#13;
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&amp;amp;gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.&#13;
&#13;
While at it, also fix the folowing:&#13;
&#13;
 *…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1566</guid>
    </item>
    <item>
      <title>SSA-613116 — SSA-613116: Multiple Vulnerabilities in Third-Party Components in SINEC OS before V3.1</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-613116</link>
      <description>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;firmware: arm_scmi: Harden accesses to the reset domains&lt;/p&gt;
&lt;p&gt;Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.&lt;/p&gt;
&lt;p&gt;Add an internal consistency check before any such domains descriptors
accesses. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: lgdt3306a: Add a check against null-pointer-def&lt;/p&gt;
&lt;p&gt;The driver should check whether the client provides the platform_data.&lt;/p&gt;
&lt;p&gt;The following log reveals it:&lt;/p&gt;
&lt;p&gt;[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;lt;TASK&amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netfilter:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-613116</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2493-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2493-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:2493-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-26635</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26635</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, 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 159 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug.   write$tun(r0, &amp;amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, &amp;#34;90e5dd&amp;#34;}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb-&amp;gt;protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e (&amp;#34;net: delete all instances of special processing for token ring&amp;#34;). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90  __llc_lookup_established+0xe9d/0xf90  __llc_lookup net/llc/llc_conn.c:611 [inline]  llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791  llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206  __netif_receive_skb_one_core net/core/dev.c:5527 [inline]  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641  netif_receive_skb_internal net/core/dev.c:5727 [inline]  netif_receive_skb+…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, 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 159 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug.   write$tun(r0, &amp;amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, &amp;#34;90e5dd&amp;#34;}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb-&amp;gt;protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e (&amp;#34;net: delete all instances of special processing for token ring&amp;#34;). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90  __llc_lookup_established+0xe9d/0xf90  __llc_lookup net/llc/llc_conn.c:611 [inline]  llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791  llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206  __netif_receive_skb_one_core net/core/dev.c:5527 [inline]  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641  netif_receive_skb_internal net/core/dev.c:5727 [inline]  netif_receive_skb+…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26635</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0654 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0654</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff 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 herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0654</guid>
    </item>
  </channel>
</rss>
