7.8
CVE-2026-23248
- EPSS 0.12%
- Veröffentlicht 18.03.2026 10:05:10
- Zuletzt bearbeitet 21.05.2026 18:45:54
- Quelle 416baaa9-dc9f-4396-8d5f-8c081f
- CVE-Watchlists
- Unerledigt
perf/core: Fix refcount bug and potential UAF in perf_mmap
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix refcount bug and potential UAF in perf_mmap Syzkaller reported a refcount_t: addition on 0; use-after-free warning in perf_mmap. The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection). In perf_mmap(), the ring_buffer (rb) is allocated and assigned to event->rb with the mmap_mutex held. The mutex is then released to perform map_range(). If map_range() fails, perf_mmap_close() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning. Fix this by extending the scope of mmap_mutex to cover the map_range() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.
Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Linux ≫ Linux Kernel Version >= 6.14 < 6.18.17
Linux ≫ Linux Kernel Version >= 6.19 < 6.19.7
Linux ≫ Linux Kernel Version7.0 Updaterc1
VulnDex Vulnerability Enrichment
| Typ | Quelle | Score | Percentile |
|---|---|---|---|
| EPSS | FIRST.org | 0.12% | 0.021 |
| Quelle | Base Score | Exploit Score | Impact Score | Vector String |
|---|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 1.8 | 5.9 |
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
|
CWE-416 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
https://git.kernel.org/stable/c/c27dea9f50ed525facb62ef647dddc4722456e07
https://git.kernel.org/stable/c/ac7ecb65af170a7fc193e7bd8be15dac84ec6a56
https://git.kernel.org/stable/c/77de62ad3de3967818c3dbe656b7336ebee461d2