CVE-2026-64163

What it actually does

This flaw is a Linux kernel denial-of-service condition in the kprobes KUnit sanity test code. When the kprobes test suite is run more than once, static kprobe and kretprobe structures can retain stale address and flag state from the prior run. On a subsequent run, probe registration may fail with invalid argument errors and can progress to a kernel paging fault or crash. Exploitation requires the vulnerable test code to be present and reachable, typically on systems with KUnit/kprobes test support and debugfs access enabled, and the attacker must be able to trigger the kprobes test run interface.

Why it matters to the business

Successful exploitation can crash the kernel, causing system downtime, workload interruption, and potential loss of in-memory state. The practical risk is limited because this appears to require local administrative or highly privileged access to a kernel test/debug interface rather than remote unauthenticated access. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a very low EPSS score, so remediation should be handled through normal kernel maintenance unless affected systems expose kernel debug/test interfaces to untrusted users.

How an attack unfolds

An attacker with sufficient local privileges first identifies a Linux system where the kernel includes the kprobes KUnit test and where debugfs exposes the KUnit run control path. The attacker triggers the kprobes test once, which completes successfully but leaves stale internal state in static kprobe or kretprobe structures. The attacker then triggers the same test again. Because the probe structures were not fully cleared between test runs, the kernel attempts to re-register probes with leftover address or flag fields, causing registration failures and potentially an invalid memory access. The end result can be a kernel oops, panic, or crash, producing a local denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the kprobes KUnit test cleanup logic. The fix clears kprobe and kretprobe state before each test run so stale address and flag data are not reused. If an immediate kernel update is not available, reduce exposure by disabling or removing KUnit test modules from production kernels, disabling access to debugfs where not required, ensuring debugfs is not mounted on production systems, and restricting root or administrative shell access. Treat kernel debug and test interfaces as privileged maintenance interfaces and avoid enabling them on production hosts unless operationally necessary.

How to confirm the fix worked

Confirm that the running kernel version contains the vendor or upstream fix for the kprobes test cleanup change. If safe in a non-production environment, validate by running the kprobes KUnit test repeatedly and confirming that both runs complete without register_kprobe invalid argument failures, kernel oops messages, or paging faults. On production systems, validate exposure by checking whether debugfs is mounted and whether /sys/kernel/debug/kunit/kprobes_test/run exists. Also verify that untrusted users cannot access debugfs, KUnit controls, or kernel test modules.

Typical attack path

1. Gain local shell access with privileges sufficient to access debugfs and KUnit test controls, typically root or equivalent administrative capability.
2. Confirm that debugfs is mounted and the kprobes KUnit test run interface exists.
3. Run the kprobes KUnit test once through the debugfs KUnit control file.
4. Run the same kprobes KUnit test a second time.
5. Trigger stale kprobe state during the second registration path, causing test failures and potentially a kernel paging fault or crash.
6. Leverage the crash as a denial-of-service condition against the host or workloads running on it.

How to detect it

To determine whether this was already exploited or accidentally triggered, review kernel logs and system journals for repeated execution of the kprobes KUnit test followed by registration failures, kernel oops messages, paging faults, panics, or unexpected reboots. Useful sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, auditd command and file-write records, sudo logs, shell history for privileged users, and EDR telemetry showing writes to debugfs KUnit control files. Look specifically for writes to /sys/kernel/debug/kunit/kprobes_test/run, followed closely by messages such as kprobes_test failures, register_kprobe returning -22, EXPECTATION FAILED in lib/tests/test_kprobes.c, or Unable to handle kernel paging request. Because exploitation requires privileged local interaction with kernel debug/test interfaces, also investigate who mounted debugfs, who accessed KUnit paths, and whether the activity occurred during legitimate kernel testing or CI automation.

• /sys/kernel/debug/kunit/kprobes_test/run
• echo 1 > /sys/kernel/debug/kunit/kprobes_test/run
• kprobes_test
• test_kprobe: EXPECTATION FAILED at lib/tests/test_kprobes.c:64
• register_kprobe(&kp) == -22
• register_kprobe
• Unable to handle kernel paging request
• Kernel panic
• kernel BUG
• Oops
• /sys/kernel/debug/kunit
• /sys/kernel/debug

What your security team should do

• Prioritize patching for systems that run custom, test, debug, lab, CI, or development kernels with KUnit and kprobes test support enabled.
• For production systems, disable or avoid mounting debugfs unless it is explicitly required for operations or monitoring.
• Restrict local administrative access and audit use of kernel debug/test interfaces.
• Review kernel configuration baselines to ensure KUnit test code and kernel self-test interfaces are not included in hardened production builds unless needed.
• Monitor kernel logs for kprobes_test failures, register_kprobe errors, kernel oops events, paging faults, and unexpected reboots.
• Handle remediation through standard kernel update cycles for typical production systems because the vulnerability is low-likelihood, not KEV-listed, not associated with ransomware, and has very low EPSS probability.