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

  - netfilter：nf_tables：不将数据包路径对象通知排队 以下所有 file：line 引用均针对 v7.2-rc4 （ac5b0e5651b1）。在 7.2.0-rc6-kasan72rc6 （075b74841bd0） 上捕获了跟踪，其中适用的行相同。nft_obj_notify（） 被导出并从数据包路径到达。其唯一的树内调用程序是 nft_quota_obj_eval（） （net/netfilter/nft_quota.c：68），后者在评估传输数据包规则时通过GFP_ATOMIC通知，不保留互斥体。由于提交了 67cc570edaa0（netfilter：nf_tables：将多个通知合并为一个 skbuff），因此不再立即发送该通知。
    __nft_obj_notify（） 通过裸list_add_tail nft_notify_enqueue（） （net/netfilter/nf_tables_api.c：1211） 将其排队到nft_net->notify_list。notify_list 没有自己的锁 （include/net/netfilter/nf_tables.h：1951），它按 commit_mutex 进行序列化：其他六个排队站点都在一个 netlink 事务内运行，而 nft_commit_notify（） （net/netfilter/nf_tables_api.c：10746） 中的漏会从 nf_tables_commit（） 进行 list_del（） + kfree_skb（），并保留commit_mutex。因此，通过引用已耗尽配额对象的链发送数据包会使未锁定的 list_add_tail（） 与另一个 CPU 上的 list_del（） + kfree_skb（） 争用。然后，__list_add（） 中的 WRITE_ONCE（prev->next， new） 会通过已释放的sk_buff进行存储： 缺陷：KASAN：__nft_obj_notify+0x2c5/0x2d0 中的 slab-after-free 在地址 ff110001047183c0 处按任务 poc/76 写入大小为 8 CPU：0 UID：1000 PID：76 Comm：poc 受感染：G W 7.2.0-rc6-kasan72rc6 #4 调用跟踪： <IRQ> __nft_obj_notify （include/linux/list.h：164 include/linux/list.h：191 net/netfilter/nf_tables_api.c：1211 net/netfilter/nf_tables_api.c：8743） nft_quota_obj_eval （net/netfilter/nft_quota.c：68） nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto 按任务 77 分配：__alloc_skb （net/core/skbuff.c：704） __nft_obj_notify （include/net/netlink.h：1055 net/netfilter/nf_tables_api.c：8731） nft_quota_obj_eval （net/netfilter/nft_quota.c：68） nft_do_chain 由任务 79 释放： nf_tables_commit （include/linux/skbuff.h：1332 net/netfilter/nf_tables_api.c：10759 net/netfilter/nf_tables_api.c：11185） nfnetlink_rcv_batch （net/netfilter/nfnetlink.c：574） netlink_unicast netlink_sendmsg 有缺陷的地址属于大小为 232 的缓存skbuff_head_cache 从数据包路径进行排队是错误的，即使将争用放在一边也不例外：notify_list仅由 nf_tables_commit（） 中的 nft_commit_notify（） 耗尽 （：11185）， 因此，在以后的某个 netlink 批处理提交（如果有的话）之前，不会发送排队在事务外的通知。nft_obj_notify（） 仍然采用的 gfp 参数是 67cc570edaa0 之前行为的残留，在此路径中直接调用了 nfnetlink_send（）。恢复现状：将消息结构拆分为 nft_obj_notify_alloc（），让每个调用方决定如何处理 skb。nft_obj_notify（），即从数据包路径到达的导出函数，立即将其发送;
    在 commit_mutex 下运行的 nf_tables_obj_notify（） 会一直将其排队，因此事务通知仍会合并。（CVE-2026-80837）

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

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - netfilter： nf_tables：不要將封包路徑物件通知排入佇列 以下所有 file：line 參照均針對 v7.2-rc4 （ac5b0e5651b1）。追蹤是在 7.2.0-rc6-kasan72rc6 （075b74841bd0） 上擷取的，其中適用相同的行。nft_obj_notify（） 會從封包路徑匯出並連線。它唯一的樹狀結構呼叫者是 nft_quota_obj_eval（） （net/netfilter/nft_quota.c：68），它在評估傳輸封包的規則時以 GFP_ATOMIC 通知，不保留互斥。自從提交 67cc570edaa0 （netfilter： nf_tables：將多個通知合併為一個 skbuff） 以來，系統不再立即傳送該通知。
    __nft_obj_notify（） 透過 nft_notify_enqueue（） 將其排入 nft_net->notify_list （net/netfilter/nf_tables_api.c：1211），這是一個裸list_add_tail（）。notify_list沒有自己的鎖 （include/net/netfilter/nf_tables.h：1951），它是由 commit_mutex 序列化的：其他六個入隊站點都在網路連結事務中運行，並且 nft_commit_notify（） 中的 drain （net/netfilter/nf_tables_api.c：10746） 在保留commit_mutex的情況下從 nf_tables_commit（） 執行 list_del（） + kfree_skb（）。因此，透過參照已耗盡配額物件的鏈傳送封包，會將解鎖的 list_add_tail（） 與另一個 CPU 上的 list_del（） + kfree_skb（） 爭用。然後，__list_add（） 中的 WRITE_ONCE（prev->next， new） 會儲存已釋放的 sk_buff： 錯誤： KASAN：__nft_obj_notify+0x2c5/0x2d0 中的 slab-use-after-free 透過任務 poc/76 在 addr ff110001047183c0 寫入大小 8 CPU：0 UID：1000 PID：76 Comm：poc 污染：G W 7.2.0-rc6-kasan72rc6 #4 呼叫追蹤： <IRQ> __nft_obj_notify （include/linux/list.h：164 include/linux/list.h：191 net/netfilter/nf_tables_api.c：1211 net/netfilter/nf_tables_api.c：8743） nft_quota_obj_eval （net/netfilter/nft_quota.c：68） nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto 由工作 77 分配：__alloc_skb （net/core/skbuff.c：704） __nft_obj_notify （include/net/netlink.h：1055 net/netfilter/nf_tables_api.c：8731） nft_quota_obj_eval （net/netfilter/nft_quota.c：68） nft_do_chain 由工作 79 釋放： nf_tables_commit （include/linux/skbuff.h：1332 net/netfilter/nf_tables_api.c：10759 net/netfilter/nf_tables_api.c：11185） nfnetlink_rcv_batch （net/netfilter/nfnetlink.c：574） netlink_unicast netlink_sendmsg 有錯誤的位址屬於大小為 232 的快取skbuff_head_cache 即使撇開爭用不談，從封包路徑排入佇列也是錯誤的：notify_list僅由 nf_tables_commit（） 的 nft_commit_notify（） 清空 （：11185）， 因此，在交易之外排隊的通知直到稍後的 NetLink 批次提交 （如果有的話） 才會傳送。nft_obj_notify（） 仍然採用的 gfp 引數是 67cc570edaa0 之前行為的遺留物，其中此路徑直接呼叫 nfnetlink_send（）。還原它：將訊息結構拆分為 nft_obj_notify_alloc（），並讓每個呼叫者決定如何處理 skb。nft_obj_notify（），從封包路徑到達的匯出者，立即發送;
    在 commit_mutex 下執行的 nf_tables_obj_notify（） 會不斷排隊，因此交易通知仍會合併。（CVE-2026-80837）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - netfilter:nf_tables:パケットパスオブジェクト通知をキューに入れません 以下のすべての file:line 参照は v7.2-rc4(ac5b0e5651b1)に反します。トレースは、同じ行が適用される 7.2.0-rc6-kasan72rc6(075b74841bd0)でキャプチャされました。nft_obj_notify() がエクスポートされ、パケットパスから到達します。唯一のツリー内呼び出し元は nft_quota_obj_eval()(net/netfilter/nft_quota.c:68)であり、mutex を保持していない移行パケットのルールを評価する際にGFP_ATOMICで通知します。67cc570edaa0(netfilter:nf_tables:複数の通知を 1 つの skbuff にまとめる)をコミットするため、その通知はすぐには送信されなくなりました。
    __nft_obj_notify() は、nft_notify_enqueue()(net/netfilter/nf_tables_api.c:1211)を介して、それを nft_net->notify_list にキューに入れます。これはベア list_add_tail() です。notify_list独自のロック(include/net/netfilter/nf_tables.h:1951)を持たず、commit_mutexによってシリアル化されます。他の 6 つのエンキューサイトはすべて netlink トランザクション内で実行され、nft_commit_notify()(net/netfilter/nf_tables_api.c:10746)のドレインは、commit_mutex を保持した状態で nf_tables_commit() から list_del() + kfree_skb() を行います。このため、枯渇したクォータオブジェクトを参照するチェーンを通じてパケットを送信すると、ロック解除された list_add_tail() と別の CPU 上の list_del() + kfree_skb() が競合します。その後、__list_add() の WRITE_ONCE(prev->next, new) は、既に解放されているsk_buffを通じて保存されます: バグ: KASAN:__nft_obj_notify+0x2c5/0x2d0 の slab-use-after-free タスク poc/76 による addr ff110001047183c0 におけるサイズ 8 の書き込み CPU:0 UID:1000 PID:76 Comm:poc 汚染:G W 7.2.0-rc6-kasan72rc6 #4 コールトレース: <IRQ> __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto タスク 77 により割り当てられます: __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain タスク 79 により解放されます。 nf_tables_commit(include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch(net/netfilter/nfnetlink.c:574)netlink_unicast netlink_sendmsg バグのあるアドレスは、サイズ 232 のキャッシュskbuff_head_cacheに属しています パケットパスからのキューイングは、競合を脇に置いても間違っています:notify_list は、nf_tables_commit() からの nft_commit_notify() によってのみ排出されます(:11185)、 そのため、トランザクションの外側にキューに入れられた通知は、その後 netlink バッチがコミットするまで送信されません (コミットが発生した場合)。nft_obj_notify() が今でも取る gfp 引数は、このパスが nfnetlink_send() を直接呼び出していた、67cc570edaa0 以前の動作の名残です。それを復元します:メッセージ構造を nft_obj_notify_alloc() に分割し、各呼び出し元に skb をどうするかを決定させます。パケットパスから到達したエクスポートされたものnft_obj_notify()は、それをすぐに送信します。
    commit_mutex の下で実行される nf_tables_obj_notify() はキューに入れ続けるため、トランザクション通知は引き続き合体されます。(CVE-2026-80837)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - netfilter: nf_tables: don't queue packet path object notifications All file:line references below are     against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the     same lines apply. nft_obj_notify() is exported and reached from the packet path. Its only in-tree caller     is nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a     rule for a transiting packet, holding no mutex. Since commit 67cc570edaa0 (netfilter: nf_tables: coalesce     multiple notifications into one skbuff) that notification is no longer sent immediately.
    __nft_obj_notify() queues it onto nft_net->notify_list via nft_notify_enqueue()     (net/netfilter/nf_tables_api.c:1211), which is a bare list_add_tail(). notify_list has no lock of its own     (include/net/netfilter/nf_tables.h:1951), it is serialised by commit_mutex: the six other enqueue sites     all run inside a netlink transaction, and the drain in nft_commit_notify()     (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from nf_tables_commit() with     commit_mutex held. Sending packets through a chain that references a depleted quota object therefore races     an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU. The WRITE_ONCE(prev->next,     new) in __list_add() then stores through an sk_buff that has already been freed: BUG: KASAN: slab-use-     after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr ff110001047183c0 by task poc/76 CPU: 0     UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4 Call Trace: <IRQ> __nft_obj_notify     (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211     net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet     nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto Allocated by     task 77: __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055     net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain Freed     by task 79: nf_tables_commit (include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759     net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast     netlink_sendmsg The buggy address belongs to the cache skbuff_head_cache of size 232 Queueing from the     packet path is wrong even leaving the race aside: notify_list is only drained by nft_commit_notify() from     nf_tables_commit() (:11185), so a notification enqueued outside a transaction is not sent until some later     netlink batch commits, if one ever does. The gfp argument that nft_obj_notify() still takes is a leftover     of the pre-67cc570edaa0 behaviour, where this path called nfnetlink_send() directly. Restore that: split     the message construction out into nft_obj_notify_alloc() and let each caller decide what to do with the     skb. nft_obj_notify(), the exported one reached from the packet path, sends it straight away;
    nf_tables_obj_notify(), which runs under commit_mutex, keeps queueing it, so transaction notifications are     still coalesced. (CVE-2026-80837)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
343018	Linux Distros 未修补的漏洞：CVE-2026-80837	Nessus	Misc.	9/4/2026	9/7/2026	medium
343018	Linux Distros 未修補弱點：CVE-2026-80837	Nessus	Misc.	9/4/2026	9/7/2026	medium
343018	Linux Distros のパッチ未適用の脆弱性: CVE-2026-80837	Nessus	Misc.	9/4/2026	9/7/2026	medium
343018	Linux Distros Unpatched Vulnerability : CVE-2026-80837	Nessus	Misc.	9/4/2026	9/7/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium