A subtle ordering bug in the Linux kernel's kprobes cleanup code quietly turned into a denial-of-service risk: CVE-2022-50266 patches a logic error in kill_kprobe so that ftrace-backed probes are properly disarmed before a probe is marked gone, preventing ftrace from referencing invalid probe state and crashing the kernel.
Kprobes is a low-level Linux kernel facility that lets developers and tracing tools insert dynamic instrumentation into nearly any kernel instruction. Kprobes and kretprobes are widely used by debuggers, perf tooling, and dynamic tracing frameworks; they can be registered by kernel modules or via the tracing debugfs interfaces and are powerful enough to change execution paths or capture runtime state. Because of their deep integration with the kernel execution path, correctness in kprobes code is critical—errors can cause immediate kernel OOPS/panic conditions. The specific issue fixed by CVE-2022-50266 concerns the interaction between kprobes and the ftrace backend used to implement some probes. A prior fix introduced a call to disarm_kprobe_ftrace to prevent NULL pointer dereferences in the ftrace handler; however, a later path in kill_kprobe sometimes set a probe's "gone" flag before checking whether the probe needed disarming. That ordering meant the disarm check always evaluated as "probe disabled", skipping disarm and allowing ftrace to operate on a stale or improperly-registered probepoint—producing warnings, failures to disarm, and ultimately kernel crashes that amount to a local denial-of-service.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
Kprobes is a low-level Linux kernel facility that lets developers and tracing tools insert dynamic instrumentation into nearly any kernel instruction. Kprobes and kretprobes are widely used by debuggers, perf tooling, and dynamic tracing frameworks; they can be registered by kernel modules or via the tracing debugfs interfaces and are powerful enough to change execution paths or capture runtime state. Because of their deep integration with the kernel execution path, correctness in kprobes code is critical—errors can cause immediate kernel OOPS/panic conditions. The specific issue fixed by CVE-2022-50266 concerns the interaction between kprobes and the ftrace backend used to implement some probes. A prior fix introduced a call to disarm_kprobe_ftrace to prevent NULL pointer dereferences in the ftrace handler; however, a later path in kill_kprobe sometimes set a probe's "gone" flag before checking whether the probe needed disarming. That ordering meant the disarm check always evaluated as "probe disabled", skipping disarm and allowing ftrace to operate on a stale or improperly-registered probepoint—producing warnings, failures to disarm, and ultimately kernel crashes that amount to a local denial-of-service. Technical analysis
What the code did wrong
At a high level, kill_kprobe is invoked when a probe is being removed—most commonly when the module that installed the probe is being unloaded. The function should:- detect whether the probe uses the ftrace backend,
- if so and if the probe is currently enabled, call disarm_kprobe_ftrace so ftrace stops tracking the probepoint,
- then mark the probe as gone and perform architecture-specific removal.
The surrounding patch and fixes
Patchsets merged into the stable trees moved the probe-enabled check ahead of setting the gone flag and added a guard for the global kprobes-all-disarmed state. The fix is intentionally small—reorder the disarm invocation so ftrace is always disarmed for enabled ftrace-based probes before setting KPROBE_FLAG_GONE. Kernel maintainers reviewed and backported this correction to multiple stable branches once the issue was recognized. The public patch notes and diffs show succinct edits to kernel/kprobes.c that remove the erroneous call site and add the corrected check in the module-going path.Why this causes availability loss (denial-of-service)
Because kprobes directly influence code paths executed on probe hits and on module unload, leaving ftrace with an inconsistent registration can provoke:- immediate WARNs during clean-up sequences (disarm failures),
- NULL pointer dereferences inside kernel tracing handlers,
- OOPS and kernel panic in the worst cases.
Affected systems and severity
- The root cause is in the upstream Linux kernel kprobes code; downstream distributions that package kernels based on the relevant upstream versions may be affected until they ship the corrected stable patch. Multiple vulnerability trackers and vendor advisories list the issue as resolved in patched kernel updates.
- Severity assessments differ slightly across sources but converge on medium-to-high impact driven by denial-of-service potential. For example, one vendor advisory (Amazon Linux) lists a CVSSv3 base score in the mid-range (6.4) with the attack vector classified as Local; other trackers mark Availability Impact as High. These differences reflect how vendors evaluate required privileges and exploit complexity rather than disagreement about the kernel behavior itself.
- This is not a remote network-facing flaw: the attack path requires local access and the ability to register or influence kprobes, or to trigger module unloads that cause kill_kprobe to run. In practice that means the attacker needs elevated local privileges or the ability to load/unload modules or control tracing interfaces. As such, this vulnerability is primarily a local privilege escalation/denial-of-service tool rather than a wormable remote exploit—its utility to attackers depends on their local capabilities on the target system.
Privilege requirements and exploitability — reconciling different assessments
Public trackers sometimes report varying "Privileges Required" values. The technical constraints that drive exploitability are:- Registering probes and manipulating ftrace typically requires elevated permissions. Kprobes are often installed from kernel modules (module init/exit), or via the tracing/debugfs interfaces that are normally only writable by root or processes with appropriate capabilities. The kernel tracing documentation and capability guides indicate these operations are administrative in nature and controlled by capabilities such as CAP_SYS_ADMIN and, for module loading, CAP_SYS_MODULE (and distribution-specific policies).
- In environments where containers or processes run with elevated capabilities (privileged containers, misconfigured seccomp or capability masks), an attacker in a container could potentially exercise kprobe registration or module unload behavior. Similarly, if a system allows unprivileged tracing or gives CAP_SYS_ADMIN to non-root actors, the effective attack surface grows.
Timeline and provenance
- The patch that specifically rearranged the disarm check appears in kernel stable history and associated patch logs; various backports and stable merges carry similar diffs across kernel trees. The fix is documented in kernel stable patch emails and stable trees, with maintainers marking it as a fix for prior logic introduced along with other kprobes/ftrace hardening commits.
- Public CVE assignment and vulnerability tracker entries for CVE-2022-50266 (despite the "2022" label) were published in vendor trackers and public databases later when the issue was bundled and analyzed for CVE assignment. That timeline difference is common for kernel issues: code fixes and discussions can predate formal CVE reservation and aggregator entry. Where you see a late CVE publication date in trackers, it typically reflects the date of formal CVE assignment and disclosure consolidation rather than the date the kernel diff landed.
Mitigation and remediation
Immediate remediation centers on applying upstream or vendor-supplied kernel updates that include the corrected kprobes ordering. Practical steps:- Install vendor kernel updates that include the fix. Major distributions and vendors have published advisories and backports; update guidance is distribution-specific. If you manage kernels directly, pick a stable upstream release that includes the fix or apply the kprobes.c patch and rebuild.
- Reduce attack surface by restricting who can register probes, load/unload modules, or write tracing control files:
- Ensure only trusted administrators have write access to /sys/kernel/debug/tracing and /sys/kernel/debug/kprobes.
- Drop unnecessary capabilities from containerized workloads (avoid CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_PERFMON where not needed).
- Use seccomp/AppArmor/SELinux profiles to forbid module insertion and tracing syscalls for untrusted processes.
- In high-security environments, consider disabling module loading (where feasible) or compiling the kernel without module support. This is a blunt instrument and may not be practical for general-purpose hosts but can remove the module-unload attack vector entirely. Use kernel boot parameters and initramfs hardening where appropriate.
- For immediate emergency mitigation (temporary), you can turn off kprobes globally via debugfs to prevent ftrace-backed probes from being armed (write "0" to /sys/kernel/debug/kprobes/enabled). This is disruptive—tracing and diagnostic tools will be affected—but may be appropriate while patching large fleets. The kprobes debugfs interface exposes this knob.
Detection and monitoring
- Watch for kernel WARNs and messages in dmesg that reference "Failed to disarm kprobe-ftrace" or call traces pointing at kernel/kprobes.c lines near __disarm_kprobe_ftrace or kill_kprobe. These specific log strings occur in testcases and real-world observations when the disarm call fails. Frequent WARNs in module unload sequences or repeated warnings tied to tracing indicates potential exposure or attempted exploitation.
- Monitor systems for unexpected module unloads/loads and for suspicious uses of tracing interfaces. Audit module events, monitor writes to /sys/kernel/debug/tracing, and arrange logging/alerting for capability escalations (CAP_SYS_ADMIN, CAP_SYS_MODULE use) on hosts that should not perform such operations. LSMs like SELinux or AppArmor can help enforce policies and produce audit events when capabilities are used.
Risk assessment for different environments
- Bare-metal servers and desktops: Moderate risk if only trusted local users exist—exploitation requires local privileges—but high if administrators allow broad tracing or have many untrusted local accounts. Patch promptly.
- Virtual machines and cloud images: If tenant users can load kernel modules (rare) or the host/kernel is misconfigured, the risk increases. For cloud providers, ensure hypervisor-managed kernels and guest kernels are patched. Amazon Linux advisories highlight varying status across their kernel streams; operators should consult their vendor guidance.
- Containers: The biggest practical risk is in privileged containers or misconfigured systems where containers inherit CAP_SYS_ADMIN or CAP_SYS_MODULE. Non-privileged containers generally do not allow module loading or direct kernel tracing, but some distros or runtimes may expose tracing debugfs to containers—this must be audited. Harden container runtimes to drop capabilities and disallow debugfs mounts for untrusted containers.
- WSL/WSL2 and desktop Linux on Windows: WSL2 uses a Microsoft-maintained Linux kernel image. Whether a specific WSL kernel image contains the fix depends on the exact kernel version shipped by Microsoft for WSL2 on that release. Administrators and users should watch their provider's kernel update notes and apply WSL/Windows updates that include patched kernel binaries where applicable. (Users running native Linux in virtual machines on Windows should treat those kernels like any other distribution kernel and patch accordingly. This statement is advisory: confirm WSL kernel versions and update timelines with your vendor.
Strengths of the fix and residual risks
- The fix is surgical and conservative: it reorders an existing check rather than introducing a heavy-handed code rewrite, minimizing regression risk. Kernel maintainers accepted and backported it across stable trees after review. This approach reduces the chance that the remediation itself introduces new semantics in kprobes behavior.
- Residual risk is operational. Because kprobes and ftrace touches low-level runtime state, the most significant danger is still human error and misconfiguration: systems that allow untrusted local users to manipulate tracing or load modules remain susceptible to crashes even after the fix if other kprobes/ftrace-related bugs exist. Operators should not rely solely on this patch to eliminate all tracing-related hazards; broader least-privilege controls and auditing are still required.
Practical checklist for administrators (quick actions)
- Identify kernel versions in use across servers and appliances. Cross-check with vendor advisories and apply kernel updates that include the kprobes ordering fix.
- Audit and harden capability sets for containers and services:
- Remove CAP_SYS_ADMIN / CAP_SYS_MODULE from non-administrative containers.
- Avoid privileged containers; do not mount /sys/kernel/debug into untrusted containers.
- Use LSMs (SELinux/AppArmor) and seccomp to block untrusted processes from invoking module load or tracing syscalls where possible.
- If immediate patching is impossible, consider temporarily disabling kprobes globally (echo 0 > /sys/kernel/debug/kprobes/enabled), with the understanding that tracing functionality will be impacted.
- Monitor kernel logs for disarm-related warnings and arrange for a rapid rollback to a patched kernel if an increase in relevant WARN/OOPS events appears.
Final assessment
CVE-2022-50266 is not a glamorous remote exploit vector—but it is a clear reminder of how ordering bugs in low-level kernel housekeeping can yield serious availability consequences. The fix is small and targeted, and distribution vendors have incorporated it into stable kernels; the highest-impact mitigation is to ensure your kernels are updated. However, defenders must also treat tracing and module-loading facilities as sensitive controls: enforce least privilege, harden container capability sets, and monitor kernel logs for new or unusual tracing-related WARNs. Taken together, timely patching plus operational hardening will remove the primary vector for denial-of-service from this kprobes logic bug while reducing the chance that similar instrumentation mistakes can be weaponized in the future.Source: MSRC Security Update Guide - Microsoft Security Response Center
