CVE-2026-43409

What it actually does

This is a local Linux kernel denial-of-service flaw in the interaction between kprobes and ftrace. If ftrace has been disabled internally after an error, subsequent removal or insertion of kernel modules that have kprobes associated with ftrace can trigger an invalid memory access in the kprobes module notifier path, causing a kernel oops or crash. The primary impact is loss of availability; the vulnerability does not directly provide confidentiality or integrity compromise based on the published details.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, applications, and infrastructure services running on those hosts. Because exploitation requires local access and the ability to interact with kernel tracing/module functionality, this is most relevant for multi-user Linux systems, developer/build hosts, systems allowing privileged containers or module operations, and environments where untrusted users can obtain elevated Linux capabilities. It is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is unlikely, but the operational impact of a crash can still be significant for critical servers.

How an attack unfolds

An attacker first needs local execution on an affected Linux host with sufficient privileges or Linux capabilities to manipulate tracing/kprobe state and trigger kernel module load or unload activity. The attacker causes or waits for ftrace to enter a killed/disabled state after an internal error, leaving the kprobe/ftrace integration in a vulnerable condition. They then remove or insert a module associated with kprobe probes, for example through rmmod, insmod, or modprobe. During module notification handling, the kernel reaches the kprobes module callback and attempts ftrace-related operations despite ftrace being disabled, resulting in an invalid memory access and a kernel crash. The exploit outcome is service disruption rather than code execution according to the available advisory information.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for the kprobes/ftrace module callback handling. No exact fixed package versions were provided in the input, so use the relevant distribution vendor advisory and install the latest patched kernel for each affected release stream, then reboot into the updated kernel. As mitigations until patching is complete, restrict local shell access, limit sudo rights for module and tracing operations, prevent untrusted users and containers from receiving capabilities such as CAP_SYS_MODULE, CAP_SYS_ADMIN, or access to kernel tracing interfaces, disable unnecessary kernel module loading where operationally feasible, and restrict access to /sys/kernel/debug/tracing and /sys/kernel/tracing.

How to confirm the fix worked

Confirm that systems are running a patched kernel from the relevant Linux distribution or vendor advisory, not merely that the package has been installed. Validate with uname -r, package manager kernel version checks, and a reboot verification step. Review whether untrusted users can execute rmmod, insmod, modprobe, or write to kprobe tracing interfaces. Where safe in a non-production test environment, reproduce the previously vulnerable sequence using kprobes/ftrace and module unload/load operations to confirm the kernel no longer crashes. Also confirm that debugfs/tracing mounts and Linux capabilities are appropriately restricted for non-administrative users and containers.

Typical attack path

1. Obtain local shell access on an affected Linux system.
2. Acquire or abuse privileges/capabilities that permit kernel tracing, kprobe interaction, or kernel module load/unload operations.
3. Create or manipulate kprobes that use ftrace, or target a system where such probes already exist.
4. Cause ftrace to enter a killed/disabled state due to an error condition.
5. Run module insertion or removal operations such as insmod, rmmod, or modprobe against a module associated with kprobes.
6. Trigger the vulnerable kprobes module callback path and crash the kernel, causing denial of service.

How to detect it

Look for evidence of kernel crashes or oops events around module load/unload activity and tracing/kprobe usage. Useful sources include kernel ring buffer output, journald kernel logs, syslog, auditd, EDR telemetry, crash dump infrastructure, sudo logs, shell history, and container runtime logs for privileged capability use. Search for kernel oops traces containing kprobes_module_callback, ftrace_kill, __do_sys_delete_module, rmmod, insmod, or modprobe near the time of a reboot, panic, watchdog reset, or service outage. In audit logs, review executions of /sbin/rmmod, /sbin/insmod, /sbin/modprobe, writes to kprobe_events, and suspicious access to /sys/kernel/debug/tracing or /sys/kernel/tracing by non-standard users, automation, or containers. If crash dumps are available, inspect the stack trace for the kprobes module notifier path and correlate it with recent module operations and ftrace errors.

• kprobes_module_callback
• RIP: 0010:kprobes_module_callback
• __do_sys_delete_module
• blocking_notifier_call_chain
• notifier_call_chain
• ftrace_kill
• kprobe_ftrace_disabled
• __disarm_kprobe_ftrace
• BUG: unable to handle page fault
• Oops: Oops: 0000
• Comm: rmmod
• /sbin/rmmod
• /usr/sbin/rmmod
• /sbin/insmod
• /usr/sbin/insmod
• /sbin/modprobe
• /usr/sbin/modprobe
• /sys/kernel/debug/tracing/kprobe_events
• /sys/kernel/tracing/kprobe_events

What your security team should do

• Inventory Linux systems running affected kernel versions and prioritize systems that allow local users, privileged containers, kernel module management, or tracing/debug access.
• Apply vendor kernel updates that include the kprobes/ftrace fix and reboot systems into the patched kernel.
• Temporarily restrict rmmod, insmod, modprobe, kprobe, ftrace, debugfs, and tracing access to trusted administrators only.
• Audit sudoers, container runtime profiles, and Linux capabilities to ensure untrusted workloads do not have CAP_SYS_MODULE, CAP_SYS_ADMIN, or equivalent host-level privileges.
• Monitor kernel logs for crashes referencing kprobes_module_callback, ftrace_kill, rmmod, insmod, or module notifier call traces.
• Treat unexpected kernel oops/panic events during module unload/load activity as potential exploitation or unsafe local activity and preserve logs for investigation.