{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003ef_ep under file-\u003ef_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-\u003erelease / file_free().  For the epoll-watches-epoll case, f_op-\u003erelease is ep_eventpoll_release() -\u003e ep_clear_and_put() -\u003e ep_free(), which kfree()s the watched struct eventpoll. Its embedded -\u003erefs hlist_head is exactly where epi-\u003efllink.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-\u003emtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep-\u003erefcount 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-\u003edying under f_lock. The cheap lockless READ_ONCE(epi-\u003edying) fast-path bailout stays.",
  "id": "DEBIAN-CVE-2026-46242",
  "modified": "2026-05-31T08:48:18.069401879Z",
  "published": "2026-05-30T13:16:21.980Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46242"
    }
  ],
  "upstream": [
    "CVE-2026-46242"
  ]
}