CVE-2026-99238
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Nov 2, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's tracing feature could let a user who is already logged into the computer take over the whole system or make it crash.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition allowing trace_module_record() to walk the ftrace_trace_arrays list without trace_types_lock, enabling concurrent rmdir of a persistent instance to free the structure while a module load or unload notifier still references it, resulting in use-after-free.
Why it matters to the business
Local attackers on Linux systems may achieve privilege escalation or kernel crashes. The issue affects any kernel build with tracing and persistent instances enabled; its very recent disclosure and lack of known exploits mean organizations should treat it as an emerging local kernel risk requiring prompt patching.
How an attack unfolds
A local attacker creates persistent trace instances, then races rmdir operations against module load/unload events so that the notifier walks into a trace_array that has already been removed and freed under the lock.
How to fix it
Apply the upstream fix that acquires trace_types_lock before walking ftrace_trace_arrays inside the module notifier; update to a patched kernel release from your distribution or mainline once available and rebuild any custom kernels that include tracing support.
How to confirm the fix worked
Confirm the patched kernel source holds trace_types_lock around the ftrace_trace_arrays iteration in the module notifier path; perform stress testing that concurrently removes trace instances while loading and unloading modules.
Typical attack path
- Obtain local shell access on the target Linux system
- Create one or more persistent trace instances
- Concurrently issue rmdir on those instances while triggering module load or unload
- Trigger the use-after-free to corrupt kernel memory or hijack control flow
How to detect it
Review kernel logs for oops or warnings originating from the tracing or ftrace subsystems that coincide with module load or instance removal events; look for unusual patterns of trace instance creation and deletion in audit or syslog records.
What your security team should do
- Schedule kernel updates for all Linux hosts as soon as a fixed package is released by the distribution
- Limit unprivileged module loading via LSM or kernel configuration where feasible
- Audit systems for use of persistent trace instances and disable them if not required
- Watch upstream commits and distribution advisories for the exact fixed version
The record
In the Linux kernel, the following vulnerability has been resolved: tracing: Hold trace_types_lock when updating modules in persistent instances trace_module_record() walks ftrace_trace_arrays from the module notifier without trace_types_lock. A concurrent rmdir of an instance removes it from the list and frees it under that lock, so a module load or unload can walk into a freed trace_array.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|