CVE-2026-64419

What it actually does

This is a Linux kernel memory-management flaw in the shrinker debugfs interface. When a user reads the debugfs "count" file for a memory-cgroup-aware shrinker, the kernel can call a shrinker count callback while holding an RCU read-side lock. Some callbacks, such as the zswap shrinker path, may flush memory cgroup statistics and sleep, which is invalid in that context. The result is a kernel warning/BUG condition and potential denial of service, especially on systems configured to panic on kernel warnings or BUG conditions. Exploitation generally requires local ability to access mounted debugfs shrinker entries; it is not a typical remote code execution issue.

Why it matters to the business

A local user or process with access to kernel debugfs shrinker files may be able to destabilize or crash affected Linux systems. The main operational risk is service interruption from kernel warnings, BUG handling, or panic-on-warning configurations. Because EPSS is very low, the issue is not currently expected to be broadly exploited in the wild, and it is not listed in CISA KEV or associated with ransomware campaigns; however, production systems that expose debugfs or run workloads dependent on zswap and memory cgroups should treat it as a reliability and hardening issue.

How an attack unfolds

An attacker first obtains local execution or leverages an already-running local workload with permission to read debugfs. If debugfs is mounted and readable, the attacker locates shrinker debugfs entries and repeatedly reads a memcg-aware shrinker's "count" file. On vulnerable kernels, this path enters shrinker_debugfs_count_show() and invokes the shrinker's count_objects() callback while still inside an RCU read-side critical section. For shrinkers such as zswap, the callback can flush memory cgroup statistics through css_rstat_flush(), which may sleep. The kernel detects a sleeping function called from an invalid context and emits a BUG/warning. On hardened or availability-sensitive systems configured to panic on such conditions, this can escalate from a warning to a system crash, causing denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix removing the unnecessary RCU read lock around shrinker_debugfs_count_show(). If consuming a distribution kernel, apply the vendor-provided security or stable kernel update rather than relying only on upstream version numbers. No exact fixed package versions were provided in the input, so administrators should consult their Linux distribution, appliance vendor, cloud image, or kernel maintainer advisories for the patched release containing the mm/shrinker debugfs fix. As mitigations where immediate patching is not possible, avoid mounting debugfs on production systems unless required, restrict access to /sys/kernel/debug to trusted administrators only, disable or limit untrusted local shell access, review use of kernel.panic_on_warn where appropriate for the environment, and consider disabling optional features such as zswap only if operationally acceptable and validated.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the shrinker_debugfs_count_show() RCU locking issue and that the host has been rebooted into the patched kernel. Check `uname -r` and package manager metadata against the vendor advisory. Validate exposure by checking whether debugfs is mounted with `findmnt debugfs` or by inspecting `/proc/mounts` for `/sys/kernel/debug`. Confirm access controls on `/sys/kernel/debug` prevent untrusted users from reading shrinker entries. On a non-production test system only, a controlled read of relevant `/sys/kernel/debug/shrinker/*/count` files should no longer produce kernel messages such as "BUG: sleeping function called from invalid context" or stack traces involving `shrinker_debugfs_count_show`, `zswap_shrinker_count`, `mem_cgroup_flush_stats`, or `css_rstat_flush`.

Typical attack path

1. Gain local code execution or shell access on a Linux host, container host, or appliance running an affected kernel.
2. Determine whether debugfs is mounted, commonly under /sys/kernel/debug.
3. Enumerate shrinker debugfs entries and identify memcg-aware shrinkers with a readable count file.
4. Read the affected shrinker count file, potentially repeatedly or under memory-pressure conditions.
5. Trigger the vulnerable kernel path where shrinker_debugfs_count_show() calls a sleeping callback while under RCU.
6. Cause kernel BUG/warning output and, on systems with panic-on-warn or similar settings, a kernel panic and service outage.

How to detect it

Review kernel and system logs for evidence that the vulnerable path has been triggered. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump infrastructure, kdump/vmcore records, endpoint telemetry that captures kernel oops events, and SIEM-ingested kernel logs. Look for BUG or warning messages indicating a sleeping function was called from an invalid context, especially stack traces containing `shrinker_debugfs_count_show`, `zswap_shrinker_count`, `mem_cgroup_flush_stats`, and `css_rstat_flush`. Also look for suspicious or repeated reads of `/sys/kernel/debug/shrinker/*/count` if auditd, eBPF telemetry, EDR, or shell command logging captures file access. A subsequent reboot, panic, kdump event, or service outage shortly after these kernel messages increases confidence that the issue was exploited or accidentally triggered.

• 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
• /sys/kernel/debug/shrinker/
• /sys/kernel/debug/shrinker/*/count
• debugfs_remove_recursive
• call_rcu(..., shrinker_free_rcu_cb)

What your security team should do

• Prioritize patching Linux systems where debugfs is mounted, local users are present, containers or workloads may access host debugfs, zswap is enabled, or panic-on-warning behavior can cause outages.
• Inventory systems with debugfs mounted by searching for debugfs in `/proc/mounts`, `findmnt`, endpoint telemetry, or configuration management data.
• Restrict debugfs access to trusted administrators and ensure it is not exposed into containers, sandboxes, or application runtimes.
• Review kernel panic settings such as `kernel.panic_on_warn`; understand whether a warning from this issue could become a full host outage.
• Monitor kernel logs for the specific BUG and stack-trace indicators associated with this flaw.
• Because there is no KEV listing, no known ransomware association, no named threat actor activity, and very low EPSS, treat this as a defense-in-depth and availability patch rather than an emergency internet-facing exposure, unless local multi-user access or debugfs exposure increases risk.
• Reboot after applying the kernel update; loading a patched package alone is insufficient if the vulnerable kernel remains running.