Skip to main content
Public proof of conceptFix available

CVE-2026-46242

A public proof of concept exists; no exploitation attested.

  • Published2026-05-30
  • Fixed in7.0.10 · 6.18.33 · 6.2 · 5.16
  • WeaknessCWE-416

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

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.

Timeline

dates in UTC
  1. 2026-05-3013:16CVE publishedNVD

Observed activity

isMalicious corpus · updated 2026-10-23 15:37 UTC
Indicators tagged with this CVE, per day0 indicators over 7 days
Block these indicators
  • Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2026-46242?format=txt
  • CSV export: https://api.ismalicious.com/edl/cve/CVE-2026-46242?format=csv
  • TAXII collection of exploited CVEs
  • The EDL and CSV take an API key on the Pro plan.

Versions per branch

NVD
Linux linux kernel
BranchAffectedFixed in
7.0≥ 6.19, < 7.0.107.0.10
6.x≥ 6.4, < 6.18.336.18.33
6.x≥ 6.1.175, < 6.26.2
5.x≥ 5.15.209, < 5.165.16

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Packages

  • kernelAlmaLinux:10all versions · fixed in 6.12.0-211.31.1.el10_2and 74 other packages
  • kernelAlmaLinux:9all versions · fixed in 5.14.0-687.23.1.el9_8and 73 other packages

Vendor advisories

  • CVE-2026-46242 Red Hat Product Security1,656 products fixed

    kernel: eventpoll: fix ep_remove struct eventpoll / struct file UAF

  • RHSA-2026:73187 Red Hat Product Security53 products fixed

    Red Hat Security Advisory: kernel security, bug fix, and enhancement update

  • RHSA-2026:44231 Red Hat Product Security4 products fixed

    Red Hat Security Advisory: OpenShift Container Platform 4.19.40 bug fix and security update

  • RHSA-2026:44007 Red Hat Product Security35 products fixed

    Red Hat Security Advisory: kpatch-patch-5_14_0-570_116_1, kpatch-patch-5_14_0-570_17_1, kpatch-patch-5_14_0-570_39_1, kpatch-patch-5_14_0-570_66_1, and kpatch-patch-5_14_0-570_94_1 security update

  • RHSA-2026:44006 Red Hat Product Security35 products fixed

    Red Hat Security Advisory: kpatch-patch-5_14_0-427_100_1, kpatch-patch-5_14_0-427_113_1, kpatch-patch-5_14_0-427_126_1, kpatch-patch-5_14_0-427_68_2, and kpatch-patch-5_14_0-427_84_1 security update

  • RHSA-2026:43825 Red Hat Product Security7 products fixed

    Red Hat Security Advisory: kpatch-patch-5_14_0-687_10_1 security update

10 more advisories

Full record on NVD

Fix

  1. Update Linux linux kernel to 7.0.10 · 6.18.33 · 6.2 · 5.16
  2. Vendor fix Red Hat Product Security RHSA-2026:73187 · 53 productsFor details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 The system must be rebooted for this update to take effect.
  3. Vendor fix Red Hat Product Security RHSA-2026:44231 · 4 productsFor OpenShift Container Platform 4.19 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.redhat.com/en/documentation/openshift_container_platform/4.…
  4. Vendor fix Red Hat Product Security RHSA-2026:44007 · 35 productsFor details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
  5. Vendor fix Red Hat Product Security RHSA-2026:40787 · 4 productsFor OpenShift Container Platform 4.20 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.redhat.com/en/documentation/openshift_container_platform/4.…
  6. Vendor fix Red Hat Product Security RHSA-2026:40779 · 4 productsFor OpenShift Container Platform 4.21 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.redhat.com/en/documentation/openshift_container_platform/4.…
  7. Vendor fix Red Hat Product Security RHSA-2026:40764 · 4 productsFor OpenShift Container Platform 4.22 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.redhat.com/en/documentation/openshift_container_platform/4.…

Advisories and patches

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB

Sources

Technical details

CVSS v3 Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Published
2026-05-30
Last Modified
2026-10-19
NVD status
Modified
MSRC Title
eventpoll: fix ep_remove struct eventpoll / struct file UAF

Frequently asked questions

What is CVE-2026-46242?

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.

Is CVE-2026-46242 actively exploited?

Active exploitation of CVE-2026-46242 has not been confirmed. Its EPSS score was 4.4% on 2026-10-22, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-46242?

CVE-2026-46242 has a CVSS v3 base score of 7.8 (HIGH severity), with vector string CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Running Linux kernel? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

No credit card required · No monthly cap on website lookups · 250 API requests/month