PT-2026-64640 · Linux · Linux
CVE-2026-64419
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
mm/shrinker: do not hold RCU lock in shrinker debugfs count show()
Reading the debugfs "count" file of a memcg-aware shrinker can sleep
inside an RCU read-side critical section:
BUG: sleeping function called from invalid context at kernel/cgroup/rstat.c:421
RCU nest depth: 1, expected: 0
css rstat flush
mem cgroup flush stats
zswap shrinker count
shrinker debugfs count show
shrinker debugfs count show() invokes the ->count objects() callback under
rcu read lock(). The zswap callback flushes memcg stats via
css rstat flush(), which may sleep, so it must not run under RCU.
The RCU lock is not needed here. mem cgroup iter() takes RCU internally
and returns a memcg holding a css reference (dropped on the next iteration
or by mem cgroup iter break()), so the memcg stays alive without it. The
shrinker is kept alive by the open debugfs file: shrinker free() removes
the debugfs entries via debugfs remove recursive(), which waits for
in-flight readers to drain, before call rcu(..., shrinker free rcu cb).
The sibling "scan" handler already invokes the sleeping ->scan objects()
callback with no RCU section.
Drop the rcu read lock()/rcu read unlock().
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux