Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - eventpoll：修复ep_remove结构 eventpoll / 结构文件 UAF ep_remove（） （通过 ep_remove_file（）） 清除了 file->f_lock 下的 file->f_ep，但随后继续在关键部分内使用 @file（is_file_epoll（）、hlist_del_rcu（） spin_unlock）。在该窗口中采用 eventpoll_release（） 快速路径的并行 __fput（） 观察到暂时性 NULL，跳过 eventpoll_release_file（） 并运行至 f_op->release / file_free（）。对于 epoll-watches-epoll 的情况，f_op->release 是 ep_eventpoll_release（） -> ep_clear_and_put（） -> ep_free（），kfree（） 会监视 struct eventpoll。其嵌入的 ->refs hlist_head正是 epi->fllink.pprev 所指向的位置，因此后续 hlist_del_rcu（） 的 *pprev = next 涂改到已释放的 kmalloc-192 内存中。此外，结构文件已SLAB_TYPESAFE_BY_RCU，因此插槽后备@file可通过 alloc_empty_file（） 回收 -- 重新初始化 f_lock 和 f_ep -- 而 ep_remove（） 名义上仍处于该锁定内。结果是攻击者可控制针对错误的 slab 缓存的 kmem_cache_free（）。通过 ep_remove（） 顶部的 epi_fget（） 引脚@file，并成功将引脚上的关键部分进行门控。保留引脚时@file无法达到 refcount 零，这会使 __fput（） 关闭并传递地使监视的 struct eventpoll 在 hlist_del_rcu（） 和 f_lock 使用中保持活动状态，从而关闭两个 UAF。如果引脚发生故障，则@file已达到 refcount 零，并且其 __fput（） 正在运行。由于我们在清除 f_ep 之前退出，所以该路径采用 eventpoll_release（） 慢速路径进入 eventpoll_release_file（） 并在 ep->mtx 上阻断，直到等待程序端的 ep_clear_and_put（） 将其删除。保释的 epi 在 ep->refcount 中的份额保持不变，因此 ep_clear_and_put（） 中的尾随 ep_refcount_dec_and_test（） 无法从 eventpoll_release_file（） 下释放 eventpoll;然后在那里清理孤立的 Epi。成功的引脚也证明我们没有在这个 epi 上进行 eventpoll_release_file（） 比赛，所以放弃现在多余的 epi->dying 在f_lock下重新检查。廉价的无锁READ_ONCE（epi->垂死）快速救助仍然存在。（CVE-2026-46242）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-46242

critical Nessus 插件 ID 318062

版本 1.1