Description

In the Linux kernel, the following vulnerability has been resolved: mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race Commit ba7425312607 ("mm, slab: add an optimistic __slab_try_return_freelist()") incorrectly assumed that nobody has freed an object to the slab as long as slab->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->list_lock. Since __refill_objects_node() puts the slab back on pc.slabs outside n->list_lock, it might insert the slab into that list while the slab is concurrently being removed from n->partial. This led to a list corruption [1]: list_add corruption. next->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: Fatal exception This is a classic ABA problem where cmpxchg succeeds but the state has changed since __refill_objects_node() took the freelist from the slab. As Vlastimil Babka mentioned [2], it should be rare to return more than one slab (due to the racy read of slab->counters in get_partial_node_bulk()). Therefore, instead of introducing additional complexity, acquire and release n->list_lock twice in the worst case. Return the slab directly to the partial list and hold n->list_lock across the cmpxchg and add_partial(). This is similar to the initial version of commit ba7425312607 [3]. This is enough to avoid the race as the list manipulation is serialized by n->list_lock. While at it, bring back unlikely() hint now that the condition is unlikely.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:21.517Z",
  "pubdate": "2026-09-25T11:17:21.517Z",
  "executiveSummary": "This vulnerability is a race condition in the Linux kernel slab allocator, specifically within the __slab_try_return_freelist function. The flaw involves an incorrect assumption regarding the state of slab freelists, leading to a race condition that triggers kernel-level memory corruption.\nThe issue manifests as a list corruption during concurrent slab manipulation, which can lead to a system-wide kernel panic (denial of service).\nAffected systems include the Linux kernel where the slab allocator manages slab partial lists. The vulnerability arises from an ABA-style race condition where slab state changes between the time of a freelist check and the subsequent cmpxchg operation.\nExploitation requires local access, often via syscalls that trigger slab memory allocation and deallocation patterns, allowing an attacker to manipulate the state of kernel memory management. The impact is critical as it results in an unrecoverable system crash.",
  "technicalDetails": "The root cause of this vulnerability is an unsafe assumption in the optimistic __slab_try_return_freelist mechanism introduced in commit ba7425312607. The logic assumed that if slab->freelist is NULL and a cmpxchg operation succeeds, no objects have been freed to the slab, allowing for lockless management. This assumption fails to account for concurrent slab modifications occurring on other CPUs.\nIn the vulnerable scenario, a race condition occurs when another CPU frees an object to a slab, reinserts that slab into the partial list, and subsequently allocates an object from that same slab. While this second CPU is actively removing the slab from the n->partial list under the protection of n->list_lock, the original thread executing __slab_try_return_freelist may attempt to reinsert the slab into the partial list outside of that lock. This asynchronous insertion into a data structure currently undergoing modification leads to the corruption of the linked list pointers.\nThe kernel BUG is triggered at lib/list_debug.c:29, which detects a list_add operation where the prev/next pointers have become inconsistent, effectively flagging a corrupted list structure. The stack trace indicates that this occurs during standard memory allocation flows such as lsm_blob_alloc, demonstrating that common kernel operations can reach this vulnerable state.\nThe technical flow involves: 1) The original CPU reads the slab state. 2) A concurrent CPU modifies the slab's internal partial list status by invoking __refill_objects_node or similar slab management functions. 3) The original CPU proceeds with an optimistic operation based on stale data. 4) The cmpxchg succeeds, creating an ABA problem where the slab is logically returned to the list while another CPU is mid-update, causing pointer corruption in the kernel's list metadata.\nThe fix necessitates re-introducing the use of n->list_lock to ensure that slab list management is serialized. By acquiring and releasing n->list_lock across the cmpxchg and the add_partial() operations, the kernel ensures that the list structure cannot be concurrently mutated, thus preventing the identified corruption."
}