CVE-2025-38349
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-18

Last updated on: 2025-11-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "ep_free(ep)" until after it has unlocked the mutex. But it's wrong for the much subtler "next to last" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: "mutex_unlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutex_unlock() context is not using the structure anymore" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-18
Last Modified
2025-11-18
Generated
2026-05-07
AI Q&A
2025-07-18
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38349
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 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.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free issue in the Linux kernel's eventpoll (epoll) implementation. The problem occurs because the epoll code decrements the epoll reference count while still holding the epoll mutex, then unlocks the mutex afterward. This sequence is unsafe because if the reference count is not the last one, another thread can free the epoll object while the mutex is still being unlocked, leading to use-after-free. The fix involves moving the decrement of the reference count outside the mutex lock, as the reference count is atomic and does not require mutex protection.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the Linux kernel, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code or escalate privileges by exploiting the freed memory being reused improperly.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by updating the Linux kernel to a version where the epoll reference count decrement is moved outside the mutex unlock operation. Immediate mitigation involves applying the kernel patch or upgrading to the fixed kernel version that resolves this issue.


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