Look up another CVE · open CVE-2026-53153 in the interactive tracker
CVE-2026-53153
mm/list_lru: drain before clearing xarray entry on reparent
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53153 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list. If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links. Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
mm/list_lru.c
- What this is
- SHRINKERMAINTAINERS section matched on mm/list_lru.c · linux-mm@kvack.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-06-25 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.10%, higher than 0.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- mm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.13 | 6.18.36 | c19ff4351214 |
| 6.13 | 7.0.13 | 2b66496d794e |
| 6.13 | 7.1 | 98733f3f0bec |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable path is reached through local cgroup filesystem operations, primarily mkdir/rmdir and process placement in a memory cgroup, combined with local filesystem or memory-pressure activity that manipulates memcg-aware list_lru entries. It is not directly reachable by unauthenticated network packets.
- AC:LAttack complexity, low
- The issue is a race, but a local attacker with control of a delegated cgroup subtree can drive both sides by repeatedly offlining cgroups while concurrently creating/removing dentries, inodes, zswap entries, or triggering shrinker activity. The race is retryable and under attacker influence, so complexity is low.
- PR:LPrivileges required, low
- Creating/removing the affected cgroups requires write access to a cgroup subtree, but Linux explicitly supports delegation of cgroup subtrees to less-privileged users and cgroup namespaces. No init-namespace root-only capability is inherent once such a subtree is delegated.
- UI:NUser interaction, none
- No victim user action is needed after the attacker has local access to the relevant cgroup subtree. The attacker can trigger cgroup teardown and concurrent LRU activity directly.
- S:UScope, unchanged
- The corruption occurs within the kernel memory-management and cgroup/list_lru scope and impacts the same kernel security authority. There is no VM escape, IOMMU bypass, or separate security scope crossing.
- C:HConfidentiality impact, high
- The bug corrupts kernel list_head next/prev pointers in memcg-aware LRUs such as dentries, inodes, zswap, and workingset shadow nodes. Such kernel memory corruption can plausibly be shaped into disclosure primitives, and uncertainty is scored at the higher severity.
- I:HIntegrity impact, high
- Concurrent list operations under different locks can corrupt adjacent kernel object links and later list manipulation can write through attacker-influenced pointers. This is a kernel memory corruption primitive with plausible control-flow or arbitrary-write exploitation potential.
- A:HAvailability impact, high
- Even without full exploitation, corrupted kernel list links can trigger list debugging splats, oopses, panics, hangs, or reclaim/list traversal failures. Kernel crash availability impact is high.