<?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 15:12:19 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68284</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68284</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-2026-68284</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1069 — 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-2026-avi-1069</link>
      <description>certfr-2026-avi-1069</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</guid>
    </item>
    <item>
      <title>EUVD-2026-356159</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356159</link>
      <description>EUVD-2026-356159</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356159</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68284</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68284</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()&lt;/p&gt;
&lt;p&gt;tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which
drops and reacquires the socket lock.  Its error path tries to decide
whether msg_tx names the local temporary message by comparing it with
the current value of psock-&amp;gt;cork.&lt;/p&gt;
&lt;p&gt;This comparison is unsafe when two threads send on the same socket:&lt;/p&gt;
&lt;p&gt;Thread A                         Thread B
  msg_tx = psock-&amp;gt;cork
  sk_msg_alloc() fails
  sk_stream_wait_memory()
    releases the socket lock      acquires the socket lock
                                  completes the cork
                                  psock-&amp;gt;cork = NULL
                                  frees the cork
    reacquires the socket lock
  msg_tx != psock-&amp;gt;cork
  sk_msg_free(msg_tx)&lt;/p&gt;
&lt;p&gt;The stale cork is therefore mistaken for the local temporary message
and freed again.  KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50
  Read of size 4 at addr ffff88810c908800 by task poc/90
  Call Trace:
   sk_msg_free+0x49/0x50
   tcp_bpf_sendmsg+0x14f5/0x1cc0
   __sys_sendto+0x32c/0x3a0
   __x64_sys_sendto+0xdb/0x1b0
  Allocated by task 89:
   __kasan_kmalloc+0x8f/0xa0
   tcp_bpf_sendmsg+0x16b3/0x1cc0
  Freed by task 91:
   __kasan_slab_free+0x43/0x70
   kfree+0x131/0x3c0
   tcp_bpf_sendmsg+0xec3/0x1cc0&lt;/p&gt;
&lt;p&gt;msg_tx can only name the stack-local tmp or the shared cork. Check for
tmp directly so a changed psock-&amp;gt;cor…&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;bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()&lt;/p&gt;
&lt;p&gt;tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which
drops and reacquires the socket lock.  Its error path tries to decide
whether msg_tx names the local temporary message by comparing it with
the current value of psock-&amp;gt;cork.&lt;/p&gt;
&lt;p&gt;This comparison is unsafe when two threads send on the same socket:&lt;/p&gt;
&lt;p&gt;Thread A                         Thread B
  msg_tx = psock-&amp;gt;cork
  sk_msg_alloc() fails
  sk_stream_wait_memory()
    releases the socket lock      acquires the socket lock
                                  completes the cork
                                  psock-&amp;gt;cork = NULL
                                  frees the cork
    reacquires the socket lock
  msg_tx != psock-&amp;gt;cork
  sk_msg_free(msg_tx)&lt;/p&gt;
&lt;p&gt;The stale cork is therefore mistaken for the local temporary message
and freed again.  KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50
  Read of size 4 at addr ffff88810c908800 by task poc/90
  Call Trace:
   sk_msg_free+0x49/0x50
   tcp_bpf_sendmsg+0x14f5/0x1cc0
   __sys_sendto+0x32c/0x3a0
   __x64_sys_sendto+0xdb/0x1b0
  Allocated by task 89:
   __kasan_kmalloc+0x8f/0xa0
   tcp_bpf_sendmsg+0x16b3/0x1cc0
  Freed by task 91:
   __kasan_slab_free+0x43/0x70
   kfree+0x131/0x3c0
   tcp_bpf_sendmsg+0xec3/0x1cc0&lt;/p&gt;
&lt;p&gt;msg_tx can only name the stack-local tmp or the shared cork. Check for
tmp directly so a changed psock-&amp;gt;cor…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68284</guid>
    </item>
    <item>
      <title>GHSA-f87h-88f3-m92w</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f87h-88f3-m92w</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()&lt;/p&gt;
&lt;p&gt;tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which
drops and reacquires the socket lock.  Its error path tries to decide
whether msg_tx names the local temporary message by comparing it with
the current value of psock-&amp;gt;cork.&lt;/p&gt;
&lt;p&gt;This comparison is unsafe when two threads send on the same socket:&lt;/p&gt;
&lt;p&gt;Thread A                         Thread B
  msg_tx = psock-&amp;gt;cork
  sk_msg_alloc() fails
  sk_stream_wait_memory()
    releases the socket lock      acquires the socket lock
                                  completes the cork
                                  psock-&amp;gt;cork = NULL
                                  frees the cork
    reacquires the socket lock
  msg_tx != psock-&amp;gt;cork
  sk_msg_free(msg_tx)&lt;/p&gt;
&lt;p&gt;The stale cork is therefore mistaken for the local temporary message
and freed again.  KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50
  Read of size 4 at addr ffff88810c908800 by task poc/90
  Call Trace:
   sk_msg_free+0x49/0x50
   tcp_bpf_sendmsg+0x14f5/0x1cc0
   __sys_sendto+0x32c/0x3a0
   __x64_sys_sendto+0xdb/0x1b0
  Allocated by task 89:
   __kasan_kmalloc+0x8f/0xa0
   tcp_bpf_sendmsg+0x16b3/0x1cc0
  Freed by task 91:
   __kasan_slab_free+0x43/0x70
   kfree+0x131/0x3c0
   tcp_bpf_sendmsg+0xec3/0x1cc0&lt;/p&gt;
&lt;p&gt;msg_tx can only name the stack-local tmp or the shared cork. Check for
tmp directly so a changed psock-&amp;gt;cor…&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;bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()&lt;/p&gt;
&lt;p&gt;tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which
drops and reacquires the socket lock.  Its error path tries to decide
whether msg_tx names the local temporary message by comparing it with
the current value of psock-&amp;gt;cork.&lt;/p&gt;
&lt;p&gt;This comparison is unsafe when two threads send on the same socket:&lt;/p&gt;
&lt;p&gt;Thread A                         Thread B
  msg_tx = psock-&amp;gt;cork
  sk_msg_alloc() fails
  sk_stream_wait_memory()
    releases the socket lock      acquires the socket lock
                                  completes the cork
                                  psock-&amp;gt;cork = NULL
                                  frees the cork
    reacquires the socket lock
  msg_tx != psock-&amp;gt;cork
  sk_msg_free(msg_tx)&lt;/p&gt;
&lt;p&gt;The stale cork is therefore mistaken for the local temporary message
and freed again.  KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50
  Read of size 4 at addr ffff88810c908800 by task poc/90
  Call Trace:
   sk_msg_free+0x49/0x50
   tcp_bpf_sendmsg+0x14f5/0x1cc0
   __sys_sendto+0x32c/0x3a0
   __x64_sys_sendto+0xdb/0x1b0
  Allocated by task 89:
   __kasan_kmalloc+0x8f/0xa0
   tcp_bpf_sendmsg+0x16b3/0x1cc0
  Freed by task 91:
   __kasan_slab_free+0x43/0x70
   kfree+0x131/0x3c0
   tcp_bpf_sendmsg+0xec3/0x1cc0&lt;/p&gt;
&lt;p&gt;msg_tx can only name the stack-local tmp or the shared cork. Check for
tmp directly so a changed psock-&amp;gt;cor…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f87h-88f3-m92w</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-68284 — bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68284</link>
      <description>msrc_CVE-2026-68284</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-68284</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-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/opensuse-su-2026:21910-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-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-2026:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-68284</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68284</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock.  Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock-&amp;gt;cork. This comparison is unsafe when two threads send on the same socket:   Thread A                         Thread B   msg_tx = psock-&amp;gt;cork   sk_msg_alloc() fails   sk_stream_wait_memory()     releases the socket lock      acquires the socket lock                                   completes the cork                                   psock-&amp;gt;cork = NULL                                   frees the cork     reacquires the socket lock   msg_tx != psock-&amp;gt;cork   sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again.  KASAN reported:   BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50   Read of size 4 at addr ffff88810c908800 by task poc/90   Call Trace:    sk_msg_free+0x49/0x50    tcp_bpf_sendmsg+0x14f5/0x1cc0    __sys_sendto+0x32c/0x3a0    __x64_sys_sendto+0xdb/0x1b0   Allocated by task 89:    __kasan_kmalloc+0x8f/0xa0    tcp_bpf_sendmsg+0x16b3/0x1cc0   Freed by task 91:    __kasan_slab_free+0x43/0x70    kfree+0x131/0x3c0    tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock-&amp;gt;cork canno…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock.  Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock-&amp;gt;cork. This comparison is unsafe when two threads send on the same socket:   Thread A                         Thread B   msg_tx = psock-&amp;gt;cork   sk_msg_alloc() fails   sk_stream_wait_memory()     releases the socket lock      acquires the socket lock                                   completes the cork                                   psock-&amp;gt;cork = NULL                                   frees the cork     reacquires the socket lock   msg_tx != psock-&amp;gt;cork   sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again.  KASAN reported:   BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50   Read of size 4 at addr ffff88810c908800 by task poc/90   Call Trace:    sk_msg_free+0x49/0x50    tcp_bpf_sendmsg+0x14f5/0x1cc0    __sys_sendto+0x32c/0x3a0    __x64_sys_sendto+0xdb/0x1b0   Allocated by task 89:    __kasan_kmalloc+0x8f/0xa0    tcp_bpf_sendmsg+0x16b3/0x1cc0   Freed by task 91:    __kasan_slab_free+0x43/0x70    kfree+0x131/0x3c0    tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock-&amp;gt;cork canno…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68284</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2730 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</guid>
    </item>
  </channel>
</rss>
