GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux slab allocator: ABA race in the optimistic freelist return corrupts the partial list

CVSS 7.8CVE-2026-97941Kernel, userspace & hypervisorcurated

Impact

The optimistic __slab_try_return_freelist() path assumed a NULL slab->freelist plus a successful cmpxchg meant nobody had freed into the slab, but another CPU can free, insert the slab onto the partial list, allocate again and be mid-removal under n->list_lock. __refill_objects_node() then re-inserts the same slab while it is being removed, corrupting the node partial list - the reporter's trace is a list_add corruption BUG from a plain msgsnd() syscall, hit as an unprivileged user (UID 65534 in the report). This is the core allocator, so it is reachable from any workload on the node, not a niche subsystem, and the known outcome is an immediate kernel panic taking every job on the GPU host with it. Note the trace is against a 7.2-rc tree - the flawed optimization arrived in commit ba7425312607, so only kernels carrying it are affected.

Who can reach it

Local unprivileged user on the node, through ordinary allocation-heavy syscalls; no GPU or device access needed. Any tenant with code execution qualifies. Requires a kernel that includes the __slab_try_return_freelist optimization.

What to do

Check whether your kernel carries commit ba7425312607; if it does, install a build with the list_lock fix and reboot the node. If your kernels predate that optimization - most current LTS lines - you are not affected and no window is needed. There is no runtime mitigation for a core allocator race.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.