CVE-2026-64417

What it actually does

This vulnerability is a Linux kernel denial-of-service flaw in the shrinker debugfs interface. The kernel created debugfs control files named "count" and "scan" for every registered shrinker even when the shrinker did not implement the corresponding callback function. If a local user or process with write access to the relevant debugfs file writes to a shrinker "scan" or "count" file whose callback is NULL, the kernel dereferences a NULL function pointer and panics. The result is a system crash rather than privilege escalation or data theft.

Why it matters to the business

Successful exploitation can abruptly crash affected Linux systems, causing workload interruption, service downtime, failed jobs, and possible data loss for in-flight operations. The practical risk is highest on systems where debugfs is mounted and accessible to users, containers, administrative automation, or monitoring tooling that can write to shrinker debugfs entries. Public exploitation maturity is currently low, EPSS is low, and the issue is not listed in CISA KEV, but kernel-level denial-of-service flaws still warrant timely remediation on production, virtualization, and high-availability Linux hosts.

How an attack unfolds

An attacker first needs local access to an affected Linux host or control over a process that can write to debugfs. The attacker checks whether debugfs is mounted, commonly under /sys/kernel/debug, and enumerates shrinker debugfs entries. For a shrinker that lacks a scan_objects() or count_objects() implementation, such as the xen-backend example described in the advisory, the attacker writes to the corresponding "scan" or "count" debugfs file. The kernel then routes the write through shrinker_debugfs_scan_write or the analogous count path and attempts to call a NULL function pointer. This causes a kernel NULL pointer dereference and panic, crashing or rebooting the system depending on panic settings.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream fix for the shrinker debugfs NULL pointer dereference. The corrected behavior is to create debugfs "count" and "scan" files only when the corresponding shrinker callback exists. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisory and apply the first kernel update that references this fix. As interim mitigation, restrict or disable debugfs on production systems where it is not required: avoid mounting debugfs, mount it only for trusted administrators, and prevent unprivileged users, containers, and automation from writing under /sys/kernel/debug. Reboot into the patched kernel after installation, since kernel package installation alone does not remove exposure from the running kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, contains the fix by checking the active kernel version with uname -r and comparing it against the vendor advisory or patched build. Verify whether debugfs is mounted with mount or findmnt and review permissions on /sys/kernel/debug. On patched systems, shrinker debugfs entries should not expose "scan" or "count" files for shrinkers that do not implement the corresponding callback. Validate that production hardening prevents non-administrative users and containers from writing to debugfs. Where safe test environments are available, reproduce the pre-patch condition only in a non-production VM and confirm the patched kernel no longer panics when interacting with applicable shrinker debugfs entries.

Typical attack path

1. Obtain local shell access, compromised workload execution, or another ability to write to debugfs on an affected Linux host.
2. Confirm debugfs is mounted, for example at /sys/kernel/debug.
3. Enumerate shrinker debugfs directories and identify writable "scan" or "count" files.
4. Write crafted or arbitrary input to a vulnerable shrinker debugfs file whose callback is not implemented.
5. Trigger a kernel NULL pointer dereference in the shrinker debugfs write path.
6. Cause a kernel panic, crash, reboot, or loss of service availability.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs and crash artifacts for panic signatures matching a NULL pointer dereference in the shrinker debugfs write path. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output captured by monitoring, kdump/vmcore records, pstore/ramoops logs, hypervisor console logs, and EDR process/file telemetry for writes under /sys/kernel/debug/shrinker. Look for crashes where the call trace includes shrinker_debugfs_scan_write, full_proxy_write, vfs_write, ksys_write, and entry_SYSCALL_64_after_hwframe. Correlate the timestamp of any panic or reboot with auditd, eBPF, shell history, sudo logs, container runtime logs, or process accounting showing writes to /sys/kernel/debug/shrinker/*/scan or /sys/kernel/debug/shrinker/*/count. If auditd was enabled, search for PATH or SYSCALL records involving debugfs shrinker paths and write syscalls. Absence of these logs does not rule out exploitation because kernel panic may interrupt logging before all events are flushed.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• RIP: 0010:0x0
• shrinker_debugfs_scan_write
• full_proxy_write
• vfs_write
• ksys_write
• entry_SYSCALL_64_after_hwframe
• /sys/kernel/debug/shrinker/
• /sys/kernel/debug/shrinker/*/scan
• /sys/kernel/debug/shrinker/*/count
• debugfs
• kernel NULL pointer dereference
• xen-backend shrinker

What your security team should do

• Prioritize patching Linux hosts where debugfs is mounted, where local users have shell access, where containers may reach host debugfs, or where virtualization components such as Xen backends are present.
• Inventory systems with debugfs mounted using configuration management, EDR, or vulnerability management tooling.
• Apply vendor kernel updates and reboot systems into the patched kernel; schedule controlled restarts for high-availability services.
• As a mitigation, unmount debugfs or restrict access to /sys/kernel/debug on production systems that do not require it.
• Review container runtime and host mount configurations to ensure host debugfs is not exposed into containers unless explicitly required and tightly controlled.
• Monitor kernel logs for NULL pointer dereference or panic traces involving shrinker_debugfs_scan_write, shrinker debugfs, full_proxy_write, or vfs_write.
• Treat unexpected kernel panics on affected versions as potential security events if they coincide with writes to /sys/kernel/debug/shrinker paths.
• Because EPSS is low and there is no KEV listing, handle as timely risk reduction rather than emergency internet-facing exploitation response, unless local multi-user or container escape-to-host-write scenarios exist.