CVE-2026-64417

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: shrinker: fix NULL pointer dereference in debugfs<br /> <br /> shrinker_debugfs_add() creates both "count" and "scan" debugfs files<br /> unconditionally.<br /> <br /> That assumes every shrinker implements both count_objects() and<br /> scan_objects(), which is not guaranteed. For example, the xen-backend<br /> shrinker sets count_objects() but leaves scan_objects() NULL, so writing<br /> to its scan file calls through a NULL function pointer and panics the<br /> kernel:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> Call Trace:<br /> <br /> shrinker_debugfs_scan_write+0x12e/0x270<br /> full_proxy_write+0x5f/0x90<br /> vfs_write+0xde/0x420<br /> ? filp_flush+0x75/0x90<br /> ? filp_close+0x1d/0x30<br /> ? do_dup2+0xb8/0x120<br /> ksys_write+0x68/0xf0<br /> ? filp_flush+0x75/0x90<br /> do_syscall_64+0xb3/0x5b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The count path has the same issue in principle if a shrinker omits<br /> count_objects().<br /> <br /> To fix it, only create "count" and "scan" debugfs files when the<br /> corresponding callbacks are present.