Linux Kernel EUVD-2026-86795

Requires local code execution on the host running an affected build (Linux kernel 7.2 before 7.2.7, i.e. only kernels containing regressing commit ba7425312607 - released stable series are not affected). No special privilege beyond an ordinary local account: the demonstrated trigger uses the System V message-queue send path (msgsnd) reachable by unprivileged users, and the crash trace shows UID 65534 (nobody). The practical limiting factor is the race itself - the attacker must win a narrow multi-CPU timing window where one CPU inserts a slab onto pc.slabs outside n->list_lock while another removes it from n->partial, so reliable triggering needs concurrent threads across multiple CPUs. No user interaction and no non-default configuration are required beyond running the vulnerable kernel version.

This is a slab allocator (mm/slab) ABA race introduced by commit ba7425312607's optimistic __slab_try_return_freelist(). The NVD CVSS of 7.8 (AV:L/AC:L/PR:L/C:H/I:H/A:H) overstates real-world risk on two counts. First, AC:L is inconsistent with the mechanism: the description explicitly frames this as 'a classic ABA problem where cmpxchg succeeds but the state has changed' - a tight cross-CPU race between __refill_objects_node() inserting a slab onto pc.slabs outside n->list_lock and another CPU removing it from n->partial. Winning that window reliably requires precise multi-CPU timing, which is AC:H, not AC:L. Second, the C:H/I:H/A:H impact triad is not supported by the evidence: the only demonstrated outcome is 'list_add corruption' hitting the BUG at lib/list_debug.c:29 followed by 'Kernel panic - not syncing', i.e. a denial-of-service crash. There is no described information leak, so C:H is unjustified and the 'Information Disclosure' tag is a mislabel. While list corruption is in principle a memory-corruption primitive that a skilled attacker could try to shape into escalation, the CVE presents it purely as a crash. On exploitation signals: EPSS is absent, there is no CISA KEV listing, and no public exploit is in the references. The reporter (Hyunwoo Kim) evidently had a private reproducer ('Comm: poc' in the trace), but a private repro is not a public POC and is not active exploitation. No SSVC decision data is provided. Net: a genuine local DoS worth patching on any system actually running the affected kernel, but not the near-critical priority the raw 7.8 implies.

A local unprivileged user runs a program that spins multiple threads pinned to different CPUs, hammering System V message-queue sends (do_msgsnd → load_msg → security_msg_msg_alloc → __kmalloc) to churn slab allocations and frees so that one CPU is mid-removal of a slab from the partial list while another re-inserts it via the optimistic freelist-return path. Landing the ABA window corrupts the partial list and triggers the list_debug BUG, panicking the kernel. No public exploit code is published; the reporter's proof-of-concept reproducer is referenced in the crash trace but is not available in the provided sources.