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

  - dm-verity：將錯誤計數器設為不可部分完成 錯誤計數器 v->corrupted_errs 不是不可部分完成的，因此可能會受到爭用情形的影響。由於爭用，可能會跳過對 dm_audit_log_target（max-corrupted-errors） 的呼叫。（CVE-2026-72096）

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

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

  - Bluetooth： ISO：修正格式錯誤的 ISO_END/CONT 處理核心規格 （Part C vol 4 sec 5.4.5） 不排除空ISO_CONT、ISO_END封包。如果它們是最後的，我們目前會拒絕它們。如果控制器發送格式錯誤的序列ISO_START -> rx_len = 4，ISO_CONT skb->len 4，ISO_START以 ISO_CONT 結束有效負載，我們就會洩露 conn->rx_skb。如果控制器發送的ISO_END太長，我們會在 skb_put 上感到恐慌。如果控制器發送太短ISO_END我們接受。透過 conn->rx_skb ！= NULL 標記未完成的ISO_START來修正。skb_put前請正確檢查 skb->len。結合 ISO_CONT/END 程式碼路徑，因為它們需要相同的初始檢查。
    拒絕太短的ISO_END封包。（CVE-2026-72334）

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

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

  - net/sched： sch_taprio：將直接出列呼叫替換為 peek 和 qdisc_dequeue_peeked 當 taprio 的軟體路徑窺視非工作保存子 qdisc 時，子項會將窺視的 skb 隱藏在其 gso_skb;
    然後，taprio_dequeue_from_txq（） 透過直接子 ->dequeue（） 呼叫來獲取封包，該呼叫會忽略該隱藏，孤立被窺視的 skb 並取消子級的 qlen/backlog 同步。對於 qfq 子項，這會在清空清單中重新輸入子項並取消參照 NULL，從而在普通出口時使核心從 softirq 中出現恐慌。通過 qdisc_dequeue_peeked（） 獲取數據包，就像 sch_red 和 sch_sfb 現在所做的那樣。協助程式會先歸還孩子隱藏的 skb，當沒有 skb 時，則為無操作，因此節省工作的孩子不會受到影響，而且門控路徑現在會消耗其長度計入預算的 skb。（CVE-2026-72035）

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

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

  - ocfs2：在 inode 讀取期間驗證快速符號連結目標 ocfs2_validate_inode_block（） 在數個不一致的獨立雙節點公開給檔案系統的其餘部分之前，已經拒絕了它們。快速符號連結需要相同的處理。零叢集符號連結會被視為快速符號連結，稍後會讀取 page_get_link（） 和 ocfs2_fast_symlink_read_folio（）。該路徑在內嵌負載上使用 strnlen（），然後將 len + 1 位元組複製到對開本中。如果損毀的 dinode 儲存不符合內嵌區域的 i_size，或在i_size省略終止 NUL，則該副本會讀取超過 inode 區塊緩衝區的結尾。拒絕零叢集符號連結雙節點，其i_size超過內嵌快速符號連結容量，或其內嵌承載未在驗證 inode 區塊時完全在 i_size 時以 NUL 終止。這可防止格式錯誤的快速符號連結到達讀取路徑。驗證重現了此核心報告： ocfs2_fast_symlink_read_folio+0x12c/0x1f0 中的 KASAN 釋放後使用 RIP：0033：0x7f5c6d859aa7 讀取大小為 3905 呼叫追蹤：dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xce/0x630 （？：？） ocfs2_fast_symlink_read_folio+0x12c/0x1f0 （fs/ocfs2/inode.c：？） srso_alias_return_thunk+0x5/0xfbef5 （？：？）
    __virt_addr_valid+0x19f/0x330 （？：？） kasan_report+0xe0/0x110 （？：？） kasan_check_range+0x105/0x1b0 （？：？）
    __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)（CVE-2026-74350）

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

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

  - pmdomain： imx93-blk-ctrl： 擷取 PHY 作為 DSI/CSI 的共用網域 MIPI DSI 和 CSI 網域共用時鐘和重設的控制位元，如果一個網域停用共用資源而另一個網域仍處於作用中狀態，可能會導致不正確的行為。若要解決此問題，請引入共用 MIPI PHY 電源網域來擁有通用資源，並將 DSI 和 CSI 設為其子網域。這可確保共用位元得到妥善管理，並且在仍在使用時不會停用。（CVE-2026-72009）

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

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

  - coresight： platform：延遲連線計數器增量，直到 alloc 成功為止 coresight_add_out_conn（） 在呼叫 devm_krealloc_array（） 之前和 devm_kmalloc（） 之前nr_outconns遞增。如果任一配置失敗，則計數器已經被顛簸，而對應的陣列項目是 NULL 或未初始化的垃圾。coresight_add_in_conn（） 對 nr_inconns 和 devm_krealloc_array（） 有相同的問題。在這兩種情況下，探查都會傳回 -ENOMEM，這會導致 coresight_get_platform_data（） 呼叫 coresight_release_platform_data（） 進行清理。該函式最多可反覆運算 nr_outconns （或 nr_inconns） 個項目，並無條件地解除參照每個指標，命中 NULL 或垃圾項目並發生錯誤，而不是正常失敗。透過將計數器增量移動到所有配置成功之後來修正，以便結構在任何錯誤路徑上始終保持一致。（CVE-2026-72485）

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

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

  - 9p：在無快取模式下跳過 nlink 更新，以修正 WARN_ON v9fs_dec_count（） 在一般檔案上無條件呼叫 drop_nlink（），即使 inode 的 nlink 已經為零。在無快取模式下，用戶端會在每次操作時從伺服器（事實來源）重新擷取 inode 中繼資料，因此當 v9fs_remove（） 傳回時，本機快取的 nlink 可能已經反映了取消連結後的值： 1. 用戶端啟動解除連結，伺服器對其進行處理並將 nlink 設定為 0 2.在取消連結之前，用戶端重新擷取 inode 中繼資料 （nlink=0） 傳回 3。用戶端的 v9fs_remove（） 成功完成 4.用戶端呼叫 v9fs_dec_count（），該 （） 在 nlink=0 上呼叫 drop_nlink（） 此爭用在繁重的取消連結工作負載下很容易觸發，例如 stress-ng 的取消連結壓力源，從而產生以下警告： 警告：fs/inode.c：417 在 drop_nlink+0x4c/0xc8 呼叫追蹤：
    drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... 在無快取模式下，伺服器是權威的，而 inode 正在退出，因此在本地調整 nlink 不會購買任何東西。當 CACHE_META 和 CACHE_LOOSE 都未設定時，完全跳過 v9fs_dec_count（），這既避免了警告，又刪除了一類 nlink 爭用（兩個並發解除連結器觀察 nlink > 0，並且都調用 drop_nlink（）），僅 nlink == 0 防護只會縮小而不是關閉。
    (CVE-2026-72170)

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

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

  - mtd：mchp23k256：將 SPI 比對資料用於晶片上限 驅動程式會將晶片容量資訊儲存在 OF 相符資料表和 SPI ID 資料表中。Probe 目前使用 of_device_get_match_data（），因此即使 SPI ID 表選擇了不同的部分，非 OF SPI 模態比對也會回歸到 mchp23k256_caps。使用 spi_get_device_match_data（），以便在缺少 OF 比對資料時使用 SPI id-table driver_data。這會保留現有的預設後援，同時避免僅限 id-table 相符的錯誤 MTD 幾何圖形。
    (CVE-2026-68467)

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

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

  - mm/mm_init：修正 ZONE_DEVICE 的未初始化結構頁面 如果 DAX 記憶體熱插拔到早期區段的未佔用子區段中，section_activate（） 會重複使用未最佳化的開機記憶體。但是，compound_nr_pages（） 仍假設 vmemmap 最佳化正在生效，並且僅初始化減少的結構頁數。因此，剩餘的尾部結構頁面未初始化，這在以後可能會導致意外行為或崩潰。在計算要初始化的結構頁面數目時，將早期區段視為未最佳化，以修正此問題。（CVE-2026-72172）

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

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

  - xprtrdma：修正 ADDR_CHANGE rpcrdma_cm_event_handler（） 上的 ep kref 不平衡，當事件在 RDMA_CM_EVENT_ESTABLISHED 之前到達時，（） 會落入 RDMA_CM_EVENT_ADDR_CHANGE disconnected： 標籤，並在沒有相符的 get 的情況下呼叫 rpcrdma_ep_put（）。然後，kref 在連接拆卸期間下溢，rpcrdma_xprt_disconnect（） 在釋放的 ep 上運行。正常連線生命週期中的參照計數：
    rpcrdma_ep_create（） kref_init ->1 rpcrdma_xprt_connect（） ep_get ->2 （post_recvs 之前） RDMA_CM_EVENT_ESTABLISHED ep_get ->3 RDMA_CM_EVENT_DISCONNECTED ep_put ->2 rpcrdma_xprt_drain（） ep_put ->1 rpcrdma_xprt_disconnect（） 尾ep_put ->0 （ep_destroy） 連接時間 rpcrdma_xprt_connect（） 之前，rpcrdma_post_recvs當有未完成的接收時， 由rpcrdma_xprt_drain平衡。ESTABLISHED 之前的 ADDR_CHANGE 沒有 get 可供消費，因此它的 put 將計數降至 1，然後 drain put 釋放 ep，而 rpcrdma_xprt_disconnect（） 仍然持有指向它的指標。透過 xchg（） 在先前的re_connect_status上分派來修正：對於 prev == 0 （預先建立），喚醒連接服務程式並返回，不放;對於 prev == 1，呼叫 rpcrdma_force_disconnect（） 並返回。case-1 臂依賴後續的 RDMA_CM_EVENT_DISCONNECTED 事件（在仍然連接的cm_id上呼叫 rdma_disconnect（） 時可靠地傳遞）來平衡 ESTABLISHED get;rpcrdma_xprt_drain（） 繼續僅平衡該連接時間 get。任何其他先驗值都表示拆卸已在進行中。
    (CVE-2026-72469)

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

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

  - xen/pvcalls：在索引 rsp[] pvcalls_front_event_handler（） 之前綁定後端回應req_id直接從後端提供的 ring 回應中獲取req_id，並使用它來索引 memcpy（） 和 store 的固定大小 bedata->rsp[] 陣列，無需檢查範圍。惡意或有錯誤的後端可能會設定req_id過去的PVCALLS_NR_RSP_PER_RING，並驅動越界寫入超出 bedata 配置。當線路欄位 rsp->req_id 為 u32 時，req_id也被宣告為 int，因此僅對帶正負號的值進行範圍檢查是不夠的：後端req_id 0xffffffff 變為 -1，通過 >= PVCALLS_NR_RSP_PER_RING 測試並索引 bedata->rsp[-1]。將req_id宣告為 u32，以便單一邊界涵蓋兩端。傳送超出範圍req_id的後端已違反有線通訊協定，因此與其無訊息地刪除回應，不如記錄一次並停止信任後端：set bedata->disabled。然後，事件處理常式會忽略進一步的回應，而等待回應的要求路徑會傳回 -EIO，而不是永遠封鎖。這反映了 xen-netback 使用的致命錯誤處理 （xenvif_fatal_tx_err（））。pvcalls 前端目前信任其後端，因此這不是傳統的 Xen 安全問題，但對於針對惡意後端（機密和分解部署）強化 PV 前端很重要。（CVE-2026-72380）

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

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

  - RDMA/bnxt_re：韌體拆卸後釋放 CQ 切換頁面 只有在韌體拆卸完成後才釋放切換頁面，以便 bnxt_qplib_destroy_cq（） 期間到達的 NQ 中斷不會將切換值寫入已釋放的頁面。在bnxt_qplib_destroy_cq之後移動 free_page（）。（CVE-2026-72499）

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

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

  - netfilter： nft_fib：拒絕 netdev 輸出勾點上的 fib 運算式 netdev 輸出基本鏈中的 fib 運算式解除參照 nft_in（pkt），傳輸路徑上為 NULL，導致評估時出現 NULL 指標解除參照。nft_fib_validate（） 會使用 NF_INET_* 值遮罩勾點，但 netdev 鉤子編號是一個單獨的列舉，可別名它們 （NF_NETDEV_EGRESS == NF_INET_LOCAL_IN），因此出口鏈會通過驗證，然後出錯。新增 nft_fib_netdev_validate（），將每個結果/旗標限制到它讀取的裝置所在的 netdev 鉤子：輸入裝置案例 （OIF、OIFNAME、ADDRTYPE 與 F_IIF） 進入，輸出裝置案例 （ADDRTYPE 與 F_OIF） 輸出，無裝置標誌的 ADDRTYPE 兩者。同時將 nft_fib_validate（） 限制為 NFPROTO_IPV4/IPV6/NET，這樣它的 NF_INET_* 遮罩就不會套用到其他系列的勾點。（CVE-2026-72254）

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

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

  - OpenStack Octavia 透過 18.0.0 不當處理服務品質 （QoS） 原則授權。透過將另一個專案的 QoS 原則與 amphora 建立關聯，經過驗證的使用者可能會阻止刪除該原則。
    所有 Octavia 部署都會受到影響。（CVE-2026-74248）

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

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

  - xprtrdma：修正 bcall rep 洩漏和不受限制的 peek rpcrdma_is_bcall（） 解碼回覆的第一個單字，以判斷框架是否為反向通道呼叫。該解碼路徑中的兩個問題會讓簡短或格式錯誤的回覆洩漏接收緩衝區，並清空接收佇列。首先，推測性窺視 p = xdr_inline_decode（xdr， 0）;/* 後面有五個 p++ 讀取 */ 要求 xdr_inline_decode（） 提供零位元組，這會在不諮詢 xdr->end 的情況下傳回 xdr->p。然後，後續的五個 __be32 讀取最多可通過線負載 20 位元組，進入過時的 regbuf 內容，並將回覆錯誤分類為反向通道呼叫。其次，在後窺視 p = xdr_inline_decode（xdr， 3 * sizeof（*p））;if （unlikely（！p）） 傳回 true;短標頭臂傳回 true，而不呼叫 rpcrdma_bc_receive_call（）。與調用方的合約是，真正的 return 會將 rep 的所有權轉移到反向通道路徑：rpcrdma_reply_handler（） if （rpcrdma_is_bcall（r_xprt， rep）） return;/* 裸返回，跳過 out_post */ ...out_post：
    rpcrdma_post_recvs（r_xprt，製作人員名單 + ...）;因為 rpcrdma_bc_receive_call（） 從未運行過，所以沒有人獲得代表，但rpcrdma_reply_handler仍然在 rpcrdma_rep_put（） 和 rpcrdma_post_recvs（） 之後獲得光回報。代表具有持續 DMA 對應的接收緩衝區，在 rb_all_reps 上孤立，只有在傳輸拆卸時才釋放。此完成不會重新發布任何內容，因此只有在稍後的轉發通道回覆到達out_post並且 rpcrdma_post_recvs（） 分配新的代表進行回填時，才會回收其插槽;如果沒有該流量，接收佇列就會清空，而對等的傳送會繪製 RNR NAK。在零長度窺視之後諮詢 xdr->end 來修正，這樣除非剩餘 20 個位元組的有線負載，否則五個__be32讀取無法執行。需要與 xdr->end 進行位元組精確比較，因為非 4 對齊接收會將資料流的字數四捨五入超過真實承載。還要從短標頭臂傳回 false，以便回覆通過正常的out_norqst清理鏈（rpcrdma_rep_put（） 加上 rpcrdma_post_recvs（））。（CVE-2026-72466）

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

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

  - ksmbd：將開啟器認證用於 FSCTL 突變 SET_SPARSE、SET_ZERO_DATA 和 SET_COMPRESSION 在開啟的 SMB 控制碼上運作，但使用目前的 ksmbd 背景工作者認證呼叫 VFS xattr、fallocate 或 fileattr 協助程式。這些協助程式可以獨立於 SMB 處理存取遮罩，重新驗證 inode 權限、擁有權和 LSM 原則。使用開啟控制碼時在目標檔案中擷取的認證來執行每個作業。將認證處理保留為這些單一檔案 FSCTL 的本機，而不是將工作階段認證套用至完整的 IOCTL 處理常式，其中也包含無控制碼和多控制碼作業。
    (CVE-2026-68457)

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

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

  - afs：修正 inode 的重新初始化，特別是 ->lock_work 似乎在 slab 的 init 函式中初始化一次 afs_vnode：：lock_work 並不足以work_structs。這會導致DEBUG_OBJECTS除錯內容在執行 generic/131 xfstest 時偶爾產生警告： ODEBUG： Activate Not Available （Active State 0） object： 0000000016d8760f object type： work_struct hint： afs_lock_work+0x0/0x220 警告： lib/debugobjects.c：629 at debug_print_object+0x4b/0x90， CPU#3：
    locktest/7695 ... CPU：3 UID：0 PID：7695 通訊：locktest 污染：G S 7.1.0-build3+ #2771 搶佔 ... RIP：
    0010：debug_print_object+0x65/0x90 ... 呼叫追蹤： <TASK> ？ __pfx_afs_lock_work+0x10/0x10 debug_object_activate+0x122/0x170 insert_work+0x25/0x60 __queue_work+0x2e0/0x340 queue_delayed_work_on+0x48/0x70 afs_fl_release_private+0x57/0x70 locks_release_private+0x5c/0xa0 locks_free_lock+0xe/0x20 posix_lock_inode+0x55f/0x5b0 locks_lock_inode_wait+0x81/0x140 ？ file_write_and_wait_range+0x50/0x70 afs_lock+0xcd/0x110 fcntl_setlk+0x10d/0x260 do_fcntl+0x24e/0x5b0
    __do_sys_fcntl+0x6a/0x90 do_syscall_64+0x11e/0x310 entry_SYSCALL_64_after_hwframe+0x71/0x79 在配置 inode 後重新初始化 ->lock_work 來修正此問題。此外，當 inode 被驅逐時，請排清 ->lock_work，以確保它不會仍在執行。（CVE-2026-72375）

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

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

  - drm/radeon：修正 radeon_align_pitch（） 中的整數溢位 radeon_align_pitch（） 與舊的 amdgpu 協助程式具有相同的溢位問題：對齊四捨五入加法和最終的「對齊 * cpp」計算都可能溢位帶正負號的 int。如果包裝，radeon_mode_dumb_create（） 最終可能會傳回無效的音高或建立零大小的啞緩衝區。透過使用 check_add_overflow（） 進行對齊四捨五入，並使用 check_mul_overflow（） 進行最終音高計算來解決此問題，在溢位時傳回 0。也拒絕 radeon_mode_dumb_create（） 中的零間距和大小。使用 sqry 透過基於 AST 的呼叫圖分析找到。（CVE-2026-74417）

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

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

  - IB/mlx5：修正傳輸網域復原並儘早初始化 lb 互斥 mlx5_ib_alloc_transport_domain（） 會配置傳輸網域，然後可能會在 mlx5_ib_enable_lb（） 中失敗。在這種情況下，分配的 TD 會洩漏。透過在 mlx5_ib_enable_lb（） 傳回錯誤時取消配置 TD 來修正此問題。也在 no-loopback-capability success 分支中明確傳回 0，並將 dev->lb.mutex 初始化移至 mlx5_ib_stage_init_init（）。（CVE-2026-74397）

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

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

  - xprtrdma：將 req 回收與RPC完成分離，rl_kref先前透過單一參照計數提供兩個不同的存留期：當 Reply 可以喚醒其RPC工作時，它會進行門控，當 rpcrdma_req 可以返回其可用集區時，它會進行門控。只有在 SGE 需要 DMA 取消映射 （sc_unmap_count > 0） 時，封送處理路徑才採用發送端參照，這使得僅攜帶預先註冊緩衝區的發送成為例外狀況：回覆處理常式將rl_kref從 1 降至 0，並在 HCA 可能仍在從其傳送緩衝區讀取 DMA 時釋放要求。給rl_kref一個更窄的工作。當插槽分配發出要求時，RPC 層會接受一個參考。rpcrdma_prepare_send_sges（） 會在 WR 準備成功之後，無條件地取得 Send-side 參照。xprt_rdma_free_slot（） 和 xprt_rdma_bc_free_rqst（） 刪除RPC層參照;
    rpcrdma_sendctx_unmap（） 會刪除傳送端參照。只有在雙方所有者都簽字後，該請求才會返回其免費池。已移除 rpcrdma_prepare_send_sges（） 中現有的 kref_init（&req->rl_kref） 呼叫。初始化會移至插槽配置路徑 （xprt_rdma_alloc_slot 和 rpcrdma_bc_rqst_get），而釋放回呼會在 req 返回可用集區之前重新布防rl_kref。封送處理路徑中的重新初始化會捨棄項目上已存在的 RPC 層參考。以下有三個不變量： - rpc_rqst所持有的任何rpcrdma_req都有 rl_kref >= 1。xprt_rdma_alloc_slot（）、rpcrdma_bc_rqst_get（） 和 xprt_rdma_alloc_slot（） 中的 backlog-wake 分支在發佈要求之前kref_init rl_kref。如果沒有這個不變量，在插槽分配和封送處理之間中止的RPC任務（例如，在call_connect期間gss_refresh故障或訊號）將驅動 xprt_release（） -> xprt_rdma_free_slot（） -> kref_put 而不是零的參照計數，使refcount_t飽和並擱淺插槽。- 只有在 WR 準備成功之後，才會取得傳送端參照。rpcrdma_prepare_send_sges（） 中的對應失敗會執行 rpcrdma_sendctx_cancel（），該 DMA 會取消對應 sendctx 並清除sc_req而不碰rl_kref。sendctx 環在 rpcrdma_sendctx_put_locked（） 和 rpcrdma_sendctxs_destroy（） 中遍歷具有 sc_req == NULL 的項目，因此一連串的 -EIO 封送處理失敗無法阻止 reqs 關閉rb_send_bufs。- 釋放回呼會重新武裝rl_kref，讓下一個消費者在滿足不變量的情況下進入。回覆現在會直接完成 RPC。
    rpcrdma_reply_handler（） 呼叫 rpcrdma_complete_rqst（） 來取代非 LocalInv 分支上的kref_put。LocalInv 分支已完成從 frwr_unmap_async（） 的RPC，並且不受影響。由於傳送端參照現在可能比 RPC 完成時間更長，因此連線中斷會耗盡 sendctx 項目，而這些項目的無訊號傳送從未有稍後的訊號完成，以遍歷環路。在重設要求緩衝區之前，rpcrdma_sendctxs_destroy（） 遍歷活動範圍並在每個項目上以非 NULL sc_req執行 rpcrdma_sendctx_unmap（），並在 rpcrdma_xprt_disconnect（） 中移動到 rpcrdma_reqs_reset（） 之前，因此當釋放發送端參照時，要求仍處於預重置狀態。排水管會在反通道路徑上造成拆解排序危險。使用新的存留期時，從 rpcrdma_req_release（） 釋放bc_prealloc要求會將其重新新增至bc_pa_list。xprt_rdma_destroy（） 中的斷開連接會在 xprt_destroy_backchannel（） 已經清空bc_pa_list之後運行，因此耗盡的 reqs 會洩漏。xprt_rdma_destroy（） 現在會在中斷連線後第二次執行 xprt_rdma_bc_destroy（xprt， 0） 以回收它們。（CVE-2026-72473）

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

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

  - bpf：遮罩驗證程式記錄中的虛擬指標值 print_bpf_insn（） 遮罩 ldimm64 會在不允許指標洩漏時立即針對帶有指標的虛擬來源，但遮罩僅涵蓋BPF_PSEUDO_MAP_FD和BPF_PSEUDO_MAP_VALUE。BPF_PSEUDO_MAP_IDX、BPF_PSEUDO_MAP_IDX_VALUE和BPF_PSEUDO_BTF_ID也可以在驗證程式記錄列印指令之前解析為核心指標值。將它們包含在現有的指標分類中，以便記錄列印0x0而不是重寫的位址。（CVE-2026-72402）

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

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

  - ixgbe：不要為 XDP 佇列設定 xps netif_set_xps_queue（） 不應該針對 XDP Tx 佇列呼叫，因為這類佇列不會公開 netdev。在 CPU 數目為 >=64 的系統上，在轉接器上 E610 ，netdev 會設定為佇列配對數目上限為 63 （因為 MSI-X 指派），但設定 XDP 會導致 64 個 XDP 佇列。因此，在 XDP 程式載入期間，當為最後一個 XDP 佇列呼叫 netif_set_xps_queue（） 時，我們會收到一個 WARNING，其中包含呼叫追蹤和之後的 KASAN 報告（如果啟用）。[ 2012.699800] 警告：net/core/dev.c：2854，__netif_set_xps_queue+0x116a/0x1e40， CPU#36：xdpsock/103668 [...][2012.700029] RIP： 0010：__netif_set_xps_queue+0x116a/0x1e40 [ 2012.700035] 代碼：b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84 [ 2012.700040] RSP： 0018：ffff8882369aeb28 EFLAGS：00010246 [ 2012.700046] RAX：00000000000000000000 RBX：000000000000003f RCX：0000000000000000000 [2012.700050] RDX：1ffff1111da3d891 RSI：ffff888120e34250 RDI：ffff8888ed1ec488 [ 2012.700054] RBP：
    ffff888913281560 R08： 0000000000000000 R09： ffff8888ed1ec000 [ 2012.700058] R10： ffff8888a2e83180 R11：
    0000000000000000 ： 0000000000007fa8 [ 2012.700061] R13： 000000000000003f R14： ffff888120e34854 R15R12：
    ffff8889132817c8 [ 2012.700065] FS：00007fc8ea9ff740（0000） GS：ffff88884cefe000（0000） knlGS：000000000000000000000 [ 2012.700069] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [ 2012.700073] CR2：
    00007f81c8000020 CR3： 00000002299f8006 CR4： 00000000007726f0 [ 2012.700077] PKRU： 55555554 [ 2012.700080] 呼叫追蹤： [ 2012.700084] <TASK> [ 2012.700087] ？ ktime_get+0x61/0x150 [ 2012.700097] ？ usleep_range_state+0x133/0x1b0 [ 2012.700108] ？ __pfx_usleep_range_state+0x10/0x10 [ 2012.700114] netif_set_xps_queue+0x31/0x50 [ 2012.700119] ixgbe_configure_tx_ring+0x472/0x920 [ixgbe] [...][2012.700486] ixgbe_xdp+0x38f/0x750 [ixgbe] [...][ 2012.701094] 錯誤：KASAN：中 slab-out-of-bounds
    __netif_set_xps_queue+0x1ac5/0x1e40 [ 2012.701100] 在 addr ffff88888d43cff8 上，由任務 xdpsock/103668 寫入大小 4 跳過 XDP Tx 佇列的 XPS 設定。（CVE-2026-74317）

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

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

  - netfilter： ipset：確保 gc 已正確停止 Sashiko 注意到，在破壞集合時，調用 cancel_delayed_work_sync（），而 gc 無條件調用 queue_delayed_work（），這可能導致無法正確關閉 gc。（CVE-2026-72434）

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

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

  - crypto：sun4i-ss - 移除不安全和未使用的 rng_alg 移除 sun4i_ss_rng，因為它不安全且未使用： - 它有多個漏洞。sun4i_ss_prng_seed（） 缺少鎖定，且有緩衝區溢位。
    sun4i_ss_prng_generate（） 無法用加密隨機位元組填充整個緩衝區，因為它會向下捨入目的地長度，而且實際上也不會等待硬體準備就緒，然後再從中提取位元組。- 不知道此程式碼的使用者。理論上只能透過 rng 演算法類型的 AF_ALG 使用。但使用者空間實際上只是使用實際的 Linux RNG（/dev/random 等）。
    而且rng_algs也不會為實際的 Linux RNG 貢獻熵。（這可能與 hwrng 混淆了，後者確實貢獻了熵。sun4i_ss_prng_seed（） 緩衝區溢位由 Tianchu Chen 報告並由 Atuin 發現 - Automated Vulnerability Discovery Engine 當這是未使用的程式碼時，單獨修復所有這些漏洞是沒有意義的，所以讓我們將其刪除。（CVE-2026-74438）

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

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

  - cpu： hotplug：綁定的熱插拔狀態 sysfs 輸出 states_show（） 使用 sprintf（） 將 CPU 熱插拔狀態名稱新增到單一 sysfs 緩衝區中。如果有足夠的已註冊狀態，這可能會寫入PAGE_SIZE緩衝區的結尾。使用 sysfs_emit_at（） 使輸出受到限制。（CVE-2026-72066）

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

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

  - minix：避免點陣圖區塊計數計算中的溢位 minix_check_superblock（） 使用 minix_blocks_needed（） 來驗證磁碟上的 IMAP 和 zmap 區塊計數是否足夠大，無法達到通告的 inode 和區域計數。協助程式目前在 unsigned int 算術中執行 DIV_ROUND_UP（）。
    Minix v3 映像檔可以將 s_ninodes 或 s_zones設定在UINT_MAX附近，因此 DIV_ROUND_UP（） 內的加法會換行為零。這使得零 imap/zmap 區塊計數看起來有效，之後 minix_fill_super（） 可以取消參照 s_imap[0] 或 s_zmap[0]，即使沒有配置點陣圖緩衝區。影響：裝載特製的 Minix v3 影像，其s_ninodes或s_zones接近 UINT_MAX，會使 minix_check_superblock（） 接受零點陣圖區塊計數和 minix_fill_super（） 解除參照 s_imap[0]/s_zmap[0]，從而使核心陷入錯誤。除數是以位為單位的點陣圖容量，區塊大小 * 8，始終是 2 的冪：minix_fill_super（） 透過 sb_set_blocksize（） 獲得區塊大小，blk_validate_block_size（） 拒絕任何不是 2 的冪的大小。使用 DIV_ROUND_UP_POW2（），它在添加四捨五入項之前進行除法，因此不能為 2 的冪除數溢位。（CVE-2026-72369）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: fix off-by-one in mapping pairs decoding bounds checks In ntfs_mapping_pairs_decompress(), attr_end points one byte past the end of the attribute record: attr_end = (u8 *)attr + le32_to_cpu(attr->length); The two bounds checks validating that mapping pair data bytes fit within the attribute use strict greater-than (>), which allows a one-byte out-of-bounds read when the data extends exactly to attr_end: b = *buf & 0xf; if (b) { if (unlikely(buf + b > attr_end)) // off-by-one goto io_error; for (deltaxcn = (s8)buf[b--]; b; b--) deltaxcn = (deltaxcn << 8) + buf[b]; } When buf + b == attr_end, the check evaluates to false and buf[b] reads one byte past the valid attribute boundary. The same pattern appears in the LCN delta bytes check. Fix both checks to use >= so that buf[b] at exactly attr_end is correctly rejected as out of bounds. (CVE-2026-72210)

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

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

  - net： udp_tunnel：防止 udp_tunnel_nic_device_sync 中的重複佇列 Yue Sun 在並行裝置操作期間，在 udp_tunnel_nic_device_sync_work（） 中報告了釋放後使用和 debugobjects 警告。工作佇列核心會在叫用背景工作程式之前清除內部擱置位元。此時，並行執行緒可以再次將工作排入佇列。當已執行的工作角色最終將work_pending旗標清除為 0 時，它會錯誤地清除新佇列執行個體的旗標。然後，udp_tunnel_nic_unregister（） 將 work_pending 觀察為 0，並在佇列中第二個工作專案仍在作用中時釋放結構，導致 UAF。如果已設定work_pending，請在 udp_tunnel_nic_device_sync（） 中儘早返回來修正此問題，以防止重複的工作佇列。（CVE-2026-72405）

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

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

  - tracing/osnoise：取消註冊時呼叫 synchronize_rcu（） 這可確保任何周遊執行個體清單的 RCU 讀取器都已完成，然後再釋放執行個體所指向的追蹤器上的參照。
    (CVE-2026-72012)

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

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

  - dmaengine： dw-edma-pcie：拒絕沒有驅動程式資料的裝置 dw_edma_pcie_probe（） 會將 PCI 裝置識別碼driver_data視為控制器配置的範本，並無條件地複製它。透過 sysfs 動態繫結的裝置可以比對沒有該資料的驅動程式，這會導致 NULL 指標解除參照。
    在啟用裝置之前，請先拒絕此類相符專案。（CVE-2026-72147）

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

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

  - cxl/region：解決區域刪除爭用 Sungwoo 注意到刪除區域的 sysfs 觸發程序可能會多次嘗試刪除區域。它也沒有排除透過 CXL 根裝置拆卸釋放區域的核心。不要在每個區域安裝新的 cxl root devres 動作，而是使用現有的根解碼器取消註冊事件來移除所有剩餘區域。區域的 xarray 會取代區域的 devres 清單。這處理了舊方法的 3 個不同問題： 1/ sysfs 使用者競相刪除相同的區域：現在不再可能，因為regions_lock被保留在查詢和刪除期間。
    2/ 多個動作觸發同一區域刪除：透過按住@regions_lock時擦除區域來解決，並且只有在擦除成功後才繼續。3/ 使用者空間競速 devres_release_all（） 以觸發 devres Not found 警告：已透過 sysfs 取消註冊解決，不需要釋放動作 （CVE-2026-74272）

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

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

  - netfs：修正 netfs_create_write_req（） 以處理非同步快取物件建立 netfs_create_write_req（） 如果停用 fscache cookie，則會跳過快取，但這是一個問題，因為非同步快取物件建立可能尚未啟用，進而導致跳過對 fscache_begin_write_operation（） 的呼叫。透過移除對 cookie 的檢查並將其委派給 fscache_begin_write_operation（） 來解決此問題。（CVE-2026-72366）

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

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

  - netfilter： xt_connmark：拒絕無效的移位參數 CONNMARK 目標的修訂版 2 接受使用者控制的移位參數，並將它們套用至 connmark_tg_shift（） 中的 32 位元標記值。評估規則時，shift_bits值為 32 或更多會觸發未定義的移位錯誤。也會接受無效的shift_dir值，並以無訊息的方式回復至左移路徑。拒絕 connmark_tg_check（） 中無效的修訂版 2 移位參數，讓格式錯誤的規則在安裝時失敗，然後才能到達封包路徑。（CVE-2026-72347）

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

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

  - sctp：在 cookie 解壓縮後新增 INIT 驗證 在 SCTP 交握中，INIT 區塊最初由伺服器處理並嵌入到 INIT-ACK 中攜帶的 cookie 中。然後，用戶端透過 COOKIE-ECHO 傳回此 cookie，伺服器在其中解壓縮並重建原始 INIT 區塊。啟用 Cookie 驗證後，Cookie 內容會受到保護，防止竄改，因此重複使用解壓縮的 INIT 而不重新驗證是安全的。但是，當停用 cookie 驗證時，重建的 INIT 就無法再受信任。在此情況下，必須在解壓縮之後明確驗證 INIT，以避免處理可能遭竄改的資料。停用 sctp_verify_init（） 時，在 COOKIE-ECHO 處理路徑 （sctp_sf_do_5_1D_ce（） 和 sctp_sf_do_5_2_4_dupcook（）） 中解壓縮 cookie 後新增 cookie_auth_enable（） 檢查。失敗時，會釋放新的關聯，並捨棄封包。此外，在將內嵌區塊類型視為 INIT 區塊之前，先驗證內嵌區塊類型是否SCTP_CID_INIT，以加強 sctp_unpack_cookie（） 中的 cookie 驗證。最後，更新 sctp_verify_init（） 以使用實際嵌入的 INIT 長度而不是區塊>chunk_end來驗證參數邊界，因為儲存在 COOKIE-ECHO 中的 INIT 可能不會跨越整個區塊緩衝區。（CVE-2026-72398）

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

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

  - Debian Linux - inetutils - 無 Ubuntu Linux - 帶有長 DNS 名稱的有聲緩衝區溢位 （CVE-2026-19720）

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

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

  - bpf：釋放時清除 rb 節點連結 bpf_rb_root bpf_rb_root_free（） 會複製目前的 rb_root_cached，然後以 RB_ROOT_CACHED 取代即時根，以分離根。接著，它會遍歷複製的根目錄，並捨棄樹狀結構中包含的每個物件。這會在捨棄物件時保持 rb 節點狀態不變。如果物件經過參照計數並在刪除後繼續存在，則其bpf_rb_node_kern仍包含釋放根和過時 rb 樹狀結構連結的所有者指標。如果稍後的bpf_rb_root配置重複使用相同的位址，則 bpf_rbtree_remove（） 可能會錯誤地通過所有者檢查，並在 rb 指標屬於舊樹狀結構的節點上呼叫 rb_erase_cached（）。在分離根時將節點標示為忙碌，以鏡像清單清空行為，然後清除 rb 節點並釋放所有者，然後再捨棄包含的物件。這使得倖存的節點無人擁有，並且可以安全地拒絕移除或接受以後的新增。
    (CVE-2026-74344)

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

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

  - netfs：修正直寫以使用集合卸載 修正直寫以設定要求的NETFS_RREQ_OFFLOAD_COLLECTION，以便以非同步方式處理集合，而不僅僅是在最後處理，並且完全可以收集非同步O_SYNC寫入。（CVE-2026-72365）

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

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

  - wifi： mac80211：在 RX 之前驗證擴充框架配置 擴充框架僅在常規 802.11 標頭位移處具有擴充標頭。通用 RX 路徑仍然可以到達協助程式和介面分派程式碼，這些協助程式和介面分派程式碼在刪除不支援的延伸模組子類型之前讀取常規標頭位址欄位。mac80211 目前僅處理 S1G 信標擴充框架。在其他延伸模組子類型到達一般標頭 RX 處理之前，先刪除它們。對於 S1G 信標，請使用管理框架路徑線性化 SKB，並在通用 RX 分派之前要求固定的 S1G 信標標頭，包括框架控制指示的可選固定欄位。透過站台/預設連結 RX 路徑路由 S1G 信標，無需常規標頭站點查詢。避免在處理 S1G 擴充信標的 mac80211 RX 路徑中讀取常規標頭位址，包括接受框架、重複偵測、位址複製和 MLO 位址轉換路徑。
    在傳回 S1G 來源位址指標之前，也要使 ieee80211_get_bssid（） 長度安全。
    (CVE-2026-68470)

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

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

  - netfilter： nft_compat：ebtables 模擬必須拒絕非橋接器目標 xtables 目標會傳回 netfilter 判定：NF_ACCEPT、NF_DROP等。ebtables 目標傳回不相容的判定：EBT_ACCEPT、EBT_DROP、... 我們不能允許後援到NFPROTO_UNSPEC。ebtables 不允許這樣做，因為 11ff7288beb2 （netfilter： ebtables：拒絕非橋接器目標），但該提交遺漏了nft_compat層。
    (CVE-2026-72416)

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

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

  - ext4：在 EXT4_IOC_MOVE_EXT 中儘早驗證捐贈者檔案超級區塊 如果捐贈者檔案不屬於與原始檔案相同的超級區塊，則提前拒絕EXT4_IOC_MOVE_EXT ioctl。目前，此驗證由 mext_check_validity（） 在 ext4_move_extents（） 內執行，但只有在 lock_two_nondirectories（） 已經取得 inode 鎖定之後。當捐贈者 fd 引用不同檔案系統上的檔案 （例如 overlayfs） 時，此延遲驗證會建立循環鎖定相依性： CPU0 （overlayfs write） CPU1 （ext4 ioctl） ---- ---- inode_lock（ovl_inode） mnt_want_write_file（filp） sb_start_write（ext4_sb） [sb_writers] backing_file_write_iter（） vfs_iter_write（real_file） file_start_write（real_file） sb_start_write（ext4_sb） [被凍結阻止] lock_two_nondirectories（） inode_lock（ovl_inode） [blocked] 使用sb_writers寫端持有並發凍結操作，這會形成一個鎖死循環：CPU0 等待凍結完成，freeze 等待 CPU1 的 sb_writers 讀取器退出，CPU1 等待 CPU0 的 inode 鎖定。由於 EXT4_IOC_MOVE_EXT 會在兩個檔案之間交換實體範圍，因此基本上需要兩個檔案都位於相同的 ext4 檔案系統上。在任何鎖定取得之前移動超級區塊檢查在語義上都是正確的，並且透過確保在採用 sb_writers 或 inode 鎖定之前拒絕跨檔案系統捐贈者 fd，從而消除循環依賴關係。（CVE-2026-74307）

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

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

  - ntfs3：驗證 indx_insert_into_buffer indx_insert_into_buffer（） 中的分割點偏移 計算 used = used1 - to_copy - sp_size;memmove（de_t， Add2Ptr（sp， sp_size），已使用 - le32_to_cpu（hdr1->de_off））;其中 sp 和 sp_size 來自 hdr_find_split（）。hdr_find_split（） 會依 le16_to_cpu（e->size） 遍歷項目，而不驗證每個步驟是否保持在 hdr->used 內，或 size 欄位至少為 sizeof（struct NTFS_DE）。index_hdr_check（） 是載入閘道守，僅驗證標頭層級欄位 （used、total、de_off），不會遍歷每個項目大小。因此，一個特製的 NTFS 映像，其葉INDEX_HDR報告 used == total，但包含一個大小 = 0xFFF0 的內部NTFS_DE，因此會通過驗證，透過 ntfs_create（） -> indx_insert_entry（） 路徑下降到 indx_insert_into_buffer（），並使 hdr_find_split（） 傳回一個 sp，其sp_size （0xFFF0） 大大超過緩衝區中的剩餘位元組。
    u32 減法反向溢位，memmove 計數變成接近 4 GiB 的值，從而產生越界核心寫入，從而損毀相鄰的分配並使核心發生錯誤。在 7.0.0-rc7 上使用 UML + KASAN 透過精心製作的映像和掛載目錄內的單一「觸摸」進行複製;當機網站解析為 memmove 處的 fs/ntfs3/index.c。觸發程序只需要在本機掛載攻擊者提供的檔案系統映像 （USB、回送或卸除式媒體自動掛載）。每當所選 sp 加上其宣告的大小已超出 hdr1->used 時，就拒絕分割。這是最低限度的修復;它會保留現有的 hdr_find_split（） 合約，並依賴與先前存在的錯誤傳回相同的 out： cleanup 路徑。在提交 b8c44949044e （fs/ntfs3： 透過收緊 hdr_find_e（） 來修正 indx_insert_into_buffer） 中的 OOB 讀取，但該修正並未涵蓋此處解決的分割點大小欄位路徑： sp 是由 hdr_find_split（） 傳回，而不是 hdr_find_e（） 傳回，indx_insert_into_buffer 而下溢是由 sp->size 驅動，而不是 hdr->used 超過 hdr->total。
    (CVE-2026-72191)

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

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

  - ipv4： fib：不要在 fib_leaf_notify（） 中轉儲垂死的fib_info。syzbot 在 nsim_fib4_prepare_event（） 中報告釋放後使用。[0] 問題是，以下函數在RCU下轉儲fib_info時調用fib_info_hold（） / refcount_inc（），這是不安全的。* mlxsw_sp_router_fib4_event（） * rocker_router_fib_event（） * 必須使用 nsim_fib4_prepare_event（） refcount_inc_not_zero（），但為時已晚。讓我們保證 fib_leaf_notify（） 中fib_info的生命週期。請注意，IPv6 不需要對應的變更，因為 fib6_table_dump（） 保留 fib6_table.tb6_lock。[0]：refcount_t：0 上加法;釋放後使用。警告： lib/refcount.c：25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c：25， CPU#0： kworker/u8：15/3420 連結的模組： CPU： 0 UID： 0 PID： 3420 通訊： kworker/u8：15 未受污染的 syzkaller #0 PREEMPT_{RT，（full）} 硬體名稱：Google Google Compute Engine/Google Compute Engine， BIOS Google 04/18/2026 工作佇列：netns cleanup_net RIP：0010：refcount_warn_saturate+0x9f/0x110 lib/refcount.c：25 程式碼： EB 66 85 DB 74 3e 83 FB 01 75 4C E8 1B F1 22 FD 48 8D 3D 84 CB F1 0A 67 48 0F B9 3A EB 4A E8 08 F1 22 FD 48 8D 3D 81 CB F1 0A 48 0F <67> B9 3A EB 37 E8 F5 F0 22 FD 48 8D 3D 7E CB F1 0A 67 48 0f RSP： 0018：ffffc9000f2c7270 EFLAGS：00010293 RAX：ffffffff84a18858 RBX：0000000000000002 RCX：
    ffff888032ff9ec0 RDX：00000000000000000000 RSI：000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ffff888032ff9ec0 R09： 0000000000000005 ： 0000000000000100 R10R11： 0000000000000004 R12：R08
    ffff8880570cc000 R13： dffffc0000000000 R14： ffff88802b40563c R15： ffff8880570cc000 FS：
    00000000000000000（0000） GS：ffff888126173000（0000） knlGS：000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000080050033 CR2：00007fb1f4d5d000 CR3：000000006072a000 CR4：00000000003526f0 呼叫追蹤： <TASK>
    __refcount_add include/linux/refcount.h：-1 [內聯] __refcount_inc include/linux/refcount.h：366 [內聯] refcount_inc include/linux/refcount.h：383 [內聯] fib_info_hold include/net/ip_fib.h：629 [內聯] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c：930 [內聯] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c：1000 [內聯] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c：1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c：25 call_fib_entry_notifier net/ipv4/fib_trie.c：90 [內嵌] fib_leaf_notify net/ipv4/fib_trie.c：2176 [內嵌] fib_table_notify net/ipv4/fib_trie.c：2194 [內嵌] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c：2217 fib_net_dump net/core/fib_notifier.c：70 [內嵌] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c：108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c：1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c：1604 [內嵌] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c：1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c：475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c：558 ops_pre_exit_list net/core/net_namespace.c：161 [內嵌] ops_undo_list+0x187/0x940 net/core/net_namespace.c：234 cleanup_net+0x56e/0x800 net/core/net_namespace.c：702 process_one_work kernel/workqueue.c：3314 [內嵌] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c：3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c：3478 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> （CVE-2026-74289）

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

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

  - ntfs：跳過回寫中的範圍 MFT 記錄以防止鎖死 此修補程式修正了自提交 6994acf33bae 以來發生的 xfstests generic/113 觸發的 extent_lock 和範圍 mrec_lock之間的 ABBA 鎖死 （ntfs：查詢基底 inode 以取得範圍記錄時，請使用基底mft_no）。路徑 A （inode 回寫）： VFS 回寫 -> ntfs_write_inode（） -> __ntfs_write_inode（） -> mutex_lock（&ni->extent_lock） -> mutex_lock（&tni->mrec_lock） 路徑 B （MFT 對開本回寫）： 已變更對開本的 $MFT VFS 回寫 -> ntfs_mft_writepages（） -> ntfs_write_mft_block（） -> ntfs_may_write_mft_record（） -> 保留先前反覆運算mrec_lock的一個範圍 -> 嘗試取得另一個基本 inode extent_lock 藉由mrec_lock extent_lock從MFT 對開本回寫路徑時，已消除 ABBA 鎖定順序： 路徑 A：__ntfs_write_inode（）：extent_lock -> mrec_lock 路徑 B （已移除）：
    ntfs_write_mft_block（）：mrec_lock -> extent_lock 範圍記錄的路徑 B 一律是多餘的，因為： 1。
    mark_mft_record_dirty（ext_ni） 不會弄髒 MFT 作品集。它僅設定 NInoDirty（ext_ni），並透過 __mark_inode_dirty（I_DIRTY_DATASYNC） 將基本 VFS inode 標記為髒，這會觸發路徑 A。因此，一般範圍修改絕不會造成 MFT 對開本已變更且路徑 B 未排程的情況。2.
    MFT 對開本只能透過 ntfs_mft_record_alloc（） 內的 ntfs_mft_mark_dirty（） 弄髒。但 attrib.c 中所有已識別的呼叫者 （ntfs_attr_add、ntfs_attr_record_move_away、ntfs_attr_make_non_resident、ntfs_attr_record_resize） 都會使用 mark_mft_record_dirty（） 跟進，這會觸發路徑 A 寫入完整記錄。3. ntfs_evict_big_inode（） 在釋放範圍 inode 之前呼叫 ntfs_commit_inode（），確保在基底 inode 離開 icache 之前，透過路徑 A 清除所有已變更的範圍。
    (CVE-2026-72203)

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

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

  - kernfs：在 LSM init 勾點之前將 kn 連結到其父項 提交 12e9e3cd03b5 （simpe_xattr：使用 per-sb 快取） 後，kernfs_xattr_set（） 和 kernfs_xattr_get（） 會在任何其他檢查之前透過 kernfs_root（kn） 計算快取。kernfs_root（kn） 首先遍歷 kn->__parent，然後回退到 kn->dir.root，這兩者在新kmem_cache_zalloc（） 的 kn 上都是 NULL。 之後在 kernfs_new_node（） 中設定了 kn->__parent
    __kernfs_new_node（），並且稍後由 kernfs_create_dir_ns（） / kernfs_create_empty_dir（） 設定 kn->dir.root。在初始化任一欄位之前，會從 __kernfs_new_node（） 內部叫用 LSM kernfs_init_security勾點。selinux_kernfs_init_security（） 以 kernfs_xattr_set（kn， XATTR_NAME_SELINUX， ...） 結尾。kernfs_root（kn） 接著傳回 NULL，&（（struct kernfs_root *）NULL）->xa_cache 的計算結果為 offsetof（struct kernfs_root， xa_cache），這會發生錯誤： 錯誤：核心 NULL 指標解除參照，位址：000000000000000e0 RIP：0010：simple_xattr_set+0x27/0x8b0 呼叫追蹤：kernfs_xattr_set+0x63/0xb0 selinux_kernfs_init_security+0x13b/0x270 security_kernfs_init_security+0x36/0xc0
    __kernfs_new_node+0x182/0x290 kernfs_new_node+0x80/0xc0 kernfs_create_dir_ns+0x2b/0xa0 cgroup_create+0x116/0x380 cgroup_mkdir+0x7c/0x1a0 在啟用 SELinux 的發行版上以 PID 1 （systemd） 確定性方式重現。/sys/fs/cgroup 下具有標記父項的第一個 cgroup mkdir 會使核心發生錯誤。LSM 鉤子的合約是 kn_dir 參數是新 kn 的父項，因此 kn->__parent 在鉤子運行時應該已經指向kn_dir。將 kn->__parent 的 kernfs_get（parent） 和 rcu_assign_pointer 從 kernfs_new_node（） 移動到安全勾點之前的 __kernfs_new_node（），並在err_out4路徑上展開父引用。然後，kernfs_root（kn） 在勾點期間獲取其父分支並傳回 parent->dir.root，這是正確的根。這也關閉了 kernfs_xattr_get（） 中相同形狀的潛在錯誤（目前僅通過 kernfs_iattrs_noalloc（） 在新的 kn 上返回 NULL 來隱藏該錯誤）。
    (CVE-2026-74342)

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

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

  - mlxsw：修正 mlxsw_sp_port_lag_join（） 中的參照計數洩漏 當 mlxsw_sp_port_lag_index_get（） 失敗時，mlxsw_sp_port_lag_join（） 會傳回錯誤，而不釋放先前 mlxsw_sp_lag_get（） 所取得的滯後參照。函式中的所有其他錯誤路徑都會跳到以 mlxsw_sp_lag_put（） 結尾的清理標籤，因此這是單一遺漏的版本。透過將裸露的「返回錯誤」替換為現有錯誤清理標籤的 goto來修復洩漏，這將安全地刪除參照。（CVE-2026-72308）

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

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

  - ALSA： seq： oss：修正處理具有內嵌 SysEx 資料的事件時的 UAF OSS 音序器會將輸入的 MIDI 位元組處理成音序器事件，以便稍後分派 （在從 snd_seq_oss_process_event（） 呼叫的 snd_seq_oss_midi_putc（） 中）。當它是 SysEx 資料時，事件記錄會包含原始 SysEx 位元組的 data.ext.ptr 指標，之後會在分派時將參照的資料複製到集區中。問題在於，如果排序器連接埠在分派之前同時關閉，則 OSS 定序器核心也會釋放資源（在 snd_seq_oss_midi_check_exit_port（） 中），而擱置事件可能會保留過時的指標，最終導致稍後的分派時出現 UAF。幸運的是，OSS MIDI 裝置存取已經有一個引用計數機制 （snd_use_lock_t），為了解決上述問題，我們只需要延長引用計數，直到事件被分派。此修補程式擴充 snd_seq_oss_process_event（） 以傳回 refcount 物件，而 refcount 物件又會在呼叫端使用指定事件呼叫排序器分派器之後釋放。根據原始報告，KASAN 報告如下： snd_seq_event_dup+0x40c/0x470 中的 KASAN slab-use-after-free RIP： 0033：0x7f2cb66a6340 讀取大小 6 呼叫追蹤：dump_stack_lvl+0x73/0xb0 （？：？） print_report+0xd1/0x650 （？：？） srso_alias_return_thunk+0x5/0xfbef5 （？：？） __virt_addr_valid+0x1a7/0x340 （？：？） kasan_complete_mode_report_info+0x64/0x200 （？：？） kasan_report+0xf7/0x130 （？：?)snd_seq_event_dup+0x40c/0x470 （？：？） kasan_check_range+0x10c/0x1c0 （？：？） __asan_memcpy+0x27/0x70 （？：？） snd_seq_event_dup+0x9/0x470 （？：？） snd_seq_client_enqueue_event+0x139/0x240 （？：？）
    _raw_spin_unlock_irqrestore+0x4b/0x60 （？：？） snd_seq_kernel_client_enqueue+0x102/0x120 （？：？） snd_seq_oss_write+0x416/0x4e0 （？：？） apparmor_file_permission+0x20/0x30 （？：？） odev_write+0x3b/0x60 （？：？） vfs_write+0x1ce/0x850 （？：？） lock_release+0xc8/0x2a0 （？：？） __kasan_check_write+0x18/0x20 （？：？）
    __mutex_unlock_slowpath+0x129/0x510 （？：？） ksys_write+0xe1/0x180 （？：？） mutex_unlock+0x16/0x20 （？：？） odev_ioctl+0x65/0xc0 （？：？） __x64_sys_write+0x46/0x60 （？：？） x64_sys_call+0x7d/0x20d0 （？：？） do_syscall_64+0xc1/0x360 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f （？：？）（CVE-2026-74388）

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

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

  - RDMA/bnxt_re：如果 ioremap 失敗，則適當復原bnxt_qplib_alloc_dpi即使 ioremap 失敗也會傳回成功。當 ioremap 失敗並傳回 -ENOMEM 狀態時，新增適當的復原。（CVE-2026-72496）

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

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

  - perf/x86/amd/brs：修正核心位址洩漏 僅限使用者的分支堆疊可以包含源自核心的分支。因此，即使要求PERF_SAMPLE_BRANCH_USER，核心位址也會公開給使用者空間。在支援 X86_FEATURE_BRS 的 AMD 處理器上 （僅限 Zen 3），perf 仍然可以報告分支來源位址位於核心中的項目，例如 SYSRET/中斷傳回。例如 $ perf 記錄
    -j any，u -c 4000 -e branch-brs -o - -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ...0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//- 0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//- 0xffffffff810001c4/0x72e2d94ffa1b/-/0//- ... BRS 不提供硬體分支篩選，因此權限層級篩選完全在軟體中執行。但是，amd_brs_match_plm（） 僅根據要求的權限等級驗證分支至位址。對於從核心到使用者空間的分支，分支來源位址未勾選並遭到洩漏。擴充軟體篩選器以同時驗證分支來源位址，以便在要求PERF_SAMPLE_BRANCH_USER時捨棄核心中分支來源位址的任何分支記錄。（CVE-2026-72237）

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

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

  - ALSA： seq：修正 bounce_error_event（） 中的核心堆積位址洩漏 上面的註解 bounce_error_event（） 記錄了使用者用戶端應接收的SNDRV_SEQ_EVENT_BOUNCE，並將原始事件內嵌為可變長度資料，而核心用戶端應接收帶有引號核心指標的SNDRV_SEQ_EVENT_KERNEL_ERROR。不過，實作會無條件地使用SNDRV_SEQ_EVENT_KERNEL_ERROR，並將 data.quote.event 設定為所有用戶端的原始結構snd_seq_event指標。透過 snd_seq_read（） 將退信錯誤事件傳送至USER_CLIENT時，data.quote.event 中的核心堆積位址會透過固定長度分支中的 copy_to_user（） 公開給使用者空間。這是與提交 705dd6dcbc0e （ALSA： seq： 讀取時清除變數事件指標） 所解決的洩漏路徑不同，後者會清理 snd_seq_read（） 可變長度分支中的 data.ext.ptr。bounce_error_event（） 洩漏使用固定長度的事件，這些事件採用未發生清理的 else 分支。依用戶端類型區分退信事件。若要USER_CLIENT，請傳送 SNDRV_SEQ_EVENT_BOUNCE 並帶有 SNDRV_SEQ_EVENT_LENGTH_VARIABLE 和 data.ext 指向原始事件。snd_seq_event_dup（） 中的可變長度路徑將事件資料複製到鏈結的儲存格中，而 snd_seq_expand_var_event（） 僅將內容複製到使用者空間，而不是指標。KERNEL_CLIENT，請保留現有的SNDRV_SEQ_EVENT_KERNEL_ERROR行為並加上引號的指標。（CVE-2026-74278）

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

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

  - wifi： mt76： mt7925：驗證 testmode 查詢中的 skb 長度 在 mt7925_tm_query（） 中，來自 mt76_mcu_send_and_get_msg（） 的回應 skb 會在 memcpy 中使用，而不驗證其長度：memcpy（evt_resp， skb->data + 8， MT7925_EVT_RSP_LEN）;其中 MT7925_EVT_RSP_LEN 是 512。如果韌體傳回短於 520 位元組 （8 + 512） 的回應，則讀取範圍會超出 skb 資料緩衝區。然後，過度讀取的資料會透過 mt7925_testmode_dump（） 中的 nla_put（） 傳回使用者空間。在 memcpy 之前新增長度檢查，以確保 skb 包含足夠的資料。（CVE-2026-74324）

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

ID	名稱	嚴重性
335562	Linux Distros 未修補弱點：CVE-2026-72096	medium
335561	Linux Distros 未修補弱點：CVE-2026-72334	high
335560	Linux Distros 未修補弱點：CVE-2026-72035	high
335559	Linux Distros 未修補弱點：CVE-2026-74350	critical
335558	Linux Distros 未修補弱點：CVE-2026-72009	high
335557	Linux Distros 未修補弱點：CVE-2026-72485	high
335556	Linux Distros 未修補弱點：CVE-2026-72170	high
335555	Linux Distros 未修補弱點：CVE-2026-68467	high
335554	Linux Distros 未修補弱點：CVE-2026-72172	high
335553	Linux Distros 未修補弱點：CVE-2026-72469	high
335552	Linux Distros 未修補弱點：CVE-2026-72380	high
335551	Linux Distros 未修補弱點：CVE-2026-72499	high
335550	Linux Distros 未修補弱點：CVE-2026-72254	high
335549	Linux Distros 未修補弱點：CVE-2026-74248	medium
335548	Linux Distros 未修補弱點：CVE-2026-72466	critical
335547	Linux Distros 未修補弱點：CVE-2026-68457	critical
335546	Linux Distros 未修補弱點：CVE-2026-72375	high
335545	Linux Distros 未修補弱點：CVE-2026-74417	high
335544	Linux Distros 未修補弱點：CVE-2026-74397	high
335543	Linux Distros 未修補弱點：CVE-2026-72473	critical
335542	Linux Distros 未修補弱點：CVE-2026-72402	medium
335541	Linux Distros 未修補弱點：CVE-2026-74317	high
335540	Linux Distros 未修補弱點：CVE-2026-72434	high
335539	Linux Distros 未修補弱點：CVE-2026-74438	high
335538	Linux Distros 未修補弱點：CVE-2026-72066	high
335537	Linux Distros 未修補弱點：CVE-2026-72369	high
335536	Linux Distros 未修補弱點：CVE-2026-72210	critical
335535	Linux Distros 未修補弱點：CVE-2026-72405	high
335534	Linux Distros 未修補弱點：CVE-2026-72012	high
335533	Linux Distros 未修補弱點：CVE-2026-72147	medium
335532	Linux Distros 未修補弱點：CVE-2026-74272	high
335531	Linux Distros 未修補弱點：CVE-2026-72366	critical
335530	Linux Distros 未修補弱點：CVE-2026-72347	high
335529	Linux Distros 未修補弱點：CVE-2026-72398	critical
335528	Linux Distros 未修補弱點：CVE-2026-19720	critical
335527	Linux Distros 未修補弱點：CVE-2026-74344	high
335526	Linux Distros 未修補弱點：CVE-2026-72365	high
335525	Linux Distros 未修補弱點：CVE-2026-68470	high
335524	Linux Distros 未修補弱點：CVE-2026-72416	high
335523	Linux Distros 未修補弱點：CVE-2026-74307	high
335522	Linux Distros 未修補弱點：CVE-2026-72191	critical
335521	Linux Distros 未修補弱點：CVE-2026-74289	high
335520	Linux Distros 未修補弱點：CVE-2026-72203	high
335519	Linux Distros 未修補弱點：CVE-2026-74342	medium
335518	Linux Distros 未修補弱點：CVE-2026-72308	high
335517	Linux Distros 未修補弱點：CVE-2026-74388	high
335516	Linux Distros 未修補弱點：CVE-2026-72496	critical
335515	Linux Distros 未修補弱點：CVE-2026-72237	medium
335514	Linux Distros 未修補弱點：CVE-2026-74278	medium
335513	Linux Distros 未修補弱點：CVE-2026-74324	high

偵測

Nessus 的 Misc. 系列

medium

high

high

critical

high

high

high

high

high

high

high

high

high

medium

critical

critical

high

high

high

critical

medium

high

high

high

high

high

critical

high

high

medium

high

critical

high

critical

critical

high

high

high

high

high

critical

high

high

medium

high

high

critical

medium

medium

high