https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 03:31:19 +0000 https://db.gcve.eu/vuln/cve-2026-23248 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>perf/core: Fix refcount bug and potential UAF in perf_mmap</p> <p>Syzkaller reported a refcount_t: addition on 0; use-after-free warning in perf_mmap.</p> <p>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).</p> <p>In perf_mmap(), the ring_buffer (rb) is allocated and assigned to event-&gt;rb with the mmap_mutex held. The mutex is then released to perform map_range().</p> <p>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-&gt;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.</p> <p>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.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>perf/core: Fix refcount bug and potential UAF in perf_mmap</p> <p>Syzkaller reported a refcount_t: addition on 0; use-after-free warning in perf_mmap.</p> <p>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).</p> <p>In perf_mmap(), the ring_buffer (rb) is allocated and assigned to event-&gt;rb with the mmap_mutex held. The mutex is then released to perform map_range().</p> <p>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-&gt;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.</p> <p>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.</p> https://db.gcve.eu/vuln/cve-2026-23248