CVE-2026-64417: mm: shrinker: fix NULL pointer dereference in debugfs
In the Linux kernel, the following vulnerability has been resolved:
mm: shrinker: fix NULL pointer dereference in debugfs
shrinkerdebugfsadd() creates both "count" and "scan" debugfs files unconditionally.
That assumes every shrinker implements both countobjects() and scanobjects(), which is not guaranteed. For example, the xen-backend shrinker sets countobjects() but leaves scanobjects() NULL, so writing to its scan file calls through a NULL function pointer and panics the kernel:
BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. Call Trace: <TASK> shrinkerdebugfsscanwrite+0x12e/0x270 fullproxywrite+0x5f/0x90 vfswrite+0xde/0x420 ? filpflush+0x75/0x90 ? filpclose+0x1d/0x30 ? dodup2+0xb8/0x120 ksyswrite+0x68/0xf0 ? filpflush+0x75/0x90 dosyscall64+0xb3/0x5b0 entrySYSCALL64afterhwframe+0x76/0x7e
The count path has the same issue in principle if a shrinker omits countobjects().
To fix it, only create "count" and "scan" debugfs files when the corresponding callbacks are present.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the kernel shrinker debugfs implementation, update shrinker_debugfs_add() to create the "count" debugfs file only when count_objects() is non-NULL, and create the "scan" debugfs file only when scan_objects() is non-NULL, to prevent shrinker_debugfs_scan_write() from calling a NULL function pointer.
Linux kernel mm: shrinker debugfs files creation for shrinkers (count/scan) = Only create debugfs files when the corresponding callbacks are present
Event History
Frequently Asked Questions
Who can trigger the kernel panic?
An attacker or local user needs the ability to write to a shrinker’s debugfs "scan" or "count" file for a shrinker that lacks the corresponding callback. The provided example is the xen-backend shrinker, which has no scan_objects() callback.
Is this reachable through normal shrinker operation?
The described crash occurs when writing to the debugfs file, not during normal shrinker operation. The vulnerable behavior exists because debugfs files were created even when their associated callback was NULL.
What should be done if the fix cannot be applied immediately?
Prevent writes to the affected shrinker debugfs "scan" and "count" files, particularly for shrinkers without the corresponding callbacks. The issue is avoided when those debugfs files are not created for missing callbacks.
How can I check whether the system may be affected?
Check whether debugfs exposes "count" or "scan" files for shrinkers that do not implement the matching count_objects() or scan_objects() callback. A xen-backend shrinker with a writable "scan" debugfs file is a concrete affected condition described in the advisory.