CVE-2026-64419 in Linux
Summary
by MITRE • 07/25/2026
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().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/26/2026
This vulnerability exists in the linux kernel's memory management subsystem, specifically within the shrinker_debugfs_count_show() function that handles debugfs file operations for memcg-aware shrinkers. The issue manifests when reading the debugfs "count" file associated with memory control group aware shrinkers, where the function attempts to invoke the ->count_objects() callback while holding an RCU read-side critical section. This creates a dangerous scenario where sleeping functions can be called from within an RCU context, violating fundamental kernel locking principles and potentially leading to system instability or deadlock conditions.
The technical flaw stems from improper lock management where shrinker_debugfs_count_show() incorrectly holds rcu_read_lock() while calling the zswap callback function that ultimately invokes css_rstat_flush(). This flush operation may sleep during memory allocation or synchronization operations, which is strictly forbidden within RCU read-side critical sections as defined by kernel design principles. The problem occurs because the zswap_shrinker_count callback chain eventually calls mem_cgroup_flush_stats(), which requires sleeping operations to complete its work properly.
The operational impact of this vulnerability extends beyond simple system stability concerns to potentially enable denial-of-service conditions or system crashes when memory management operations are performed concurrently with debugfs access. The issue affects memory cgroup-aware shrinkers specifically, which are used for tracking and managing memory consumption across different control groups in the system. When multiple processes attempt to read debugfs count files while memory pressure exists, the kernel may enter an invalid state where sleeping functions execute within RCU contexts, violating the fundamental requirement that RCU critical sections must remain non-blocking.
The fix implemented removes the unnecessary rcu_read_lock()/rcu_read_unlock() calls from shrinker_debugfs_count_show() since these locks are not required for the operation being performed. The mem_cgroup_iter() function already provides adequate reference counting through CSS references, ensuring memory cgroup objects remain valid without requiring explicit RCU protection. The sibling "scan" handler already correctly implements this pattern by invoking sleeping ->scan_objects() callbacks outside of RCU sections, maintaining consistency with established kernel patterns. This vulnerability aligns with CWE-367 - Time-of-Check to Time-of-Use (TOCTOU) flaw classification and could potentially map to ATT&CK technique T1490 - Inhibit System Recovery through denial-of-service conditions that affect system memory management capabilities.
The resolution follows established kernel best practices for RCU usage and maintains the integrity of debugfs file operations while preserving all existing functionality. The fix ensures that memory cgroup statistics can be properly flushed without blocking RCU readers, preventing potential deadlocks or system hangs during concurrent memory management operations. This change also aligns with kernel security principles that require strict separation between non-blocking RCU contexts and potentially blocking operations, maintaining the overall stability and reliability of the linux kernel's memory subsystem under various load conditions.