# CVE-2026-97941: mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race

> A race condition in the Linux kernel slab allocator can cause list corruption and kernel panics, leading to denial of service.

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 25 Sep 2026
- **Updated:** 19 Oct 2026
- **Also known as:** DEBIAN-CVE-2026-97941, GHSA-jvph-rmf4-fgm6, UBUNTU-CVE-2026-97941

## What is CVE-2026-97941?

CVE-2026-97941 is a high-severity vulnerability in Linux, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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.

## Which versions are affected by CVE-2026-97941?


## How do I fix CVE-2026-97941?

Apply the vendor's patch.

## Is CVE-2026-97941 being exploited?

There is no known exploitation of CVE-2026-97941 in the wild and no public exploit code.

Public exploit code:

- Android/ARM64 port (github_poc): https://github.com/ylh440104/InfinityCore-Android-CVE-2026-97941

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-97941 and fix it if it is affected.

What it is: CVE-2026-97941 is a high-severity vulnerability in Linux, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-97941 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-97941/ (Markdown: https://insights.sbomify.com/CVE-2026-97941/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-97941
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-97941
- OSV: https://osv.dev/vulnerability/CVE-2026-97941

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-97941/
Summaries are generated and may contain mistakes; the official description above is the record.