CVE-2026-46196: Linux Kernel Tracepoint State Leak and Performance Degradation

Technical summary

The vulnerability exists in the tracepoint_add_func() function in the Linux kernel's tracepoint infrastructure. When a tracepoint transitions from having zero to one active consumer, the kernel invokes ext->regfunc() to perform subsystem-specific setup (such as incrementing reference counts or setting per-task flags). If the subsequent func_add() call fails—typically due to memory allocation failure in allocate_probes()—the function returns without invoking the corresponding ext->unregfunc() cleanup. For syscall tracepoints, this means syscall_regfunc() has already incremented sys_tracepoint_refcount and set the SYSCALL_TRACEPOINT flag on all tasks, but these changes are never reversed. The result is orphaned kernel state that imposes ongoing CPU overhead and cannot be cleared without rebooting. The fix mirrors the existing 1→0 transition cleanup logic by calling ext->unregfunc() in the error path when func_add() fails after regfunc() has been invoked.

Business impact

While not exploitable for privilege escalation or data theft, this vulnerability can severely degrade system performance under adverse conditions. On production systems making heavy use of tracepoints or experiencing memory pressure, a failed probe installation leaves the kernel in a state where every syscall and tracepoint operation incurs unnecessary overhead. This can manifest as increased latency, reduced throughput, and higher CPU utilization across all workloads. Systems relying on dynamic tracepoint instrumentation—such as those running eBPF-based monitoring, observability agents, or kernel debugging tools—are at elevated risk of triggering the failure condition and suffering persistent performance degradation without operator awareness. The only remedy is a reboot.

Affected systems

All Linux kernel versions that include the tracepoint subsystem are potentially affected. The vulnerability specifically impacts the syscall tracepoint implementation and any other subsystem that defines regfunc()/unregfunc() pairs for registration state management. Systems under sustained memory pressure or those frequently enabling and disabling tracepoints are most likely to encounter the failure path. Check the Linux kernel advisory and your vendor's patch announcements for the specific kernel versions and stable release branches addressed.

Exploitability

This is not an exploitability issue in the traditional sense—there is no code execution, privilege escalation, or information disclosure vector. However, it is easily triggerable by any local user or administrator with permissions to manage tracepoints or run workloads that cause memory allocation failures. The condition can occur naturally during system memory pressure, making it a denial-of-service risk rather than a security boundary violation. Once triggered, the degradation persists without further action from an attacker, making detection of malicious intent difficult.

Remediation

Apply the Linux kernel patch that adds the missing ext->unregfunc() call in the error handling path of tracepoint_add_func(). This ensures that when func_add() fails after regfunc() has been invoked, the corresponding cleanup is performed symmetrically. Affected deployments should prioritize patching systems that make active use of dynamic tracepoint instrumentation, eBPF monitoring, or observability agents. After patching and rebooting, verify that tracepoint registration succeeds and that no orphaned state persists by monitoring sys_tracepoint_refcount and syscall overhead metrics.

Patch guidance

Obtain the Linux kernel update from your distribution's kernel repository or from kernel.org's stable release trees. The patch applies to the tracepoint subsystem and is typically included in stable kernel releases that address this issue. Verify the patch commit hash against the upstream Linux kernel repository to confirm authenticity. After applying the patch and rebuilding the kernel, reboot to load the new kernel image. If your system is currently in a degraded state due to this issue, rebooting to the patched kernel will clear the orphaned state.

Detection guidance

Monitor sys_tracepoint_refcount via sysctl or kernel module inspection to detect abnormally elevated values when no tracepoint consumers are actively registered. Use tools like bpftrace or perf to profile syscall entry/exit overhead and establish baseline metrics; persistent overhead above baselines may indicate orphaned tracepoint state. Review kernel logs and memory allocation failure warnings (OOM, ENOMEM) that occur during tracepoint registration attempts. In environments with strict observability, correlate sudden increases in CPU usage or syscall latency with recent attempts to enable or modify tracepoints via perf, eBPF tools, or systemtap. Implement alerts for sustained elevation in these metrics that cannot be correlated with active tracepoint consumers.

Why prioritize this

Although the CVSS score is MEDIUM (5.5) and the vulnerability does not enable direct exploitation, its impact on system performance and the difficulty in remediating without a reboot make it a priority for systems that depend on stable, predictable performance. The vulnerability is particularly critical for production environments running observability platforms, eBPF agents, or kernel tracing tools that regularly register and unregister tracepoints. The fact that an orphaned state persists until reboot elevates its operational risk, even if it does not pose an immediate security boundary violation. Prioritize patching on systems likely to encounter memory pressure or dynamic tracepoint churn.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects a local attack vector, low attack complexity, and requirement for low privileges, with high availability impact but no confidentiality or integrity impact. The score appropriately captures that this is a denial-of-service / availability degradation issue triggered by memory allocation failures or tracepoint registration sequences. However, the practical impact on production systems—especially those running continuous observability infrastructure—may warrant elevated prioritization despite the MEDIUM baseline score. Organizations should adjust their internal risk ratings based on their deployment of tracepoint-dependent tools and their tolerance for performance degradation.

Frequently asked questions