<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 16:55:24 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-97941</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-97941</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/slab: take n-&amp;gt;list_lock in __slab_try_return_freelist() to avoid race&lt;/p&gt;
&lt;p&gt;Commit ba7425312607 (&amp;#34;mm, slab: add an optimistic
__slab_try_return_freelist()&amp;#34;) incorrectly assumed that nobody has freed
an object to the slab as long as slab-&amp;gt;freelist is NULL and cmpxchg
succeeds.&lt;/p&gt;
&lt;p&gt;However, as reported by Hyunwoo Kim [1], other CPUs might have freed
an object to the slab, insert the slab to the partial list, then
allocated an object from the slab, and be in the middle of removing
the slab from the list under n-&amp;gt;list_lock.&lt;/p&gt;
&lt;p&gt;Since __refill_objects_node() puts the slab back on pc.slabs
outside n-&amp;gt;list_lock, it might insert the slab into that list while
the slab is concurrently being removed from n-&amp;gt;partial.
This led to a list corruption [1]:&lt;/p&gt;
&lt;p&gt;list_add corruption. next-&amp;gt;prev should be prev
  (ffff888100000248), but was dead000000000122.
  (next=ffffea000416e410).
  kernel BUG at lib/list_debug.c:29!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted
  7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy)
  RIP: 0010:__list_add_valid_or_report+0x80/0xd0
  ...
  Call Trace:
   alloc_from_new_slab+0x183/0x300
   ___slab_alloc+0x31c/0x890
   __kmalloc_noprof+0x3d4/0x800
   lsm_blob_alloc+0x2d/0x50
   security_msg_msg_alloc+0x26/0x90
   load_msg+0x1aa/0x210
   do_msgsnd+0x91/0x800
   do_syscall_64+0x109/0x5d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  ...
  Kernel panic - not syn…&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;mm/slab: take n-&amp;gt;list_lock in __slab_try_return_freelist() to avoid race&lt;/p&gt;
&lt;p&gt;Commit ba7425312607 (&amp;#34;mm, slab: add an optimistic
__slab_try_return_freelist()&amp;#34;) incorrectly assumed that nobody has freed
an object to the slab as long as slab-&amp;gt;freelist is NULL and cmpxchg
succeeds.&lt;/p&gt;
&lt;p&gt;However, as reported by Hyunwoo Kim [1], other CPUs might have freed
an object to the slab, insert the slab to the partial list, then
allocated an object from the slab, and be in the middle of removing
the slab from the list under n-&amp;gt;list_lock.&lt;/p&gt;
&lt;p&gt;Since __refill_objects_node() puts the slab back on pc.slabs
outside n-&amp;gt;list_lock, it might insert the slab into that list while
the slab is concurrently being removed from n-&amp;gt;partial.
This led to a list corruption [1]:&lt;/p&gt;
&lt;p&gt;list_add corruption. next-&amp;gt;prev should be prev
  (ffff888100000248), but was dead000000000122.
  (next=ffffea000416e410).
  kernel BUG at lib/list_debug.c:29!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted
  7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy)
  RIP: 0010:__list_add_valid_or_report+0x80/0xd0
  ...
  Call Trace:
   alloc_from_new_slab+0x183/0x300
   ___slab_alloc+0x31c/0x890
   __kmalloc_noprof+0x3d4/0x800
   lsm_blob_alloc+0x2d/0x50
   security_msg_msg_alloc+0x26/0x90
   load_msg+0x1aa/0x210
   do_msgsnd+0x91/0x800
   do_syscall_64+0x109/0x5d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  ...
  Kernel panic - not syn…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-97941</guid>
    </item>
    <item>
      <title>GHSA-jvph-rmf4-fgm6</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-jvph-rmf4-fgm6</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/slab: take n-&amp;gt;list_lock in __slab_try_return_freelist() to avoid race&lt;/p&gt;
&lt;p&gt;Commit ba7425312607 (&amp;#34;mm, slab: add an optimistic
__slab_try_return_freelist()&amp;#34;) incorrectly assumed that nobody has freed
an object to the slab as long as slab-&amp;gt;freelist is NULL and cmpxchg
succeeds.&lt;/p&gt;
&lt;p&gt;However, as reported by Hyunwoo Kim [1], other CPUs might have freed
an object to the slab, insert the slab to the partial list, then
allocated an object from the slab, and be in the middle of removing
the slab from the list under n-&amp;gt;list_lock.&lt;/p&gt;
&lt;p&gt;Since __refill_objects_node() puts the slab back on pc.slabs
outside n-&amp;gt;list_lock, it might insert the slab into that list while
the slab is concurrently being removed from n-&amp;gt;partial.
This led to a list corruption [1]:&lt;/p&gt;
&lt;p&gt;list_add corruption. next-&amp;gt;prev should be prev
  (ffff888100000248), but was dead000000000122.
  (next=ffffea000416e410).
  kernel BUG at lib/list_debug.c:29!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted
  7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy)
  RIP: 0010:__list_add_valid_or_report+0x80/0xd0
  ...
  Call Trace:
   alloc_from_new_slab+0x183/0x300
   ___slab_alloc+0x31c/0x890
   __kmalloc_noprof+0x3d4/0x800
   lsm_blob_alloc+0x2d/0x50
   security_msg_msg_alloc+0x26/0x90
   load_msg+0x1aa/0x210
   do_msgsnd+0x91/0x800
   do_syscall_64+0x109/0x5d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  ...
  Kernel panic - not syn…&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;mm/slab: take n-&amp;gt;list_lock in __slab_try_return_freelist() to avoid race&lt;/p&gt;
&lt;p&gt;Commit ba7425312607 (&amp;#34;mm, slab: add an optimistic
__slab_try_return_freelist()&amp;#34;) incorrectly assumed that nobody has freed
an object to the slab as long as slab-&amp;gt;freelist is NULL and cmpxchg
succeeds.&lt;/p&gt;
&lt;p&gt;However, as reported by Hyunwoo Kim [1], other CPUs might have freed
an object to the slab, insert the slab to the partial list, then
allocated an object from the slab, and be in the middle of removing
the slab from the list under n-&amp;gt;list_lock.&lt;/p&gt;
&lt;p&gt;Since __refill_objects_node() puts the slab back on pc.slabs
outside n-&amp;gt;list_lock, it might insert the slab into that list while
the slab is concurrently being removed from n-&amp;gt;partial.
This led to a list corruption [1]:&lt;/p&gt;
&lt;p&gt;list_add corruption. next-&amp;gt;prev should be prev
  (ffff888100000248), but was dead000000000122.
  (next=ffffea000416e410).
  kernel BUG at lib/list_debug.c:29!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted
  7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy)
  RIP: 0010:__list_add_valid_or_report+0x80/0xd0
  ...
  Call Trace:
   alloc_from_new_slab+0x183/0x300
   ___slab_alloc+0x31c/0x890
   __kmalloc_noprof+0x3d4/0x800
   lsm_blob_alloc+0x2d/0x50
   security_msg_msg_alloc+0x26/0x90
   load_msg+0x1aa/0x210
   do_msgsnd+0x91/0x800
   do_syscall_64+0x109/0x5d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  ...
  Kernel panic - not syn…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-jvph-rmf4-fgm6</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-97941</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97941</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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: mm/slab: take n-&amp;gt;list_lock in __slab_try_return_freelist() to avoid race Commit ba7425312607 (&amp;#34;mm, slab: add an optimistic __slab_try_return_freelist()&amp;#34;) incorrectly assumed that nobody has freed an object to the slab as long as slab-&amp;gt;freelist is NULL and cmpxchg succeeds. However, as reported by Hyunwoo Kim [1], other CPUs might have freed an object to the slab, insert the slab to the partial list, then allocated an object from the slab, and be in the middle of removing the slab from the list under n-&amp;gt;list_lock. Since __refill_objects_node() puts the slab back on pc.slabs outside n-&amp;gt;list_lock, it might insert the slab into that list while the slab is concurrently being removed from n-&amp;gt;partial. This led to a list corruption [1]:   list_add corruption. next-&amp;gt;prev should be prev   (ffff888100000248), but was dead000000000122.   (next=ffffea000416e410).   kernel BUG at lib/list_debug.c:29!   Oops: invalid opcode: 0000 [#1] SMP NOPTI   CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted   7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy)   RIP: 0010:__list_add_valid_or_report+0x80/0xd0   ...   Call Trace:    alloc_from_new_slab+0x183/0x300    ___slab_alloc+0x31c/0x890    __kmalloc_noprof+0x3d4/0x800    lsm_blob_alloc+0x2d/0x50    security_msg_msg_alloc+0x26/0x90    load_msg+0x1aa/0x210    do_msgsnd+0x91/0x800    do_syscall_64+0x109/0x5d0    entry_SYSCALL_64_after_hwframe+0x77/0x7f   ...   Kernel panic - not syncing:…&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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: mm/slab: take n-&amp;gt;list_lock in __slab_try_return_freelist() to avoid race Commit ba7425312607 (&amp;#34;mm, slab: add an optimistic __slab_try_return_freelist()&amp;#34;) incorrectly assumed that nobody has freed an object to the slab as long as slab-&amp;gt;freelist is NULL and cmpxchg succeeds. However, as reported by Hyunwoo Kim [1], other CPUs might have freed an object to the slab, insert the slab to the partial list, then allocated an object from the slab, and be in the middle of removing the slab from the list under n-&amp;gt;list_lock. Since __refill_objects_node() puts the slab back on pc.slabs outside n-&amp;gt;list_lock, it might insert the slab into that list while the slab is concurrently being removed from n-&amp;gt;partial. This led to a list corruption [1]:   list_add corruption. next-&amp;gt;prev should be prev   (ffff888100000248), but was dead000000000122.   (next=ffffea000416e410).   kernel BUG at lib/list_debug.c:29!   Oops: invalid opcode: 0000 [#1] SMP NOPTI   CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted   7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy)   RIP: 0010:__list_add_valid_or_report+0x80/0xd0   ...   Call Trace:    alloc_from_new_slab+0x183/0x300    ___slab_alloc+0x31c/0x890    __kmalloc_noprof+0x3d4/0x800    lsm_blob_alloc+0x2d/0x50    security_msg_msg_alloc+0x26/0x90    load_msg+0x1aa/0x210    do_msgsnd+0x91/0x800    do_syscall_64+0x109/0x5d0    entry_SYSCALL_64_after_hwframe+0x77/0x7f   ...   Kernel panic - not syncing:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97941</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder 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 Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
