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

  - drm/log：修正空訊息長度的越界讀取 drm_log_draw_kmsg_record（） 存取 s[len - 1] 以去除尾端換行符，但 len 是無符號的 int。如果 len 為 0，則減法會換行為 UINT_MAX，造成越界讀取。當 len 為 0 時，新增提前返回。（CVE-2026-80741）

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

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

  - ovpn：在解除參照之前確保通訊端由 ovpn 擁有 sk_user_data 某些子系統（例如 BPF SOCKMAP）在未實際設定encap_type的情況下設定sk_user_data。因此，在取消參照之前，我們必須確保該類型是 ovpn 預期的類型sk_user_data。否則可能會導致越界讀取。
    (CVE-2026-80735)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - 穩壓器：fp9931：修正 VPOS/VNEG 電壓選擇表 VPOSNEG_table[] 映射與規格書不符 FP9931 。數據表將 VPOS/VNEG 電壓映射定義為：00h-04h -> 7.04V （-7.04V） 05h -> 7.26V （-7.26V） 06h -> 7.49V （-7.49V） ...28h-3Fh -> 15.06V （-15.06V） 但是， VPOSNEG_table[] 有兩個問題： 1. 選擇器 0x00~0x04 應該全部映射到 7.04V （5 個條目），但該表有 6 個條目 7.04V，導致所有後續條目移動一個位置。2. 選擇器 0x29~0x3F 應該全部限制為 15.06V （23 個條目），但該表只有 41 個條目。任何高於 0x28 的選取器值都會導致越界資料表存取。移除重複 7.04V 項目並附加缺少的 23 個固定 15.06V 項目，使表格大小正確為 64 個項目 （0x00~0x3F），以解決這兩個問題。
    (CVE-2026-80745)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - 已解決 Linux 核心中的下列弱點：clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its Display Clock Controller is enabled and references parent clocks from DSI PHYs, which causes clock reparenting issues during probe (init) and warning on Eliza EVK: disp_cc_mdss_mdp_clk_src:
    rcg didn't update its configuration. WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273 ... update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P) clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471) clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540) __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368) devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1)) devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104) qcom_cc_really_probe (drivers/clk/qcom/common.c:418) qcom_cc_probe (drivers/clk/qcom/common.c:445) disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza platform_probe (drivers/base/platform.c:1432) (CVE-2026-80746)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - OpenVPN 2.1中的引數剖析問題_rc10 2.6.222.7Windows上_alpha1 2.7.6 ，允許遠端驗證使用者透過特製的憑證主體 （CVE-2026-84256） 執行任意命令

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

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

  - mm/huge_memory：在 Folio 分割 xas_try_split（） 為頁面快取xa_nodes新增__GFP_ACCOUNT之前初始化工作集狀態，但 __folio_split（） 會保留xa_state的xa_lru未設定。這使得一個實時的、充滿 memcg 的xa_node存在，而無需鏈接到映射的shadow_nodes list_lru;當 Reclaim 稍後遍歷它跳閘的list_lru時 VM_WARN_ON（！css_is_dying（））。使用 mapping_set_update（） 在xa_state上安裝工作集更新回呼和shadow_nodes list_lru。（CVE-2026-80729）

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

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

  - pmdomain：mediatek：修正 of_node_put（） scpsys_get_bus_protection_legacy（） 從裝置樹狀結構節點查詢數個舊版匯流排保護 regmap 後剩餘的 %pOF。兩個錯誤路徑在檢查 regmap 查詢是否失敗之前放置設備節點，但仍會在失敗時將該節點傳遞給 dev_err_probe（） 並帶有 %pOF。如果 of_node_put（） 刪除最後一個參照，則較晚的 %pOF 格式可以取消參照釋放的裝置節點。保留節點參照，直到在 infracfg 和 SMI 查閱路徑中發出錯誤訊息為止。當遺漏 SMI phandle 時，也請先捨棄 SMI 節點，再返回。
    (CVE-2026-80750)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - NToPNG 是一個基於 Web 的網絡流量監控應用程序。在 的6.7.260717版本6.7.0中，管理 ntopng 的標籤/徽章功能「POST /lua/rest/v2/delete/tag/tag.lua」和「POST /lua/rest/v2/edit/tag/tag.lua」的兩個 REST v2 端點完全不執行授權檢查。任何經過驗證的使用者 （包括非管理員 （無特權） 帳戶） 都可以刪除或重新命名系統中的任何標籤，包括管理員建立的標籤。版本 6.7.260718 包含一個修正。(CVE-2026-84989)

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

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

  - OpenVPN 2.0.0 直通 2.6.22 和 2.7_alpha1 2.7.6 在 Windows 上允許本機經過驗證的使用者透過具名 IPC 物件上的空 DACL 造成拒絕服務 （CVE-2026-82312）

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

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

  - thunderbolt：修正頻寬群組保留索引 有效頻寬群組 ID 範圍為 1 到 MAX_GROUPS，而群組 ID 為保留 0。tb_consumed_dp_bandwidth（） 直接使用群組 ID 來索引其本機 group_reserved[] 陣列。陣列目前有 MAX_GROUPS 個項目，因此其有效索引為 0 到 MAX_GROUPS - 1。因此，群組 ID MAX_GROUPS 會存取結束後的一個元素，且在加總陣列時，不會包含最後一個群組的保留頻寬。提供 group_reserved[] MAX_GROUPS + 1 個項目，以便直接群組 ID 索引涵蓋保留 ID 0 和有效 ID 1 到 MAX_GROUPS。
    (CVE-2026-80736)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - drm/connector/hdmi：修正越界記憶體讀取 協助程式函式將指定的音訊資訊框架複製到連接器的副本中，但使用目的地的大小 （通用目標，大小可接受許多不同的資料區塊），而不是來源 （一種非常特定的資料區塊類型）。因此，它從 28 位元組配置中複製 60 位元組的資料。改用來源大小來修正此問題，以及來源大小實際上小於目的地的建置錯誤。我在 KASAN 下運行 KUnit 測試時遇到了這個問題（同時調試完全其他東西）。在現實世界中，它似乎不太可能引起實際問題。它是讀取而不是寫入，因此它不會損壞任何記憶體。但是，它可能會從頁面末尾掉落並導致 accvio 錯誤。（CVE-2026-80749）

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

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

  - OpenVPN 2.7_alpha1 2.7.6 中的 Windows 互動式服務中的緩衝區大小計算不正確，允許本機驗證使用者透過特製的 NRPT 輸入造成記憶體損毀或洩漏敏感資訊。（CVE-2026-78221）

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

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

  - 在 Windows 上使用 tap-windows6 驅動程式的 OpenVPN 2.5.02.7.6 允許攻擊者透過特製的 DOMAIN-SEARCH 項目 （CVE-2026-81738） 觸發越界寫入

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

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

  - python-jose through 無法 3.5.0 正確驗證 HMAC 初始化中的非對稱金鑰，接受缺少 PEM armor 或 SSH 前綴的 DER 編碼公開金鑰。持有服務公開金鑰的攻擊者可以偽造 HS256 令牌，在演算法未明確限制的情況下通過驗證。這是 的 CVE-2024-33663不完整修正。（CVE-2026-85394）

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

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

  - Ubuntu Linux - [GHSA-g89c-p67h-r497： 'scale_nearest_neighbor（）' 中透過巢狀 'iden'/'auxl' 項目的重複 Alpha 平面導致堆積緩衝區溢位] （CVE-2026-84383）

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

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

  - PMDOMAIN：MediaTek：mfg：在 mtk_mfg_attach_dev（） 中初始化prev_o mtk_mfg_attach_dev（） 在其迴圈的第一次迭代中讀取prev_o，在迴圈本文末尾指派 prev_o 之前，在 if （prev_o & prev_o->freq == o->freq） 中讀取。在第一次反覆運算中，評估prev_o讀取不確定的值。如果為非 NULL，則條件會取消參照過時或無效的指標，可能會出錯或錯誤地略過第一個 OPP。將prev_o初始化為 NULL。這也符合意圖：在第一次迭代中沒有先前的 OPP 可供比較。使用 Clang 的 -Wconditional-uninitialized 找到。
    (CVE-2026-80751)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - xfrm：避免 NAT keepalive 工作中的鎖定反轉 nat_keepalive_work（） 會遍歷狀態表，而 xfrm_state_walk（） 會保留 net->xfrm.xfrm_state_lock。然後，它的回呼會取得 x->lock，這與透過 xfrm_state_delete（） 以相反順序採用相同鎖定的刪除路徑發生衝突，並且
    __xfrm_state_delete（）。這會建立 AB-BA 鎖死，當 NAT keepalive 工作程式與 SA 刪除爭用時，lockdep 會報告該鎖死。透過將 keepalive 遍歷分成兩個階段來解決此問題。首先，在步行保持xfrm_state_lock時收集候選州，並參考每個州。然後，在遍歷完成後，處理每個收集的狀態並取得 x->lock，而不將其巢狀化在xfrm_state_lock下。（CVE-2026-80845）

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

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

  - USB：c67x00：修正 c67x00_add_iso_urb（） 中的釋放後使用當同步 URB 的最後一個封包的 TD 建立失敗時，c67x00_add_iso_urb（） 會在更新端點排程狀態之前返回 URB。
    c67x00_giveback_urb （） 會釋放 URB 私人數據，而完成回呼可能會釋放最終的 URB 參考。因此，下列對 urbp->ep_data、urb->interval 和 urbp->cnt 的存取可以使用釋放的記憶體。在傳回失敗的最終封包之前更新 next_frame 和 cnt，讓送回成為使用 URB 及其私人資料的最後一個作業。（CVE-2026-80826）

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

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

  - RDMA/rxe：使用 qp->attr.max_dest_rd_atomic 修正 free_rd_atomic_resources（） free_rd_atomic_resources（） 反覆運算中的 OOB。在釋放舊陣列之前更新max_dest_rd_atomic可能會使自由路徑越過舊的分配，並觸發 KASAN 捕獲的 slab 越界寫入：
    ================================================================== 錯誤：KASAN：free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c：180 中的 slab-out-of-bounds [內聯] 錯誤：KASAN：free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：171 中的 slab-out-of-bounds [內嵌] 錯誤：KASAN：free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：163 中的 slab-out-of-bounds [內嵌] 錯誤：KASAN：rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/ 中的 slab-out-of-boundsrxe_qp.c：712 由任務 syz 在 addr ffff88802b8dddb8 寫入大小 4 3.451/11063 CPU：0 UID：0 PID：11063 通訊：syz.3.451 未受 7.1.0 #2 污染 PREEMPT（完整） 硬體名稱：QEMU Ubuntu 24.04 PC v2 （i440FX + PIIX，arch_caps fix，1996），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 呼叫追蹤： <TASK> __dump_stack lib/dump_stack.c：94 [內嵌] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 [內嵌] print_report+0xf7/0x600 mm/kasan/report.c：482 kasan_report+0xe4/0x120 mm/kasan/report.c：595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c：180 [內聯] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：171 [內聯] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：163 [內聯] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c：712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c：623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c：625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c：1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c：1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c：1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c：680 vfs_write+0x2aa/0x1070 fs/read_write.c：686 ksys_write+0x1f8/0x250 fs/read_write.c：740 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7fefc75a70cd 代碼：ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007fefc8495018 EFLAGS：00000246 ORIG_RAX：0000000000000001 RAX：ffffffffffffffda RBX：
    00007fefc7835fa0 RCX：00007fefc75a70cd RDX：0000000000000078 RSI：0000200000000240 RDI：0000000000000007 RBP：00007fefc764f10f R08：00000000000000000000 R09： 000000000000000000 R10： 000000000000000000 ： 000000000000000 R11：
    0000000000000246 R12： 0000000000000000 R13： 00007fefc7836038 R14： 00007fefc7835fa0 R15： 00007ffcf0586aa0 </TASK> 由任務 11063 分配： kasan_save_stack+0x33/0x60 mm/kasan/common.c：57 kasan_save_track+0x14/0x30 mm/kasan/common.c：78 poison_kmalloc_redzone mm/kasan/common.c：398 [內嵌]
    __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c：415 kasan_kmalloc include/linux/kasan.h：263 [內嵌]
    __do_kmalloc_node mm/slub.c：5296 [內嵌] __kmalloc_noprof+0x32a/0x850 mm/slub.c：5308 kmalloc_noprof include/linux/slab.h：954 [內嵌] kzalloc_noprof include/linux/slab.h：1188 [內嵌] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：155 [內嵌] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c：714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c：623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c：625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c：1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c：1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c：1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated--- （CVE-2026-80863）

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

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

  - RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr（） 上的回應程式 UAF 會處理IB_QP_STATE路徑之外的IB_QP_MAX_DEST_RD_ATOMIC，因此它不會保留任何state_lock，並在回應程式工作 rxe_receiver（） （rxe_wq 上的 recv_task） 作用中時執行。僅該屬性的 modify_qp（） 設定呼叫 free_rd_atomic_resources（），然後呼叫 alloc_rd_atomic_resources（），在 rxe_prepare_res（）/find_resource（） 遍歷時交換 qp->resp.resources[];free_rd_atomic_resources（） 也會讓快取的指標 qp->resp.res 懸空。本機非特權使用者可以在 rxe_receiver（） 中將 free/realloc 爭用為釋放後使用（本機 DoS）。使用 rxe_disable_task（）/rxe_enable_task（） 在交換周圍清空recv_task，就像 rxe_qp_reset（） 在拆除此陣列時所做的那樣，只有在 alloc_rd_atomic_resources（） 成功後才重新啟用，這樣回應程式就永遠不會針對 ENOMEM 路徑上的 NULL qp->resp.resources 繼續。同時清除 free_rd_atomic_resources（） 中的 qp->resp.res，例如 rxe_resp.c 完成路徑。在 KASAN 下複製;rxe_receiver（） 中的 slab-use-after-free 消失了。（CVE-2026-80864）

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

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

  - drm/tegra： gr2d/gr3d： 在註冊 HOST1X 用戶端之前初始化位址暫存器映射 host1x_client_register（） 函數在暫存器映射初始化迴圈之前調用，使裝置可供使用者空間使用。這可能會導致使用者空間在初始化暫存器對映之前嘗試提交作業。在 host1x 用戶端註冊之前移動暫存器初始化來解決此問題。（CVE-2026-80883）

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

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

  - 藍牙：hci_event：在重設時修正 LE 清單 UAF hci_cc_reset（） 會清除 LE 接受和解析清單，而不採用 hdev->lock。其他命令完成處理常式會使用該鎖定序列化這些清單的更新，而 debugfs 讀取器會在遍歷它們時保留它。這允許重設完成和 debugfs 讀取交錯，如下所示： hci_rx_work debugfs 讀取器----------- --------------鎖定 hdev->lock 擷取目前項目 list_del（entry） kfree（entry） 讀取項目欄位 然後，讀取器會解除參照釋放的清單項目，並可能遵循其過時的下一個指標。KASAN 報告： 錯誤：KASAN：在 white_list_show+0x15f/0x180 中的 slab-use-after-free 透過任務 poc/95 在 addr ffff8881015dab16 讀取大小 1 呼叫追蹤：
    white_list_show+0x15f/0x180 seq_read_iter+0x3ff/0x1190 seq_read+0x267/0x3d0 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 由任務 91 分配： hci_bdaddr_list_add+0x1a6/0x3a0 hci_cc_le_add_to_accept_list+0xab/0x140 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 由任務 90 釋放： kfree+0x131/0x3c0 hci_bdaddr_list_clear+0xd8/0x160 hci_cc_reset+0x28a/0x370 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 將 hdev->lock 放在兩個清單清除周圍。這符合現有的突變和遊走鎖定慣例。（CVE-2026-80764）

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

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

  - nvmet-fc：在初始化 LS IOD 陣列時，修正 LS IOD 錯誤路徑 nvmet_fc_alloc_ls_iodlist（） 中的無效釋放。如果 rqstbuf 配置或回應緩衝區 DMA 對應失敗，回復迴圈會在陣列開頭遞減 iod。因此，最後的 kfree（iod） 會在分配的物件之前釋放一個位址。這可以透過在建立目標連接埠之前將 fail-n 設定為 6 來使用 nvme-fcloop 和 failslab 來重現。KASAN 報告： 錯誤： KASAN：nvmet_fc_register_targetport 中無效釋放 任務 nvmet_fail_nth/9552 釋放 addr ffff88816cf8ff48 改為釋放儲存在 tgtport->iod 中的原始分配基礎。套用此修正後，具有 fail-nth=6 的相同 sysfs 寫入會傳回 -ENOMEM，而沒有任何 KASAN 報告。（CVE-2026-80790）

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

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

  - HID： uclogic：修正 remove uclogic_remove（） 時inrange_timer的釋放後使用，取消筆範圍內計時器，然後停止裝置：timer_delete_sync（&drvdata->inrange_timer）;hid_hw_stop（hdev）;
    timer_delete_sync（） 僅保證計時器在該時刻處於閒置狀態。uclogic_raw_event_pen（） 會繼續傳送筆報告，直到 hid_hw_stop（） 在幾行後停止傳輸，並且每個帶有 pen->inrange == 的報告都會重新UCLOGIC_PARAMS_PEN_INRANGE_NONE計時器：mod_timer（&drvdata->inrange_timer， jiffies + msecs_to_jiffies（100））;一份報告在 timer_delete_sync（） 通話和 hid_hw_stop（） 運輸拆解之間的報告在取消後重新武裝inrange_timer。然後 uclogic_remove（） 返回並釋放 devm drvdata，而 hid_hw_stop（） 已經釋放了輸入設備 drvdata->pen_input 指向，因此當計時器在 ~100 毫秒後觸發時，uclogic_inrange_timeout（） 會取消參照釋放的記憶體 - timer-softirq 上下文中的釋放後使用。交換兩個呼叫並不是解決方法：先停止裝置會透過 hidinput_disconnect（） 釋放 drvdata->pen_input，而計時器可能仍處於擱置狀態，因此在移除之前已經布防的計時器會在視窗中的釋放輸入裝置上觸發 timer_delete_sync（） 執行。請改用 timer_shutdown_sync（），然後再使用 hid_hw_stop（）。它會取消計時器，在 pen_input 仍然有效時等待正在運行的回呼，並防止任何進一步的重新布防——正在進行的報告中稍後的 mod_timer（） 會被靜默地忽略——因此在 hid_hw_stop（） 釋放輸入之前，計時器可以證明是死的。這是從另一個路徑拆卸案例重新武裝此計時器的計時器核心文件的順序。(CVE-2026-80766)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - net： bridge： mcast：修正主要 VLAN 多點傳播內容的釋放後使用 br_multicast_toggle_one_vlan（） 在停止 VLAN 的多點傳播內容之前清除 br->multicast_lock 下的BR_VLFLAG_MCAST_ENABLED。這就是拆解握手：無鎖讀者通過 br_multicast_ctx_should_use（） -> br_multicast_ctx_vlan_disabled（） 對旗幟進行門禁，因此一旦它在鎖下被清除，任何讀者都無法再次武裝上下文。對於主 VLAN，交握永遠不會執行。__vlan_del（） 會在呼叫 br_vlan_put_master（） 之前清除BRIDGE_VLAN_INFO_BRENTRY，因此 br_multicast_toggle_one_vlan（masterv， false） 會在 ！br_vlan_is_brentry（vlan） 早期返回：旗標保持設定狀態，並且永遠不會採用 br->multicast_lock。然後，br_vlan_put_master（） 會耗盡 br_multicast_ctx_deinit（） 中的上下文，並透過 call_rcu（） 釋放 VLAN，而仍在 rcu_read_lock（） 內的讀取器會將上下文視為已啟用並重新武裝它。函式的 port 和 port-VLAN 分支沒有 br_vlan_is_brentry（） 測試，並在 br->multicast_lock 下翻轉旗標，因此不受影響。讀取器是橋接傳輸路徑。對於主 VLAN br_multicast_rcv（） 選擇 brmctx = &vlan->br_mcast_ctx 且 pmctx = NULL，因此傳送到橋接裝置的 IGMP 會在 br_multicast_ctx_deinit（） 已經停止上下文的計時器後重新布防它們。錯誤：KASAN：detach_if_pending+0x412/0x4a0 中的 slab-use-after-free 透過任務 brmc/601 在 addr ffff88810ac39918 寫入大小 8
    __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 由任務 610 分配：br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 由任務 0 釋放：kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 啟用時僅測試 br_vlan_is_brentry（） 就像旁邊的 br_multicast_ctx_vlan_global_disabled（） 測試一樣。然後，停用總是會在 br_multicast_ctx_deinit（） 耗盡上下文之前清除 br->multicast_lock 下的BR_VLFLAG_MCAST_ENABLED。
    (CVE-2026-80842)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - dmaengine： sun6i-dma： 終止 DMA 時修正回收描述元 終止 DMA 傳輸時，無法正確回收作用中描述元。僅處理循環描述符，留下非循環描述符及其 LLI 鏈永久洩露。使用 vchan_terminate_vdesc（） 進行修正，該描述元可同時處理循環和非循環描述元，方法是將它們新增至佇列desc_terminated以便正確清除。
    新增 pchan->desc ！= pchan->done 檢查，以防止重複新增已完成的描述元，這會損毀清單。（CVE-2026-80902）

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

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

  - crypto：sun8i-ce - 移除crypto_rng介面 由於硬體 PRNG 的crypto_rng介面未使用，並且與 hwrng 和實際的 Linux RNG 是多餘的，因此正在逐步淘汰。它的大多數驅動程序已經被刪除。繼續刪除 sun8i-ce 支持，這是僅存的支撐之一。請注意，對 hwrng 的 sun8i-ce 支援仍然存在。這才是真正重要的界面。與 crypto_rng 一樣，此驅動程式也存在錯誤：其 ->generate（） 函式因使用 wait_for_completion_interruptible_timeout（） 而未處理在傳送訊號時關閉 DMA 作業而存在釋放後使用弱點。無論如何，單獨修復此問題只是為了刪除程式碼是沒有意義的，因此此提交被標記為 Fixes 和 Cc 穩定。（CVE-2026-80834）

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

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

  - xfrm： ah6：驗證路由標頭 segments_left AH6 會在計算或驗證 ICV 之前重新排列路由標頭位址。ipv6_rearrange_rthdr（） 假設segments_left不大於路由標頭的 hdrlen 欄位所描述的位址數目。此假設不適用於原始 IPv6 HDRINCL 封包。hdrlen 等於 2 的封包描述一個位址，但可以攜帶任意segments_left值。當segments_left等於 255 時，函式會將其位址指標向後移動 4,064 位元組，並將 4,064 位元組的長度傳遞給 memmove（），從而導致越界存取。在修改路由標頭或執行任何位址指標算術之前，先在本機驗證不變量，並將格式錯誤的標頭錯誤傳播到現有的 AH6 輸入和輸出錯誤路徑。（CVE-2026-80844）

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

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

  - NFC： FDP：繫結裝置報告的讀取長度並修正 SKB 洩漏 fdp_nci_i2c_read（） 會從裝置提供的兩個位元組中獲取下一個封包長度，並且從不對其進行驗證。該值是一個 u16，用作 261 位元組堆疊緩衝區的 i2c_master_recv（） 計數：惡意、偽造或故障的控制器（或 I2C 匯流排內插器）可以驅動它遠遠超過緩衝區，以進行堆疊越界寫入，從而破壞金絲雀和傳回位址，或低於最小幀大小（直接，或透過截斷計算的總和），因此標頭/LRC 條和下一個長度讀取會經過短接收。拒絕超出 [FDP_NCI_I2C_MIN_PAYLOAD， FDP_NCI_I2C_MAX_PAYLOAD] 的長度，因為封包已經損毀，然後強制重新同步。相同的迴圈每次迭代分配一個資料 skb，並假設一個長度封包後面接著一個資料封包;在一次呼叫中傳送兩個資料封包的裝置會在第二個配置覆寫第一個 SKB 時洩漏第一個 SKB。在配置下一個 skb 之前，先釋放先前配置的 skb。
    (CVE-2026-80802)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - USB： usbfs：修正 usbdev_release（） 中 usb_device 的釋放後使用 usbdev_release（） 會在清空已完成的非同步 URB 清單之前刪除其對結構usb_device的參照，但該清空路徑會透過相同的物件回讀： free_async（） 會針對緩衝區來自 usbfs mmap（） 區域的任何 URB 呼叫 dec_usb_memory_use_count（） ， 它的第一個語句是 bus_to_hcd（ps->dev->bus）。斷開連接後，usbfs 參照可以是最後一個參照，在這種情況下，usb_put_dev（） 釋放設備，後續循環讀取釋放記憶體的偏移量 80，並將結果用作結構usb_hcd *，然後 hcd_buffer_free_pages（） 解除參照。對 /dev/bus/usb 節點具有讀取/寫入存取權限的無權限進程可以實現此目的：mmap（） fd，提交一個在映射內帶有緩衝區的 URB，等待設備被拔下，然後 munmap（） 和 close（）。它會在每次嘗試時重現，而不是爭用，因為即時MAP_SHARED vma 在結構檔案上保留引用，因此 usbdev_release（） 無法運行，直到最後一個 vma 消失並且始終採用 dec_usb_memory_use_count（） 的釋放分支。錯誤：KASAN：dec_usb_memory_use_count+0x3ae/0x410 中的 slab-use-after-free 由任務 poc/769 在 addr ffff8880122ee050 讀取大小 8 CPU：1 UID：1000 PID：769 通訊：poc 污染：G B 6.12.94 #3 呼叫追蹤：dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 由任務 11 分配： usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 由任務 769 釋放：kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 改為在漏空迴路後釋放裝置參照。兩點之間沒有任何東西需要刪除它。
    (CVE-2026-80824)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - ALSA：had/tas2781：取消綁定 TAS2781 HDA I2C 和 SPI 佇列 RCA 韌體時，取消非同步韌體要求，從元件與 request_firmware_nowait（） 繫結。韌體載入器會讓回呼模組保持釘選並保留裝置參考，但回呼仍會使用驅動程式私人 HDA 狀態。元件解除綁定會立即移除控制項和 DSP 狀態。稍後刪除設備會破壞 TAS2781 私人數據，包括codec_lock。如果非同步韌體回呼在解除綁定啟動之後執行，它可以在正在拆除的狀態上運作。在移除控制項和 DSP 狀態之前，先取消或同步處理非同步韌體要求。佇列的回呼會取消，而且允許在解除綁定繼續之前完成已執行的回呼。（CVE-2026-80872）

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

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

  - xfrm：修正 xfrm_state_construct（） auth-trunc 洩漏 attach_auth_trunc（） 可以配置 x->aalg，而當所選的驗證演算法沒有sadb_alg_id時，將 x->props.aalgo 保留為零。一個真實的案例是 cmac（aes）。
    然後，xfrm_state_construct（） 將 ！x->props.aalgo 視為尚未附加驗證演算法並呼叫 attach_auth（）。這會覆寫 x->aalg 並遺失第一個分配。任何後續的故障或拆卸只會釋放替換指標。檢查 x->aalg 是否已附加，而不是從 x->props.aalgo 推斷該狀態。（CVE-2026-80843）

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

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

  - nfc： nci：修正 nci_target_auto_activated（） 中的越界寫入 nci_target_auto_activated（） 將目標附加到固定大小陣列 ndev->targets[NCI_MAX_DISCOVERED_TARGETS] 並遞增 ndev->n_targets，而無需先檢查陣列是否已滿;與它的兄弟 nci_add_new_target（） 不同，當n_targets已經等於 NCI_MAX_DISCOVERED_TARGETS 時，它就會退出。ndev->n_targets 只會由 nci_clear_target_list（） 清除，因此重複重新執行探索 （RF_DISCOVER_RSP，在不清除目標清單的情況下重新輸入NCI_DISCOVERY） 並報告自動啟動目標 （RF_INTF_ACTIVATED_NTF） 的 NFCC 會驅動n_targets超過限制。然後，附加會寫入一個結構nfc_target，越過陣列的結尾 （slab 越界寫入），並且 nfc_targets_found（） 繼續以膨脹的計數遍歷陣列： 錯誤：KASAN：nci_add_new_protocol+0x94/0x2ac 中的 slab-out-of-bounds [nci] 在 addr ffff0000c7299a18 處寫入大小 2 的寫入，由任務 kworker/u8：0/12 工作佇列： nfc0_nci_rx_wq nci_rx_work [nci] 呼叫追蹤：
    nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 有錯誤的位址屬於大小為 2048 的快取 kmalloc-2k 有錯誤的位址位於已分配的 1560 位元組區域右側 1024 位元組 [ffff0000c7299000， ffff0000c7299618） 使用與 nci_add_new_target（） 相同的檢查來保護 nci_target_auto_activated（）。（CVE-2026-80795）

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

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

  - NFC： microread：驗證目標探索承載長度 microread_target_discovered（） 會根據 HCI 閘道剖析來自 skb->data 的目標探索承載。僅針對目的地nfc_target緩衝區檢查固定欄位位移和 UID 副本，而不針對實際 skb 長度進行檢查。在讀取或複製每個閘道特定承載之前，驗證它們是否包含固定欄位和 UID 位元組。
    (CVE-2026-80801)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - drm/amdgpu：拒絕具有無效數量 h265 refs 的 UVD 訊息 與 h264 的變更相同，可避免稍後在計算最小 dpb 大小時溢位。（從提交 a4b0720e4f1601f97f59a2be9c1b4b94fa6527d5 中挑選）（CVE-2026-80909）

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

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

  - fbdev：在協助程式中包裝使用者叫用的 fb_set_var（） 呼叫 在 fb_set_var_from_user（） 中的顯示更新期間處理 fbcon。與 fbcon 檢查模式更改是否可行，更新硬體狀態，最後更新 fbcon。更新所有來電者。目前只有FBIOPUT_VSCREENINFO ioctl 會執行所有步驟。sysfs 和驅動程式程式碼中的其他模式變更呼叫端缺少 fbcon 相關步驟。使用新的協助程式後，ps3fb 和 sh_mobile_lcdcfb 不再自行維護 fbcon 狀態。（CVE-2026-80786）

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

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

  - tipc：避免 tipc_exit_net（） 中的忙碌迴圈 Blamed commit 在 tipc_exit_net（） 中引入了忙碌等待迴圈，以等待擱置的 UDP 承載清理工作完成： while （atomic_read（&tn->wq_count）） cond_resched（）;如果 cond_resched（） 是 NOP，則此迴圈可能會忙碌等待很長時間。如果 netns 結束是由高優先順序任務執行，或在未配置先佔 （CONFIG_PREEMPT_NONE） 的核心下執行，通常會發生這種情況。在這種情況下，它會浪費 CPU 週期並可能導致軟鎖定。透過將忙碌迴圈替換為 wait_var_event（） 來解決此問題，讓執行緒正常休眠，直到工作佇列計數達到零。因此，更新 cleanup_bearer（） 以在計數降至零時使用 atomic_dec_and_test（） 和 wake_up_var（） 喚醒服務員。這使用全域等待佇列雜湊表，避免了使用wait_queue_head_t來膨脹結構tipc_net的需要。atomic_dec_and_test（） 提供必要的記憶體屏障，以確保不會遺漏喚醒。（CVE-2026-80866）

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

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

  - crypto：virtio - 綁定 akcipher 結果長度 virtio_crypto_dataq_akcipher_callback（） 會設定裝置報告回應長度的結果長度，而不將其綁定至為原始要求長度配置的目的地緩衝區。然後sg_copy_from_buffer（） 從目的地緩衝區讀取該數量的位元組;報告較大長度的後端會將相鄰的核心堆積過度讀取到調用方的散佈清單中（越界讀取）。將報告的長度限制為最初要求的目的地長度。符合規範的裝置報告不會超過此值，因此有效結果不受影響。（CVE-2026-80836）

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

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

  - xfrm： espintcp：修正關閉期間的 UAF ZDI 報告並分析了 espintcp 通訊端關閉期間的爭用情形：espintcp_close（） 透過 kfree_skb（） 釋放 emsg->skb，而不持有任何通訊端鎖定。同時，xfrm_trans_reinject工作佇列會叫用 esp_output_tcp_finish（） -> espintcp_push_skb（） -> espintcp_push_msgs（） -> skb_send_sock_locked（），其會讀取與資料來源相同的 skb。透過在重設 sk_prot 後新增 synchronize_rcu（） 呼叫來解決此問題，因為 esp_output_tcp_finish（） 在 RCU 下運行並且不會使用具有 sk_prot == &tcp_prot 的通訊端。如果 esp_output_tcp_finish（） 在我們剛剛釋放的插槽中重新新增 skb，簡單地在 espintcp_close（） 中進行通訊端鎖定可能會導致洩漏。在此之後，就不再需要現有的 barrier（）。（CVE-2026-80848）

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

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

  - HID： pidff：修正 hid->inputs 為空時的 OOB 寫入 hid_pidff_init_with_quirks（） 從 list_entry（hid->inputs.next， struct hid_input， list） 派生其input_dev，而無需先檢查 hid->inputs 是否為非空。struct hid_input 的清單成員位於位移 0，因此在空白清單上，list_entry（） 會產生 &hid->inputs 本身，而下列 hidinput->input 載入會讀取結構 hid_device 的不相關成員。
    然後 dev 是一個類型混淆的指標，強制反饋 init 通過它寫入：每個 set_bit（FF_*， dev->ffbit） 在 dev + 192 處存儲 8 個位元組，超過物件 dev 實際別名的末尾，並且 input_ff_create（） 添加堆指標和兩個函數指標的進一步寫入。在 hid-universal-pidff 之前，唯一的調用方是來自 usbhid 的 hid_pidff_init（），它在 HID_CLAIMED_INPUT 下運行，因此總是至少有一個hid_input。universal_pidff_probe（） 以 HID_CONNECT_DEFAULT & ~HID_CONNECT_FF 啟動裝置，然後在描述元攜帶 PID 使用頁面時直接呼叫 hid_pidff_init_with_quirks（），繞過該閘道。唯一應用程式集合位於 HID_UP_PID 上的報告描述元會將 hid->input 留空，而 hid_connect（） 仍會透過 hidraw 宣告成功，因此探查會到達不受保護的 list_entry（） 。寫入發生在熱插拔工作佇列上的 USB 探查路徑中，因此插入惡意裝置就足以觸發它;不需要攻擊者軟體，也不需要登入的使用者。KASAN 報告從 universal_pidff_probe（） 到達的 hid_pidff_init_with_quirks（） 中 8 位元組的越界寫入。衍生 dev 並傳回 -ENODEV 之前，檢查是否有空白清單，就像其他 HID 強制回饋驅動程式所做的那樣。 universal_pidff_probe（） 會傳播錯誤並展開。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-80780）

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

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

  - drm/amdgpu：修正 UVD dpb 最小大小計算 H264 這應該使用解碼訊息中的實際參照數量，而不是從層級派生的最大值。（從提交 64b525edb7e7bdfcdc77883c5e413804e2396856 中挑選）（CVE-2026-80907）

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

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

  - HID：任天堂：設定功能後註冊輸入裝置 input_register_device（） 會立即將裝置公開給使用者空間。在 joycon_input_create（） 中，它是在 joycon_config_rumble（） 配置 FF_RUMBLE 功能和無內顯力反饋設備之前調用的，因此並行 EVIOCSFF 可以取消參照空 dev->ff。提前註冊也意味著初始 udev 事件缺少按鈕和軸信息，這可能會使輸入管理器忽略該設備。將 input_register_device（） 移至 joycon_input_create（） 的結尾，在所有功能之後，IMU 輸入裝置和強制回饋回呼都已設定完畢。（CVE-2026-80771）

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

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

  - mm/hugetlb：修正在 fork（） 清除 uffd-wp 時的交換項目損毀 copy_hugetlb_page_range（） 會清除遷移的 uffd-wp 位元，並使用 huge_pte_clear_uffd_wp（） 清除 hwpoison 項目，該項目在 present-PTE 位元位置上運作。交換項目將 uffd-wp 狀態保留在其他地方 -- 遷移分支使用 pte_swp_uffd_wp（） 和 pte_swp_mkuffd_wp（） 讀取並設定它 -- 並且 present-PTE 位置落入交換有效負載。在 x86-64 上，它落在反向交換偏移中，其中自然對齊的 hugetlb PFN 始終具有受影響的位集，因此清除會將編碼的 PFN 提前兩頁。不需要涉及 userfaultfd：清除僅由未註冊 uffd-wp 的子 VMA 保護，因此帶有正在進行的 hugetlb 遷移項目（或中毒的 hugetlb 頁面）的普通 fork（） 會損壞複製到子項中的項目。在 2MB anon hugetlb 頁面上MADV_HWPOISON後檢測清除和分叉顯示： =120e02 之後的偏移 before=120e00 偏移 影響主要是潛在的：rmap 遍歷按作品集範圍匹配遷移條目，並且 remove_migration_pte（） 從作品集重建 PTE，因此一旦遷移完成，作品集內 PFN 偏差就會得到修復。但是任何重新編碼損毀偏移的路徑，例如
    hugetlb_change_protection（） 透過 make_readable_migration_entry（swp_offset（entry）） 重寫可寫入的移轉項目 -- 傳播它。遷移項目合法地帶有 uffd-wp，因此請使用 pte_swp_clear_uffd_wp（） 清除它，匹配 copy_nonpresent_pte（） 和 move_huge_pte（）。另一方面，hwpoison 條目從不攜帶 uffd-wp 位元：它由 make_hwpoison_entry（） 全新安裝（try_to_unmap_one（） 不會在 hwpoison 路徑上保留 uffd-wp），並且 hugetlb_change_protection（） 保持 hwpoison 條目不變。那裡沒有什麼可清除的，只有腐敗，所以完全放棄清除。（CVE-2026-80893）

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

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

  - fuse：修正檢查 io-uring 整備狀態時遺失的屏障 fuse_block_alloc（） 讀取 fch->initialized，然後讀取 fch->io_uring。fch->io_uring 設定在 fch->initialized 之前，由 fuse_chan_set_intialized（） 中的 smp_wmb（） 排序，但 fuse_block_alloc（） 在兩個負載之間沒有相符的讀取屏障。
    這可能會導致 CPU 觀察到 fch->initialized=1 但 fch->io_uring=0，並跳過阻止請求分配的檢查，直到 io-uring 佇列準備就緒為止。這可能會重新引入確定 3393ff964e0f 阻止的鎖定順序反轉鎖死。新增 smp_rmb（） 屏障以與 fuse_chan_set_initialized（） 中的 smp_wmb（） 配對以防止此情況發生。（CVE-2026-80859）

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

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

  - HID： core：修正 hid_set_field（） 中 field->usage 的 OOB 讀取 hid_set_field（） hands field->usage + offset 到 hid_dump_input（） 在邊界 offset 的防護之前：hid_dump_input（field->report->device， field->usage + offset， value）;if （offset >= field->report_count） { hid_err（...）; return -1; }在 CONFIG_DEBUG_FS hid_dump_input（） 下取消參照該指標，buf = hid_resolv_usage（usage->hid， NULL）。usage[] 陣列與 hid_register_field（） 中的 hid_field 內嵌分配，並保存 field->maxusage 項目，因此超過它的偏移量會讀取 kvzalloc（） 分配的末尾並進入相鄰物件。如果保護先執行，位移 < report_count <= maxusage 就已經將指標限制在陣列上。今天，呼叫者提供了這樣的偏移量。picolcd_fb_send_tile（） 在針對 i = 0..31 發出 hid_set_field（report->field[0]， 11 + i， ...） 之前僅驗證 report->maxfield，因此其位移固定為 11..42，並且永遠不會針對綁定欄位進行檢查。當裝置以較少的使用方式註冊該欄位時，畫面緩衝區延遲 io 工作會驅動每個圖塊的讀取。KASAN 在 hid_set_field（） 下方的 hid_dump_input（） 中報告 4 位元組的 slab-out-of-bound 讀取，並且相同的啟動日誌偏移量 （1） 超過了僅在之後執行的防護的 report_count （1）。將 hid_dump_input（） 呼叫移至防護下方。因為 field->maxusage >= field->report_count，所以守衛接著會針對每個調用方建立 field->usage + offset 位於陣列內，而不會改變有效路徑上的行為。
    由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-80781）

請注意，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 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - net/tcp-ao：修正重新連接到另一個對等體時的current_key釋放後使用 tcp_inbound_ao_hash（），在獲取 bh_lock_sock_nested（） 之前呼叫，僅保留 rcu_read_lock（）。在已建立通訊端的快速路徑上，如果對等傳送的rnext_keyid與 current_key->sndid 不同，則會查詢對等要求的金鑰並將其儲存在 current_key 中。查閱位於 RCU 讀取端內，但current_key比它更長。當通訊端中斷連線並且再次為另一個對等體呼叫 connect（） 時，tcp_ao_connect_init（） 會取消與新對等體不相符的每個金鑰的連結，並使用 call_rcu（） 將其釋放。如果current_key指向這類索引鍵，則會清除為 NULL。快速路徑在進入時僅讀取一次sk_state，因此在通訊端仍處於建立狀態時進入其中的 softirq 可以在該迴圈運行後current_key更新。更新位於 RCU 讀取端內，因此它位於 call_rcu（） 回呼之前，一旦回呼釋放金鑰，current_key就會指向釋放的記憶體。下一次傳輸會在 tcp_get_current_key（） 中拾取該指標。然後，tcp_ao_transmit_skb（） 從釋放的物件中讀取流量金鑰，即釋放後使用。等待一個寬限期後再取消連結，且僅在要移除金鑰時才取消連結。
    當 tcp_connect（） 運行時，通訊端已經處於TCP_SYN_SENT中，並且TCP_AO_ESTABLISHED不包含TCPF_SYN_SENT，因此等待後進入的 softirq 無法到達快速路徑，並且已經在其中的 softirq 已經完成。迴圈中現有的 NULL 處理就足夠了。（CVE-2026-80849）

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

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

  - Undici 的重試處理常式可能會讓已公開的回應內文永遠擱置。當伺服器傳回宣告 Content-Length、僅傳送部分內文並關閉連線的成功回應時，重試處理常式會重試要求。如果重試傳回不可重試的狀態，例如 400，處理常式會將新的回應轉送至下游，並取代其內部回應資料流程，但應用程式仍保留的原始回應本文永遠不會結束或銷毀。因此，讀取該內文的呼叫永遠不會結算，而且設定的內文逾時不會觸發，因為其計時器系結至連線剖析器，而不是孤立的主體。攻擊者控制的伺服器可以透過兩個簡短的回應來觸發此問題，而無需保持連線開啟狀態，並且重複的請求會累積擱置的承諾和資料流，從而耗盡應用程式並發或記憶體。這會影響從 到 7.29.1 和從 8.10.28.0.0 到 的 undici 版本7.11.0。使用者應升級至 undici 7.29.1 或 8.10.2.
    (CVE-2026-18149)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - nfc： llcp：拒絕短於 LLCP 標頭的 PDU 每個 LLCP PDU 都以兩個位元組的標頭 （DSAP/SSAP + PTYPE） 開頭，但接收路徑在剖析之前從未檢查框架是否至少為 LLCP_HEADER_SIZE 位元組。nfc_llcp_rx_skb（） 透過 nfc_llcp_ptype（）/nfc_llcp_dsap（）/ nfc_llcp_ssap（） 讀取標頭，取消參照 pdu->data[0] 和 pdu->data[1]，然後 CONNECT 或 CC PDU 計算 tlv_array_len = skb->len - LLCP_HEADER_SIZE;作為size_t並將其交給 TLV 步行。當框架比標頭短時，減法會換行到一個巨大的值，並且遍歷遠遠超過緩衝區，即越界讀取。附近的 NFC 裝置無需身份驗證即可到達此目的;LLCP 連結啟動會在 NFC-DEP 之後自動發生。保護目標 （nfc_llcp_data_received（）） 和啟動器 （nfc_llcp_recv（）） 路徑共用的通用接收阻塞點 __nfc_llcp_recv，以便在 rx_work 工作程式剖析之前刪除短 skb。使用 pskb_may_pull（） 而不是 skb->len 測試，因此即使對於非線性 skb，也保證兩個標頭位元組位於 skb 線性區域中，以符合同級 NCI 和 HCI 接收路徑驗證其標頭的方式。在 linux-next 上透過 /dev/virtual_nci 使用 KFENCE 越界讀取重現。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。
    (CVE-2026-80798)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - wifi：MT76：MT7925：確保 usb_sdio_tx_prepare_skb mt7925_usb_sdio_tx_prepare_skb（） 中的 TX 餘量將 TX 描述元和 USB 標頭推送到每個 skb 上，並假設它們的餘量已經存在。這適用於本機產生的流量，其中 mac80211 保留 hw->extra_tx_headroom，但轉送的框架是透過 ieee80211_8023_xmit（） 傳送的，而 （） 不會保留它。將有線介面橋接到 mt7925u AP 和到達的第一個轉發幀，短時間錯誤核心：skbuff：skb_under_panic：len：415 put：4 tail：0x19b end：0x640 dev：wlan1 核心錯誤位於 net/core/skbuff.c：212！呼叫追蹤：skb_panic+0x58/0x60 （P） skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common] mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb] __mt76_tx_queue_skb+0x54/0xe8 [mt76] mt76_txq_schedule.part.0+0x204/0x478 [mt76] mt76_txq_schedule_all+0x50/0x80 [mt76] mt792x_tx_worker+0x68/0x100 [mt792x_lib] __mt76_worker_fn+0x84/0x150 [mt76] 給定的設定是否成功取決於輸入的空間netdev 會在其 rx skb 中留下。在將板載乙太網路橋接到 Netgear A9000的 Raspberry Pi 5 上重現;最初報告在執行 OpenWrt 的路由器上 MT7986 。
    尼克·莫羅 （Nick Morrow） 在 Pi 4 （bcmgenet） 上進行的測試留下了更多的餘量，有助於縮小進入路徑的觸發範圍。同樣的錯誤已透過提交 98c4d0abf5c4 在 mt7921 上修正 （mt76： mt7921：不要假設 SDIO 標頭有足夠的空間），但 mt7925 是從 mt7921 複製的，沒有修正。在這裡添加相同的守衛。（CVE-2026-80825）

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

ID	名稱	嚴重性
343072	Linux Distros 未修補弱點：CVE-2026-80741	high
343071	Linux Distros 未修補弱點：CVE-2026-80735	high
343070	Linux Distros 未修補弱點：CVE-2026-80745	high
343069	Linux Distros 未修補弱點：CVE-2026-80746	medium
343068	Linux Distros 未修補弱點：CVE-2026-84256	high
343067	Linux Distros 未修補弱點：CVE-2026-80729	high
343066	Linux Distros 未修補弱點：CVE-2026-80750	high
343065	Linux Distros 未修補弱點：CVE-2026-84989	high
343064	Linux Distros 未修補弱點：CVE-2026-82312	low
343063	Linux Distros 未修補弱點：CVE-2026-80736	high
343062	Linux Distros 未修補弱點：CVE-2026-80749	high
343061	Linux Distros 未修補弱點：CVE-2026-78221	medium
343060	Linux Distros 未修補弱點：CVE-2026-81738	low
343059	Linux Distros 未修補弱點：CVE-2026-85394	critical
343058	Linux Distros 未修補弱點：CVE-2026-84383	critical
343057	Linux Distros 未修補弱點：CVE-2026-80751	high
343047	Linux Distros 未修補弱點：CVE-2026-80845	high
343046	Linux Distros 未修補弱點：CVE-2026-80826	high
343045	Linux Distros 未修補弱點：CVE-2026-80863	high
343044	Linux Distros 未修補弱點：CVE-2026-80864	medium
343043	Linux Distros 未修補弱點：CVE-2026-80883	medium
343042	Linux Distros 未修補弱點：CVE-2026-80764	medium
343041	Linux Distros 未修補弱點：CVE-2026-80790	medium
343040	Linux Distros 未修補弱點：CVE-2026-80766	high
343039	Linux Distros 未修補弱點：CVE-2026-80842	high
343038	Linux Distros 未修補弱點：CVE-2026-80902	medium
343037	Linux Distros 未修補弱點：CVE-2026-80834	high
343036	Linux Distros 未修補弱點：CVE-2026-80844	high
343035	Linux Distros 未修補弱點：CVE-2026-80802	medium
343034	Linux Distros 未修補弱點：CVE-2026-80824	high
343033	Linux Distros 未修補弱點：CVE-2026-80872	high
343032	Linux Distros 未修補弱點：CVE-2026-80843	medium
343031	Linux Distros 未修補弱點：CVE-2026-80795	medium
343030	Linux Distros 未修補弱點：CVE-2026-80801	medium
343029	Linux Distros 未修補弱點：CVE-2026-80909	medium
343028	Linux Distros 未修補弱點：CVE-2026-80786	high
343027	Linux Distros 未修補弱點：CVE-2026-80866	medium
343026	Linux Distros 未修補弱點：CVE-2026-80836	high
343025	Linux Distros 未修補弱點：CVE-2026-80848	medium
343024	Linux Distros 未修補弱點：CVE-2026-80780	high
343023	Linux Distros 未修補弱點：CVE-2026-80907	medium
343022	Linux Distros 未修補弱點：CVE-2026-80771	medium
343021	Linux Distros 未修補弱點：CVE-2026-80893	medium
343020	Linux Distros 未修補弱點：CVE-2026-80859	medium
343019	Linux Distros 未修補弱點：CVE-2026-80781	medium
343018	Linux Distros 未修補弱點：CVE-2026-80837	medium
343017	Linux Distros 未修補弱點：CVE-2026-80849	high
343016	Linux Distros 未修補弱點：CVE-2026-18149	medium
343015	Linux Distros 未修補弱點：CVE-2026-80798	medium
343014	Linux Distros 未修補弱點：CVE-2026-80825	medium

偵測

Nessus 的 Misc. 系列

high

high

high

medium

high

high

high

high

low

high

high

medium

low

critical

critical

high

high

high

high

medium

medium

medium

medium

high

high

medium

high

high

medium

high

high

medium

medium

medium

medium

high

medium

high

medium

high

medium

medium

medium

medium

medium

medium

high

medium

medium

medium