In the Linux kernel, the following vulnerability has been resolved:
mm/shrinker: do not hold RCU lock in shrinkerdebugfscount_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 cssrstatflush memcgroupflushstats zswapshrinkercount shrinkerdebugfscountshow
shrinkerdebugfscountshow() invokes the ->countobjects() callback under rcureadlock(). The zswap callback flushes memcg stats via cssrstatflush(), which may sleep, so it must not run under RCU.
The RCU lock is not needed here. memcgroupiter() takes RCU internally and returns a memcg holding a css reference (dropped on the next iteration or by memcgroupiterbreak()), so the memcg stays alive without it. The shrinker is kept alive by the open debugfs file: shrinkerfree() removes the debugfs entries via debugfsremoverecursive(), which waits for in-flight readers to drain, before callrcu(..., shrinkerfreercucb). The sibling "scan" handler already invokes the sleeping ->scan_objects() callback with no RCU section.
Drop the rcureadlock()/rcureadunlock().
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64419.json",
"cna_assigner": "Linux"
}