CVE-2026-46242
Received Received - Intake
Use-After-Free in Linux Kernel eventpoll

Publication date: 2026-05-30

Last updated on: 2026-05-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-30
Last Modified
2026-05-30
Generated
2026-05-30
AI Q&A
2026-05-30
EPSS Evaluated
N/A
NVD
CVE-2026-46242
EUVD
EUVD-2026-33459
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free (UAF) issue in the Linux kernel's eventpoll subsystem, specifically in the ep_remove() function. The problem occurs because ep_remove() clears a pointer (file->f_ep) under a lock but continues to use the file structure inside the critical section. Concurrently, another function (__fput()) may observe this cleared pointer and skip necessary cleanup steps, leading to the freeing of memory that is still in use.

This results in subsequent operations writing into freed memory, causing memory corruption. Additionally, the file structure can be recycled and reinitialized while still in use, allowing an attacker to manipulate kernel memory caches incorrectly.

The fix involves pinning the file structure at the start of ep_remove() to prevent it from being freed while still in use, ensuring proper synchronization and preventing the use-after-free condition.


How can this vulnerability impact me? :

This vulnerability can lead to memory corruption in the Linux kernel, which may be exploitable by an attacker to cause system instability, crashes, or potentially execute arbitrary code with kernel privileges.

Because it involves use-after-free and improper memory handling, an attacker with the ability to trigger this vulnerability could compromise the security and reliability of the affected system.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved by changes in the Linux kernel's eventpoll subsystem, specifically by pinning the file structure at the start of ep_remove() to prevent use-after-free conditions.

Immediate mitigation steps would typically include updating the Linux kernel to a version that contains this fix.


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