CVE-2026-46196
Awaiting Analysis Awaiting Analysis - Queue
Linux Kernel Tracepoint Registration Failure Leads to Persistent State

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's tracepoint subsystem. When a tracepoint transitions from inactive (0) to active (1), the function tracepoint_add_func() calls a registration function (regfunc()) before trying to install a new probe using func_add(). If func_add() fails, for example due to memory allocation failure, the error is returned without calling the corresponding unregistration function (unregfunc()). This leaves behind side effects from regfunc() even though no probe was successfully installed.

Specifically for syscall tracepoints, the registration function increments a reference count and sets a flag on every task. If the failure occurs, the reference count remains stuck at a non-zero value with no actual consumer, causing every task to continue incurring syscall trace overhead until the system is rebooted. Other subsystems with similar regfunc()/unregfunc() pairs can also leave persistent state due to this issue.


How can this vulnerability impact me? :

This vulnerability can cause persistent resource and performance issues on affected Linux systems. Because the reference count remains incorrectly incremented and the tracepoint flag remains set on every task, all tasks continue to pay the overhead of syscall tracing even though no probe is active.

This results in unnecessary CPU overhead and degraded system performance until the system is rebooted to clear the stuck state. In environments with high memory pressure, this failure and its side effects are more likely to occur.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by ensuring that the ext->unregfunc() is called in the func_add() error path to clean up side effects when probe installation fails.

Immediate mitigation steps would involve updating the Linux kernel to a version that includes this fix, as the issue arises from the kernel's tracepoint handling code.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart