Linux Kernel User-Mapped Reference Count Vulnerability in Tracing Buffers

Vulnerability

A vulnerability in the Linux kernel's handling of user-space mappings for trace buffers can lead to a WARN_ON condition. When a process forks, the child process duplicates the parent's virtual memory areas (VMAs) without increasing the user_mapped reference count. Consequently, when both processes terminate, the tracing_buffers_mmap_close() function is invoked twice. During the second call, the user_mapped count is already zero, causing the function to return -ENODEV and trigger a warning. This issue typically does not arise because the memory is mapped with the VM_DONTCOPY flag, which prevents copying during a fork. However, applications can reset this flag, potentially leading to the problem. The vulnerability has been addressed by modifying the VMA's open callback to increment the user_mapped reference count without re-mapping the pages.

Impact

The vulnerability can cause a warning to be triggered when the user_mapped reference count is not properly managed during process forking and termination.

Reproduction

To reproduce this vulnerability, an application must map a trace buffer into user space and then fork a process. After forking, the child process will inherit the VMA without the user_mapped reference count being updated. If the application then calls madvise(MADVISE_DOFORK), it can reset the VM_DONTCOPY flag, allowing the issue to occur when the parent and child processes exit. The WARN_ON condition can be observed during this process termination.

Remediation

The vulnerability has been fixed in the Linux kernel by updating the VMA's open callback to increment the user_mapped reference count without re-mapping the pages. Users should upgrade to the latest version of the Linux kernel where this fix is applied.

Added: Mar 25, 2026, 11:44 AM
Updated: Mar 25, 2026, 11:44 AM

Vulnerability Rating

Custom Algorithm
spread
9.0
impact
1.3
exploitability
4.3
remediation
7.7
relevance
4.7
threat
4.8
urgency
2.9
incentive
0.0

Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.