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

  - net/handshake：耗尽 net 命名空间退出中的待定请求 handshake_net_exit（） 中 list_splice_init（） 的参数颠倒。该调用会将本地空请求列表移动到 hn->hn_requests 上，使本地列表留空，因此后续的漏循环会运行零迭代。销毁网络命名空间时，尚未接受的待定握手请求不会拆散;每个选项都在套接字文件和handshake_req分配中保留一个引用。按记录的顺序传递源和目标（list_splice_init（list， head） 将列表移动到 head），以便将待定列表传输到本地暂存列表并通过 handshake_complete（） 耗尽。修复 splice 方向会暴露列表损坏争用。在 splice 之后，每个 req->hr_list 仍有非空链接指针，用于串接堆栈本地擦除列表，而不是hn_requests。并行 handshake_req_cancel（） -- 例如，来自未采用 netns 引用的内核套接字上的 sunrpc 的 TLS 超时 -- 通过 rhashtable 查找请求，调用 remove_pending（），并看到 ！list_empty（&req->hr_list）。然后，__remove_pending_locked（） 在漏迭代时从暂存列表中list_del_init（） 一个条目，从而使其损坏。漏循环在条目上运行 list_del（） 之后到达的相同调用会改为命中LIST_POISON。让 remove_pending（） 检查 hn_lock 下的HANDSHAKE_F_NET_DRAINING，并在耗尽正在进行时报告“找不到”。排水管已经拥有所有权;handshake_complete（） 在 HANDSHAKE_F_REQ_COMPLETED 上的现有test_and_set仍然会针对调用使用者hp_done的用户在 drain 和 cancel 之间进行仲裁。在漏中使用 list_del_init（） 而不是 list_del（），这样在漏释放条目之后 req->hr_list 就不会携带LIST_POISON。remove_pending（） 中的 DRAINING 防护使 cancel 返回 false，但 cancel 仍会失败至 HANDSHAKE_F_REQ_COMPLETED 上的 test_and_set_bit 并丢失请求的 hr_file 引用。如果这是最后一个引用，则在没有其他引脚的情况下，sk_destruct释放请求，前提是该请求仍链接在漏循环的本地列表中。在释放列表之前，将每个请求的hr_file固定在hn_lock下，并在循环完成请求后删除该漏引脚。
    (CVE-2026-63978)

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

检测

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

critical Nessus 插件 ID 328224

版本 1.24