CVE-2026-46196

What it actually does

This is a local Linux kernel denial-of-service flaw in tracepoint registration error handling. When a tracepoint transitions from having no probes to having one probe, the kernel calls the tracepoint subsystem registration callback before installing the probe. If probe installation then fails, such as during memory pressure when allocation returns ENOMEM, the kernel previously failed to call the matching unregister callback. That leaves persistent subsystem state enabled even though no probe was installed. For syscall tracepoints, this can leave syscall tracing marked active for every task, causing ongoing syscall entry and exit overhead until reboot. The impact is availability degradation rather than data theft or privilege escalation.

Why it matters to the business

An attacker with local access can potentially force a system into a degraded state where every process pays additional kernel tracing overhead, reducing application throughput and increasing latency until the host is rebooted or patched. This is most relevant to multi-user Linux systems, shared compute platforms, CI/build workers, container hosts, and performance-sensitive production servers. The issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, but it can still matter operationally because the degraded state may persist and be difficult to distinguish from ordinary resource contention.

How an attack unfolds

An attacker first obtains the ability to run local code as an unprivileged or low-privileged user on a vulnerable Linux system. They then repeatedly exercise interfaces that add tracepoint probes, such as tracing, perf, or eBPF-related workflows where permitted by system policy, while also creating memory pressure to increase the likelihood that the kernel allocation in the probe-add path fails. In the vulnerable path, the kernel registration callback has already enabled subsystem state, but the subsequent probe installation fails. Because the unregister callback is not invoked on that failure path, the system is left with tracing-related side effects active without a corresponding installed probe. For syscall tracepoints, this can leave syscall tracing overhead enabled across tasks, causing persistent CPU overhead and degraded performance until the affected state is cleared by reboot or the kernel is replaced with a fixed version.

How to fix it

Upgrade to a kernel build that includes the upstream fix balancing regfunc() with unregfunc() when func_add() fails in tracepoint_add_func(). If vendor fixed package versions are not yet available, track the Linux distribution advisory for this CVE and apply the first kernel update that includes the tracepoint cleanup fix. Because the lingering state may persist until reboot, schedule a reboot after applying the fixed kernel. As interim mitigation, reduce untrusted local access, restrict access to tracing and perf facilities, disable or tightly control unprivileged eBPF where applicable, and apply hardening such as kernel.perf_event_paranoid, kernel.unprivileged_bpf_disabled, lockdown mode, and container policies that prevent access to debugfs, tracefs, BPF, and perf interfaces. These mitigations reduce exploitability but do not replace the kernel fix.

How to confirm the fix worked

Confirm the running kernel is from a vendor build that includes the fix for this tracepoint registration cleanup issue. Validate both the installed package version and the active running kernel using package-manager output and uname -r, because installing a kernel package without rebooting leaves the vulnerable kernel running. Review distribution changelogs or source patches for the tracepoint_add_func() error-path change that calls the matching unregfunc() after func_add() failure. Confirm untrusted users and containers cannot access /sys/kernel/tracing, /sys/kernel/debug/tracing, perf_event_open, or unprivileged eBPF unless explicitly required. After remediation and reboot, monitor syscall-heavy workload performance to ensure there is no persistent tracing overhead left from a previous failed registration path.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as a regular or low-privileged user.
2. Identify whether tracing, perf, ftrace, eBPF, or related tracepoint interfaces are accessible under local policy.
3. Create memory pressure to make kernel probe-array allocation failures more likely.
4. Attempt to add syscall or other tracepoint probes repeatedly until the tracepoint add path fails after the registration callback has already run.
5. Leave the system in a state where tracepoint subsystem side effects remain active without a valid probe.
6. Benefit from degraded system performance, increased syscall overhead, and operational disruption until reboot or remediation.

How to detect it

There is no single definitive log entry that proves exploitation, and successful triggering may not produce a kernel message. Hunt retrospectively by correlating three signals: unexpected use of tracing/performance tooling, memory allocation pressure or ENOMEM events, and a persistent increase in syscall overhead or CPU usage after the tracing process exits. Useful sources include auditd execve records, shell history where available, process accounting, EDR telemetry, systemd journal, kernel logs, eBPF/perf monitoring logs, container runtime audit logs, and access logs for tracefs or debugfs if file auditing is enabled. Look for untrusted users invoking perf, trace-cmd, bpftrace, or custom programs that interact with tracepoint or perf_event_open interfaces shortly before unexplained performance degradation. Also inspect whether tracefs/debugfs was mounted into containers unexpectedly. For forensic triage, compare the timing of OOM or allocation failures with tracepoint enablement attempts and sustained syscall-heavy CPU overhead. Absence of these artifacts does not rule out exploitation because the vulnerable code path is internal to the kernel and may fail silently.

• /sys/kernel/tracing/events/syscalls/enable
• /sys/kernel/debug/tracing/events/syscalls/enable
• /sys/kernel/tracing/events/syscalls/
• /sys/kernel/debug/tracing/events/syscalls/
• /sys/kernel/tracing/kprobe_events
• /sys/kernel/debug/tracing/kprobe_events
• /sys/kernel/tracing/uprobe_events
• /sys/kernel/debug/tracing/uprobe_events
• perf_event_open
• bpftrace
• trace-cmd
• perf trace
• perf record
• tracepoint_add_func
• func_add
• allocate_probes
• ENOMEM
• Cannot allocate memory
• SYSCALL_TRACEPOINT
• syscall_regfunc
• sys_tracepoint_refcount

What your security team should do

• Prioritize patching shared Linux hosts, container nodes, build systems, HPC systems, and performance-sensitive servers where local users or workloads are not fully trusted.
• Verify that the fixed kernel is actually running after patch deployment; require reboot or live-patching validation where applicable.
• Restrict access to tracefs, debugfs, perf, ftrace, and unprivileged eBPF for non-administrative users and containers.
• Harden sysctl and kernel security settings, including kernel.perf_event_paranoid and kernel.unprivileged_bpf_disabled, according to application requirements.
• Monitor for unusual local tracing activity combined with memory pressure, especially from unexpected users, containers, CI jobs, or short-lived processes.
• Investigate unexplained persistent CPU overhead or syscall latency increases that remain after tracing tools have exited.
• Because this is not KEV-listed and has low EPSS, treat it as a medium-priority availability issue unless exposed on multi-tenant or high-criticality Linux platforms, where priority should be raised.