<?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 18:52:04 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-10738</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-10738</link>
      <description>bdu:2024-10738</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-10738</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-38582</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-38582</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-38582</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0527 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0527</link>
      <description>certfr-2024-avi-0527</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0527</guid>
    </item>
    <item>
      <title>EUVD-2026-320624</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320624</link>
      <description>EUVD-2026-320624</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320624</guid>
    </item>
    <item>
      <title>fkie_cve-2024-38582</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-38582</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nilfs2: fix potential hang in nilfs_detach_log_writer()&lt;/p&gt;
&lt;p&gt;Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.&lt;/p&gt;
&lt;p&gt;Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:&lt;/p&gt;
&lt;p&gt;nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&amp;gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&amp;gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***&lt;/p&gt;
&lt;p&gt;Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.&lt;/p&gt;
&lt;p&gt;The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().&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;nilfs2: fix potential hang in nilfs_detach_log_writer()&lt;/p&gt;
&lt;p&gt;Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.&lt;/p&gt;
&lt;p&gt;Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:&lt;/p&gt;
&lt;p&gt;nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&amp;gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&amp;gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***&lt;/p&gt;
&lt;p&gt;Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.&lt;/p&gt;
&lt;p&gt;The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-38582</guid>
    </item>
    <item>
      <title>GHSA-g9c8-phh2-8fqc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g9c8-phh2-8fqc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nilfs2: fix potential hang in nilfs_detach_log_writer()&lt;/p&gt;
&lt;p&gt;Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.&lt;/p&gt;
&lt;p&gt;Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:&lt;/p&gt;
&lt;p&gt;nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&amp;gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&amp;gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***&lt;/p&gt;
&lt;p&gt;Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.&lt;/p&gt;
&lt;p&gt;The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().&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;nilfs2: fix potential hang in nilfs_detach_log_writer()&lt;/p&gt;
&lt;p&gt;Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.&lt;/p&gt;
&lt;p&gt;Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:&lt;/p&gt;
&lt;p&gt;nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&amp;gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&amp;gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***&lt;/p&gt;
&lt;p&gt;Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.&lt;/p&gt;
&lt;p&gt;The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g9c8-phh2-8fqc</guid>
    </item>
    <item>
      <title>OESA-2024-1835 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1835</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
usb: fix various gadgets null ptr deref on 10gbps cabling.&#13;
&#13;
This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps.(CVE-2021-47270)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
seg6: fix the iif in the IPv6 socket control block&#13;
&#13;
When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving
interface index into the IPv4 socket control block (v5.16-rc4,
net/ipv4/ip_input.c line 510):&#13;
&#13;
    IPCB(skb)-&amp;amp;gt;iif = skb-&amp;amp;gt;skb_iif;&#13;
&#13;
If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH
header, the seg6_do_srh_encap(...) performs the required encapsulation.
In this case, the seg6_do_srh_encap function clears the IPv6 socket control
block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):&#13;
&#13;
    memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));&#13;
&#13;
The memset(...) was introduced in commit ef489749aae5 (&amp;amp;quot;ipv6: sr: clear
IP6CB(skb) on SRH ip4ip6 encapsulation&amp;amp;quot;) a long time ago (2019-01-29).&#13;
&#13;
Since the IPv6 socket control block and the IPv4 socket control block share
the same memory area (skb-&amp;amp;gt;cb), the receiving interface index info is lost
(IP6CB(skb)-&amp;amp;gt;iif is set to zero).&#13;
&#13;
As a side effect, that condition triggers a NULL pointer dereference if
commit 0857d6f8c759 (&amp;amp;quot;ip…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
usb: fix various gadgets null ptr deref on 10gbps cabling.&#13;
&#13;
This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps.(CVE-2021-47270)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
seg6: fix the iif in the IPv6 socket control block&#13;
&#13;
When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving
interface index into the IPv4 socket control block (v5.16-rc4,
net/ipv4/ip_input.c line 510):&#13;
&#13;
    IPCB(skb)-&amp;amp;gt;iif = skb-&amp;amp;gt;skb_iif;&#13;
&#13;
If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH
header, the seg6_do_srh_encap(...) performs the required encapsulation.
In this case, the seg6_do_srh_encap function clears the IPv6 socket control
block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):&#13;
&#13;
    memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));&#13;
&#13;
The memset(...) was introduced in commit ef489749aae5 (&amp;amp;quot;ipv6: sr: clear
IP6CB(skb) on SRH ip4ip6 encapsulation&amp;amp;quot;) a long time ago (2019-01-29).&#13;
&#13;
Since the IPv6 socket control block and the IPv4 socket control block share
the same memory area (skb-&amp;amp;gt;cb), the receiving interface index info is lost
(IP6CB(skb)-&amp;amp;gt;iif is set to zero).&#13;
&#13;
As a side effect, that condition triggers a NULL pointer dereference if
commit 0857d6f8c759 (&amp;amp;quot;ip…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1835</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2372-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2372-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:2372-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-38582</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-38582</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 185 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential hang in nilfs_detach_log_writer() Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer   nilfs_segctor_destroy     nilfs_segctor_kill_thread  --&amp;gt; Shut down log writer thread     flush_work       nilfs_iput_work_func         nilfs_dispose_list           iput             nilfs_evict_inode               nilfs_transaction_commit                 nilfs_construct_segment (if inode needs sync)                   nilfs_segctor_sync  --&amp;gt; Attempt to synchronize with                                           log writer thread                            *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().&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 185 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential hang in nilfs_detach_log_writer() Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer   nilfs_segctor_destroy     nilfs_segctor_kill_thread  --&amp;gt; Shut down log writer thread     flush_work       nilfs_iput_work_func         nilfs_dispose_list           iput             nilfs_evict_inode               nilfs_transaction_commit                 nilfs_construct_segment (if inode needs sync)                   nilfs_segctor_sync  --&amp;gt; Attempt to synchronize with                                           log writer thread                            *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-38582</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1418 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1418</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher 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 nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1418</guid>
    </item>
  </channel>
</rss>
