CVE-2022-50266: kprobes: Fix check for probe enabled in kill_kprobe()
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix check for probe enabled in kill_kprobe()
In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be
called always fails. This is because before that we set the
KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always
false.
The disarm_kprobe_ftrace() call introduced by commit:
0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
to fix the NULL pointer reference problem. When the probe is enabled, if
we do not disarm it, this problem still exists.
Fix it by putting the probe enabled check before setting the
KPROBE_FLAG_GONE flag.
Security readout for executives and security teams
Plain-English summary
CVE-2022-50266 is a Linux kernel kprobes defect. During probe removal, the kernel can skip disarming an enabled ftrace-backed probe, leaving a previously fixed NULL pointer dereference condition present. Business urgency is unclear because the source bundle provides no CVSS score, CWE, exploit report, or impact statement beyond the kernel bug fix.
Executive priority
Set priority after asset inventory. This is a kernel-level reliability and safety issue with incomplete severity data, so prioritize internet-facing or production-critical Linux hosts once affected kernel presence is confirmed.
Technical view
In kill_kprobe(), KPROBE_FLAG_GONE was set before checking whether the kprobe was enabled. That made !kprobe_disabled(p) always false, so disarm_kprobe_ftrace() was not called for enabled probes. The fix moves the enabled check before setting the gone flag, preserving the intended disarm path.
Likely exposure
Exposure is limited to Linux kernel environments matching the affected kernel versions or missing the referenced stable commits. The risk is most relevant on systems where kprobes and ftrace-backed probes are used by tracing, debugging, monitoring, or kernel instrumentation workflows.
Exploitation context
The bundle marks KEV as false and provides no cited evidence of active exploitation, public exploit availability, remote attack surface, or privilege requirement. Treat exploitability as unproven from these sources, not as impossible.
Researcher notes
The source only describes the root cause and stable fix. It does not provide CVSS, CWE, crash conditions, privilege model, or attack path. Analysis should stay tied to kprobes/ftrace behavior and confirmed kernel versions or commits.
Mitigation direction
Update affected Linux kernels using vendor-supported packages or stable releases.
Confirm the referenced kernel stable commits are included in deployed kernel builds.
Track distribution advisories for backports and supported fixed versions.
Avoid relying on unsupported custom kernels without verifying the kprobes fix.
Validation and detection
Inventory Linux kernel versions across servers, appliances, containers hosts, and build images.
Check whether deployed kernel source includes the referenced stable fixes.
Review monitoring or debugging tooling that uses kprobes or ftrace-backed probes.
Record affected assets separately from systems already on fixed vendor kernels.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-50266 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Sep 15, 2025, 14:21 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.