CVE-2026-23380
published 2026-03-25CVE-2026-23380: 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…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.11%
1.7th percentile
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.
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.19.8-1 (forky) | linux 6.19.8-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= cf9f0f7c4c5bb45e7bb270e48bab6f7837825a64 < 91f3e8d84c89918769e71393f839c9fefadc2580 | 91f3e8d84c89918769e71393f839c9fefadc2580 |
| linux | linux | >= cf9f0f7c4c5bb45e7bb270e48bab6f7837825a64 < cdd96641b64297a2db42676f051362b76280a58b | cdd96641b64297a2db42676f051362b76280a58b |
| linux | linux | >= cf9f0f7c4c5bb45e7bb270e48bab6f7837825a64 < b0f269ba6fefe9e3cb9feedcf78fcd0b633800c0 | b0f269ba6fefe9e3cb9feedcf78fcd0b633800c0 |
| linux | linux | >= cf9f0f7c4c5bb45e7bb270e48bab6f7837825a64 < e39bb9e02b68942f8e9359d2a3efe7d37ae6be0e | e39bb9e02b68942f8e9359d2a3efe7d37ae6be0e |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.19.8-1 | 6.19.8-1 |
| linux | linux_kernel | >= 6.10.0 < 6.12.77 | 6.12.77 |
| linux | linux_kernel | >= 6.10.1 < 6.12.77 | 6.12.77 |
| linux | linux_kernel | >= 6.13 < 6.18.17 | 6.18.17 |
| linux | linux_kernel | >= 6.13.0 < 6.18.17 | 6.18.17 |
| linux | linux_kernel | >= 6.19 < 6.19.7 | 6.19.7 |
| linux | linux_kernel | >= 6.19.0 < 6.19.7 | 6.19.7 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vendor_redhat3.3LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: tracing: Fix WARN_ON in tracing_buffers_mmap_close
vendor_redhat·2026-03-25·CVSS 3.3
CVE-2026-23380 [LOW] CWE-911 kernel: tracing: Fix WARN_ON in tracing_buffers_mmap_close
kernel: tracing: Fix WARN_ON in tracing_buffers_mmap_close
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
Debian
CVE-2026-23380: linux - In the Linux kernel, the following vulnerability has been resolved: tracing: Fi...
vendor_debian·2026
CVE-2026-23380 [LOW] CVE-2026-23380: linux - In the Linux kernel, the following vulnerability has been resolved: tracing: Fi...
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
OSV
tracing: Fix WARN_ON in tracing_buffers_mmap_close
osv·2026-03-25
CVE-2026-23380 tracing: Fix WARN_ON in tracing_buffers_mmap_close
tracing: Fix WARN_ON in tracing_buffers_mmap_close
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
GHSA
GHSA-q6xr-q445-2xxh: In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix WARN_ON in tracing_buffers_mmap_close
When a process forks, the chi
ghsa_unreviewed·2026-03-25
CVE-2026-23380 GHSA-q6xr-q445-2xxh: In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix WARN_ON in tracing_buffers_mmap_close
When a process forks, the chi
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
OSV
CVE-2026-23380: 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
osv·2026-03-25
CVE-2026-23380 CVE-2026-23380: 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
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
No detection rules found.
No public exploits indexed.
2026-03-25
Published