CVE-2026-68146

What it actually does

This is a Linux kernel race condition in the ftrace tracing subsystem. When a userspace process opens certain ftrace control files and shares the resulting file descriptor across multiple threads, concurrent writes can race while using the same trace_parser object. The affected open, write, and release paths include ftrace_regex_open(), ftrace_graph_open(), ftrace_regex_write(), ftrace_graph_write(), ftrace_regex_release(), and ftrace_graph_release(). The race corrupts parser state fields such as idx, cont, and buffer, which can cause malformed parsing, undefined behavior, and potentially kernel instability depending on how the corrupted state is consumed. The upstream fix serializes access to trace_parser with a global parser_lock mutex across write and release paths.

Why it matters to the business

The most likely operational impact is local system instability or denial of service on Linux systems where untrusted or low-privileged users can access ftrace interfaces. Because ftrace is commonly used for diagnostics, performance tracing, kernel debugging, and observability workflows, exploitation could disrupt troubleshooting systems or shared compute environments. No public exploitation or CISA KEV listing is indicated, and exploit maturity is currently reported as none, so urgency is lower than for internet-facing remote code execution vulnerabilities; however, kernel-level race conditions should still be prioritized in multi-user, container-host, development, CI/CD, research, and high-density compute environments.

How an attack unfolds

An attacker first needs local access to a Linux system and sufficient permission to open the affected ftrace files, typically through tracefs/debugfs tracing interfaces. They open an affected ftrace control file through the regex or graph tracing paths, then share the same file descriptor across multiple attacker-controlled threads. Those threads repeatedly issue concurrent write operations with crafted or conflicting input so that the shared trace_parser state is modified simultaneously. Because the parser was not protected by a mutex, the internal idx, cont, and buffer fields can become inconsistent. The corrupted parser state may result in incorrect tracing configuration, unexpected kernel behavior, or a local denial-of-service condition. Successful exploitation depends heavily on local permissions, ftrace availability, kernel configuration, and timing.

How to fix it

Update the Linux kernel to a version that includes the upstream fix adding parser_lock serialization around trace_parser access in the ftrace write and release paths. Use vendor-supported kernel updates from the operating system distributor rather than manually patching production kernels. If exact fixed package versions are not yet available for a distribution, monitor the vendor security advisory stream and apply the first kernel build that backports the ftrace parser locking fix for this issue. As interim mitigations, restrict access to tracefs/debugfs tracing interfaces, avoid granting tracing capabilities to untrusted users or containers, unmount debugfs/tracefs where not required, and limit CAP_SYS_ADMIN/CAP_PERFMON or equivalent privileges that can expose kernel tracing functionality.

How to confirm the fix worked

Confirm the running kernel includes the ftrace trace_parser locking fix by checking the installed kernel package changelog or vendor advisory for this issue or for the ftrace parser_lock patch. Verify the running kernel version after reboot with uname -r and ensure it matches the remediated vendor build. Validate that tracefs/debugfs permissions restrict untrusted access by reviewing mounts such as /sys/kernel/tracing and /sys/kernel/debug/tracing. Where practical in a non-production test environment, attempt concurrent writes to affected ftrace files before and after patching and confirm the patched kernel remains stable and serializes access. Also confirm that no untrusted containers or users retain access to host tracing interfaces.

Typical attack path

1. Gain local code execution on a Linux host as a user or process with access to ftrace tracing interfaces.
2. Verify that tracefs or debugfs tracing files are mounted and accessible.
3. Open an affected ftrace control file that reaches ftrace_regex_open() or ftrace_graph_open().
4. Share the opened file descriptor across multiple threads within the same process.
5. Trigger concurrent writes through ftrace_regex_write() or ftrace_graph_write() using racing inputs.
6. Corrupt the shared trace_parser state, including fields such as idx, cont, or buffer.
7. Use the resulting undefined behavior to cause tracing malfunction, kernel instability, or denial of service.

How to detect it

Investigate whether untrusted or unexpected local processes accessed ftrace interfaces before patching. Useful sources include Linux auditd logs, eBPF or EDR telemetry, process execution logs, shell history for privileged users, container runtime audit logs, and file access monitoring for tracefs/debugfs. Look for repeated or concurrent writes to ftrace control files under /sys/kernel/tracing or /sys/kernel/debug/tracing, especially files related to function filtering or graph tracing. Review kernel logs for crashes, warnings, lockups, oopses, soft lockups, hung tasks, or tracing-related errors around the same time as suspicious ftrace activity. If audit rules were not already configured, post-incident detection may be limited because normal Linux systems do not log all writes to tracefs by default. There are no public threat actors or campaigns currently associated with this issue in the provided data.

• /sys/kernel/tracing/set_ftrace_filter
• /sys/kernel/tracing/set_ftrace_notrace
• /sys/kernel/tracing/set_graph_function
• /sys/kernel/tracing/set_graph_notrace
• /sys/kernel/debug/tracing/set_ftrace_filter
• /sys/kernel/debug/tracing/set_ftrace_notrace
• /sys/kernel/debug/tracing/set_graph_function
• /sys/kernel/debug/tracing/set_graph_notrace
• ftrace_regex_write
• ftrace_graph_write
• ftrace_regex_open
• ftrace_graph_open
• ftrace_regex_release
• ftrace_graph_release
• trace_parser
• kernel: BUG:
• kernel: WARNING:
• kernel: Oops:
• kernel: soft lockup
• kernel: hung task
• kernel: ftrace

What your security team should do

• Prioritize patching on shared Linux systems, container hosts, CI/CD runners, bastion hosts, developer workstations, HPC clusters, and any environment where untrusted local users can run code.
• Track Linux distribution advisories and deploy the first supported kernel update that backports the ftrace trace_parser mutex fix.
• Restrict or disable access to /sys/kernel/tracing and /sys/kernel/debug/tracing unless explicitly required for operations.
• Review container and sandbox configurations to ensure host tracefs/debugfs paths are not mounted into untrusted workloads.
• Audit users and services with elevated tracing-related privileges such as broad administrative capabilities, privileged containers, or access to debugfs/tracefs.
• Monitor for abnormal ftrace file access patterns, especially concurrent or repeated writes to tracing control files by unexpected processes.
• Because there is no current KEV listing, ransomware association, or known public exploit maturity, handle as important kernel hardening rather than an emergency internet-exposure incident unless local untrusted access is present.