CVE-2026-23380
Received Received - Intake
Reference Count Error in Linux Kernel Tracing Causes WARN_ON

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close When a process forks, the child process copies the parent's VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON. Normally, this isn't an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork. Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA's open callback.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-06
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.10
linux linux_kernel From 6.19 (inc) to 6.19.7 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.17 (exc)
linux linux_kernel From 6.10.1 (inc) to 6.12.77 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-617 The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's tracing subsystem. When a process forks, the child process copies the parent's virtual memory areas (VMAs), but the user_mapped reference count is not incremented accordingly. As a result, when both the parent and child processes exit, the function tracing_buffers_mmap_close() is called twice. On the second call, the user_mapped count is already zero, causing the function to return an error (-ENODEV) and triggering a WARN_ON warning.

Normally, this issue does not occur because the memory is mapped with the VM_DONTCOPY flag, which prevents copying on fork. However, if an application calls madvise(MADV_DOFORK), it resets the VM_DONTCOPY flag, allowing this vulnerability to be triggered during a fork.

The fix involves incrementing the user_mapped reference count properly without re-mapping the pages in the VMA's open callback to prevent the double call issue.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to trigger a WARN_ON warning and return an error during process exit when certain memory mappings are involved. This may lead to instability or unexpected behavior in applications that use the tracing subsystem and call madvise(MADV_DOFORK).

While it does not directly indicate a security breach like data leakage or privilege escalation, it can cause system warnings and potential disruptions in process management, which might affect system reliability.


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