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

  - Bluetooth： btrtl：在附加韌體版本之前，驗證韌體修補程式邊界 rtlbt_parse_firmware（） 副本 patch_length - 4 位元組。格式錯誤的韌體修補程式短於版本欄位，可能會造成此減法反向溢位，並在藍牙設定期間將複本變成過大的讀取和寫入。現有的 patch_offset + patch_length檢查也可以包裝在 32 位元架構上。在配置或複製修補程式之前，請先驗證修補程式長度和範圍，而不會出現算術溢位。（CVE-2026-68479）

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

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

  - batman-adv：確保 TX 上的乙太網路標頭最少，如提交 8bd67ebb50c0 中所述 （net： bridge： xmit：
    確保我們至少有 eth 標頭 len 位元組），具有 eBPF TC 掛鉤存取權限的本機使用者可以附加 TC 過濾器，該過濾器會截斷資料包並重新導向到 batadv 介面。但程式碼假設至少有 ETH_HLEN 個位元組可用，因此可能會在可用的緩衝區之外讀取。
    因此，batadv_interface_tx（） 必須始終檢查自己是否有足夠的資料可用於乙太網路標頭，並且不依賴min_header_len。（CVE-2026-72232）

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

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

  - tcp： ipv6：clamp 預設通告 MSS 以避免GSO_BY_FRAGS （0xFFFF） 當 MTU 較大時，ip6_default_advmss（） 可以傳回 IPV6_MAXPLEN （65535）。TCP 將其解釋為mss_clamp，從而允許 MSS 到達 65535。然而，0xFFFF也被用作核心中的魔術值GSO_BY_FRAGS。如果將 gso_size=0xFFFF 的 TCP 封包傳遞給 skb_segment（），則會錯誤地將其視為GSO_BY_FRAGS，導致 NULL 指標解除參照，因為本機 TCP 封包不使用 frag_list。當 MTU 很大時，透過從 ip6_default_advmss（） 傳回 min（IPV6_MAXPLEN， GSO_BY_FRAGS - 1） （65534） 來解決此問題。同時更新 ip6_default_advmss（） 中的過時註解，該註解建議傳回 IPV6_MAXPLEN 以表示任何 MSS。CVE-2026-72502

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

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

  - crypto： algif_skcipher - 在沒有 ctx->state 的樹狀結構上強制同步處理 skcipher_recvmsg（） 中的 AIO/async 路徑會將通訊端範圍的 ctx->iv 直接傳遞至 skcipher 要求。在 io_submit（） 之後，通訊端鎖定會遭到刪除，且要求會以非同步方式處理，因此並行的 sendmsg（ALG_SET_IV） 可以覆寫 ctx->iv，並使正在進行的請求在攻擊者控制的 IV 下執行。針對 CTR/資料流模式，這是 IV/金鑰資料流重複使用，可讓無特權的使用者復原並行作業的純文字。將 ctx->iv 快照到非同步路徑的每個要求儲存中是不夠的。對於 statesize == 0 的密碼 （包括 cbc 和 ctr），MSG_MORE區塊間 IV 鏈結僅由就地 req->iv 回寫進行，快照會重新導向到每個要求記憶體中，af_alg_free_resources（） 在完成時釋放，以無訊息方式產生錯誤的輸出。從完成回呼寫回 IV 也是不可能的：這需要 lock_sock（），但回呼可以在 softirq/atomic 上下文中運行，因此它不能休眠。改為使作業同步，這會移除 IV 爭用和任何回寫爭用。這相當於上游解析，commit fcc77d33a34c （net：移除通訊端上對 AIO 的支援），它完全移除了 net/ 上的 AIO 通訊端路徑，因此會為此檔案產生相同的結束狀態。此修補程式故意偏離了該提交：它沒有刪除樹狀結構範圍內的 AIO 通訊端支援（這對穩定版來說太具有侵入性），而是僅刪除 crypto/algif_skcipher.c 中的 AIO 分支。io_submit（） 現在會同步完成;AF_ALG非同步在實踐中很少使用。skcipher_recvmsg（） 中的 -EIOCBQUEUED 簽入現在已失效，但無害，並且單獨保留以保持最小的修正。在 6.6.y 上測試：變更後攻擊者 IV 注入從 2296/200000 降至 0/200000;MSG_MORE區塊 CTR 輸出位元與單次相同。（CVE-2026-74578）

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

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

  - net/9p：修正 trans_rdma.c 中 rdma->state 上的爭用情形 rdma->state 欄位在修改時不會在 recv_done（） 和 p9_cm_event_handler（） 中保留 req_lock，而 rdma_request（） 則存取 req_lock 微調鎖定下的相同欄位。這種不一致的鎖定會造成爭用情形： - 在 softirq 完成上下文中執行的 recv_done（） 設定 rdma->state = P9_RDMA_FLUSHING 而不獲取req_lock - p9_cm_event_handler（） 在多個點（ADDR_RESOLVED、ROUTE_RESOLVED、ESTABLISHED、CLOSED）修改 rdma->state 而不req_lock - rdma_request（） 使用 spin_lock_irqsave（&rdma->req_lock， flags） 來保護 rdma->state 的讀取-修改-寫入 爭用可能會導致狀態轉換遺失： 當 rdma_request（） 同時檢查或修改鎖定下的狀態時，recv_done（） 或 CM 事件處理常式可能會將狀態設定為 FLUSHING/CLOSED，導致 FLUSHING 轉換被 CCLOSING 無訊息地覆寫。這會損毀連線狀態機器，並可能在拆卸期間導致 RDMA 要求物件發生釋放後使用問題。透過對 recv_done（） 和 p9_cm_event_handler（） 中的所有 rdma->state 修改新增 req_lock 保護來修正，以符合 rdma_request（） 中已使用的模式。在 CM 事件處理常式中使用 spin_lock_irqsave/spin_unlock_irqrestore，因為它可以與在 softirq 上下文中執行的 recv_done（） 爭用。使用核心模組進行測試，該核心模組在 rdma->state 上爭用兩個執行緒（模擬 rdma_request 和 recv_done/CM 處理常式），並具有適當的鎖定： 5.5M+ FLUSHING 寫入超過 27M 次迭代，其中 0 次轉換遺失。（CVE-2026-72491）

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

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

  - fs/ntfs3：在分析通道中綁定copy_lcns dp->page_lcns[] 索引 在 log_replay（） 的分析通道中，在 find_dp（） 傳回 （target_attr， target_vcn） 元組的有效DIR_PAGE_ENTRY之後，copy_lcns 區塊會遍歷 lrh->lcns_follow 進一步的條目： t16 = le16_to_cpu（lrh->lcns_follow）; 對於 （i = 0; i < t16; i++） {size_t j = （size_t）（le64_to_cpu（lrh->target_vcn） - le64_to_cpu（dp->vcn））; dp->page_lcns[j + i] = lrh->page_lcns[i];} find_dp（） 只會驗證target_vcn是否屬於 [dp->vcn， dp->vcn + dp->lcns_follow），亦即涵蓋第一個叢集。進一步條目的演練不受 dp->lcns_follow 的限制。對於格式錯誤的 LRH，其中 target_vcn = dp->vcn + dp->lcns_follow - 1 且 lrh->lcns_follow > 1，則 i > 0 寫入會溢位 dp 的配置 page_lcns[] 陣列。新增缺少的 j + lrh->lcns_follow <= dp->lcns_follow防護。在主線上的 UML+KASAN 8d90b09e6741 下，從掛載路徑上的 log_replay+0x68d4 複製為大小為 8 的 slab-out-of-bounds 寫入。這與 Pavitra Jha 的 2026-05-02 修補程式 （fs/ntfs3：驗證log_replay轉換 <20260502154252.164586-1-jhapavitra98@gmail.com>中的lcns_follow） 不同，後者解決了單獨的 version-0 dirty-page-table 轉換路徑的 memmove（&dp->vcn， ...） 呼叫。這兩個修復是互補的;兩者都應該著陸。
    [almaz.alexandrovich@paragon-software.com：對更改進行了 clang 格式化，修正了衝突]（CVE-2026-72196）

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

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

  - KVM：將 kvm_io_bus_get_dev（） 鎖定責任轉移給調用方 kvm_io_bus_get_dev（） 會傳回僅與位址相符的裝置，而沒有其他比對。如果相符的裝置不是預期的類型，這可能會導致存留期問題，因為當呼叫端可以內省物件時，物件可能已經消失 （srcu 鎖定已卸除） 。鑑於此協助程式只有單一使用者，最簡單的選項是將鎖定責任移至呼叫端，呼叫端可以視需要保留 srcu 鎖定。請注意，這與其他 kvm_io_bus*（） 協助程式一致，後者已經要求呼叫端持有 srcu 鎖定。（CVE-2026-72282）

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

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

  - ASoC： SOF： ipc4-control： 驗證通知有效負載大小 在控制更新處理中讀取位元組/通道資料之前，先驗證MODULE_NOTIFICATION有效負載長度。（CVE-2026-72303）

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

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

  - SUNRPC：在寫入 xdr_buf_to_bvec（） 之前進行邊界檢查 xdr_buf_to_bvec（） 存儲，在測試該插槽是否在範圍內之前將bio_vec寫入調用方的陣列，並且 head 分支在完全不檢查的情況下執行存儲。當調用方的預算剛好用完時，下一個存放區會在陣列結尾之後放置一個元素。溢位標籤傳回計數 - 1，這會遮罩盈餘存放區，但無法復原。
    rq_bvec，nfsd_vfs_write（） 傳遞的陣列被分配給恰好 rq_maxpages 個條目，沒有鬆弛。
    OOB 存放區可以登陸相鄰的 slab 記憶體;寫入的bv_len和bv_offset欄位衍生自用戶端提供的RPC承載大小。將範圍內檢查移到商店前面的頭部、頁面循環和尾部分支中。在每個序列的頂端進行檢查時，只有在成功儲存後才會增加計數，因此溢位標籤可以直接傳回計數。（CVE-2026-72217）

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

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

  - ocfs2：避免將範圍移至佔用的叢集 對於非自動OCFS2_IOC_MOVE_EXT作業，使用者空間會提供實體me_goal。ocfs2_move_extent（） 會從該目標初始化new_phys_cpos，並預期 ocfs2_probe_alloc_group（） 會以目標區塊群組中的自由執行取代它。如果掃描到達群組結尾而未找到自由執行，則探測目前會保持 *phys_cpos 不變。因此，最後一位被佔用的目標可以在探測中倖存下來並傳遞給 __ocfs2_move_extent（），後者會在點陣圖更新之前將檔案資料複製到仍由另一個 inode 擁有的叢集中。當探測器確實找到自由運行時，它還會從結束位中減去move_len。以 i 結束的 N 位元執行的開始時間為 i - N + 1，因此目前的計算可以在自由執行之前立即報告位元。
    掃描前清除 *phys_cpos 並使用正確的自由執行開始。呼叫端已將零結果視為 -ENOSPC，因此失敗的探測不會再繼續使用已佔用的呼叫端控制目標。（CVE-2026-72164）

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

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

  - crypto：cavium/cpt - 使用錯誤的迴圈索引修正 DMA 清除 當取消映射 DMA 緩衝區時，sg_cleanup錯誤路徑使用 list[i] 而不是 list[j]，洩漏成功映射的項目並重複取消映射失敗的項目。（CVE-2026-74279）

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

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

  - drm/amdkfd：修正 kfd_criu_resume_svm 中的 list_del 損毀 kfd_criu_resume_svm（） 的清理尾部會遍歷每個結構criu_svm_metadata svms->criu_svm_metadata_list 和 kfree（），而不會將其從清單中移除。
    列表標題指向釋放的 kmalloc-96 對象。同一進程的第二個AMDKFD_IOC_CRIU_OP重新進入：list_empty（） 讀取懸空的 ->next （釋放後使用），迴圈遍歷釋放的條目，並且每個條目再次被 kfree（） 處理（雙重釋放）。無權限的轉譯群組使用者可透過 /dev/kfd 存取此項目，且不需要任何功能。在 kfree（） 之前新增 list_del（），以便正確清空清單。
    list_for_each_entry_safe（） 迭代器已經快取了下一個指標，因此在遍歷期間取消連結是安全的。（從提交 6322d278a298e2c1430b9d2697743d3a04b788b1 中挑選）（CVE-2026-72449）

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

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

  - iomap：發布不可部分完成 dio 大小不相符的頁面 如果 bio_iov_iter_get_pages（） 或反彈協助程式成功但建立了簡短的個人簡介，則REQ_ATOMIC大小檢查會在提交前拒絕它。舊的錯誤路徑僅刪除了生物參考，使任何已附加到生物的頁面未發布。在此錯誤路徑上落入out_put_bio之前，請釋放或取消頁面。這個錯誤是由 sashiko 報告的：
    https://sashiko.dev/#/patchset/20260608073134.95964-1-changfengnan%40bytedance.com (CVE-2026-72370)

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

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

  - gpu：host1x：修正 iommu_map_sgtable（） 傳回值檢查 提交 iommu：傳回 iommu_map_sg[_atomic]（） 變更 iommu_map_sgtable（） 的完整錯誤代碼，以在錯誤情況下傳回 ssize_t 值和負值，而不是size_t和零。pin_job（） 也錯誤地賦值給 'int'，這可能會導致溢位變成負值。更新 pin_job（） 以正確檢查來自 iommu_map_sgtable 的錯誤。（CVE-2026-74380）

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

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

  - fbdev： uvesafb：修正 uvesafb_probe（） 中潛在的記憶體洩漏 由於 goto 標籤不正確，在某些錯誤路徑中，uvesafb_vbe_init（） 中配置給 modedb 和 modelist 的記憶體不會釋放。透過更新 goto 標籤來修正此問題。（CVE-2026-72269）

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

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

  - dmaengine： tegra：修正突發大小計算 目前，Tegra GPC DMA 硬體要求傳輸長度是為通道設定的最大突發大小的倍數。當用戶端要求傳輸時，長度無法被設定的最大突發大小整除，DMA 會停擺，並在末尾出現部分突發。透過將突發大小減少到平均分配傳輸長度的最大 2 的冪值來解決此問題。例如，最大突發次數為 16 位元組的 40 位元組傳輸現在將使用 8 位元組突發 （40 / 8 = 5 次完整突發），而不是造成懸置。在任意長度的 TX DMA 傳輸停滯的 UART 驅動程式中 PL011 觀察到此問題。（CVE-2026-72149）

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

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

  - 暫存： nvec：修正 nvec_rx_completed（） 中的釋放後使用 在 nvec_rx_completed（） 中，當偵測到不完整的 RX 傳輸時，會呼叫 nvec_msg_free（） 透過清除其「已使用」的不可部分完成標誌，將訊息傳回集區。在此之後，程式碼會立即存取 nvec->rx->data[0] 以檢查訊息類型。
    由於 nvec_msg_free（） 透過 atomic_set（） 將集區插槽標記為可用，因此對 nvec_msg_alloc（） 的任何並發或後續呼叫都可能宣告相同的插槽並覆寫其 data[] 陣列。因此，在釋放訊息後讀取 nvec->rx->data[0] 是釋放後使用。透過在呼叫 nvec_msg_free（） 之前儲存訊息類型位元組，然後使用儲存的值進行電池怪癖檢查來解決此問題。（CVE-2026-72489）

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

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

  - rxrpc： 修正資料傳輸前回覆封包的接收 修正 rxrpc_receiving_reply（） 以在 rxrpc 有機會在用戶端呼叫上傳送任何要求 DATA 封包之前，處理明顯回覆 DATA 封包的接收，方法是檢查呼叫是否已透過傳送第一個封包而暴露。
    如果沒有這個，rxrpc_rotate_tx_window（） 可能會失敗。同時修正 rxrpc_rotate_tx_window（） 以透過變更 do...while 迴圈進入 while 迴圈，以防在傳輸最後一個要求封包之前，呼叫因提前回覆而異常終止。（CVE-2026-74429）

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

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

  - regulator： core：regulator_lock_two（） 應該測試 EDEADLK，而不是 EDEADLOCK 比較 -EDEADLK，這是 ww_mutex_lock（） 實際傳回的內容，也是此檔案中所有其他鎖死檢查都已使用的。函數 regulator_lock_two（） 通過 regulator_lock_nested（） -> ww_mutex_lock（） 獲取兩個調節器。在爭用時，ww_mutex_lock（） 會傳回 -EDEADLK，這是呼叫端的訊號，用於捨棄其持有的鎖定，並依規範順序重試擷取。不過，regulator_lock_two （） 會針對 -EDEADLOCK 而不是 -EDEADLK 測試傳回值。在大多數架構上，EDEADLK 和 EDEADLOCK 的值相同，因此比較恰好是正確的，而且錯誤是看不見的。但在 MIPS、SPARC 和 PowerPC 上，這兩個錯誤具有不同的值。測試是錯誤的：真正的 -EDEADLK 輪詢不再與 -EDEADLOCK 匹配，因此代碼不是解鎖和重試，而是落入 WARN_ON（ret） 並返回兩個調節器中的一個被鎖定。實際上，這只是 MIPS 上的錯誤，因為穩壓器核心並未在其他兩個平台上建置或使用。一般而言，對於新程式碼，EDEADLK 比 EDEADLOCK 更受歡迎。（CVE-2026-72314）

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

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

  - WiFi：RT2x00：在探測器 rt2x00lib_probe_dev（） 中的工作設定之前，避免完全拆卸，對所有探測器故障使用完整的 rt2x00lib_remove_dev（） 拆卸。但是，在初始化intf_work、autowakeup_work和sleep_work之前，drv_data配置和工作佇列配置可能會失敗。在探測到達設定這些工作項目的點之前，請勿進入完整移除路徑。在drv_data配置失敗時直接返回，並針對工作佇列配置失敗使用小型早期清除路徑。此問題由我們的靜態分析工具發現，然後透過手動檢閱 rt2x00lib_probe_dev（） 和 rt2x00lib_remove_dev（） 來確認。早期探查結束不應呼叫假設後續工作設定已完成的通用拆卸路徑。QEMU PoC 迫使 alloc_ordered_workqueue（） 在到達工作初始化程式之前失敗。產生的失敗路徑輸入 rt2x00lib_remove_dev（），DEBUG_OBJECTS報告堆疊中具有 rt2x00lib_probe_dev（） 和 rt2x00lib_remove_dev（） 的無效工作耗盡。（CVE-2026-72005）

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

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

  - net： fib_rules：不要在 fib_rules_dump（） 中轉儲垂死的fib_rule。rocker_router_fib_event（） 在 RCU 傾印期間呼叫 fib_rule_get（）。如果fib_rule快死了，refcount_inc（） 會抱怨它。讓我們在 fib_rules_dump（） 中呼叫 refcount_inc_not_zero（）。（CVE-2026-74288）

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

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

  - hwmon：（pmbus） 修正將事件傳遞至監管機構核心 Sashiko 報告：提交 754bd2b4a084 （hwmon：
    （pmbus/core）使用 mutex 保護調節器操作） 引入了工作程序，以使用 atomic_or（） 隨著時間的推移批次處理調節器事件。然後，延遲的工作角色將未修改的組合位遮罩傳遞給 regulator_notifier_call_chain（）。核心調節器子系統的 regulator_handle_critical（） 函式使用嚴格的 switch 語句來評估事件參數。如果在背景工作執行之前發生多個不同的錯誤 （例如 REGULATOR_EVENT_UNDER_VOLTAGE |REGULATOR_EVENT_OVER_CURRENT），組合的位元遮罩無法符合任何大小寫。這會將原因保留為 NULL，並完全繞過關鍵 hw_protection_trigger（）。透過將事件一點一點傳遞至調節器事件處理常式來修正問題。
    (CVE-2026-72395)

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

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

  - ksmbd：修正並行 SMB2 交涉中 conn->preauth_info 的釋放後使用，conn->preauth_info 是由 SMB2 協商處理常式配置和釋放，並由回應傳送路徑讀取的共用連線狀態 （結構 preauth_integrity_info、kmalloc-96）。smb2_handle_negotiate（） 配置 conn->preauth_info，並在 deassemble_neg_contexts（） 失敗時將其釋放並將其設定為 NULL。配置和 free/NULL 都發生在 ksmbd_conn_lock（conn） （連接srv_mutex） 下，這會在整個處理常式主體中保留。從 __handle_ksmbd_work（） 的 send： 區塊呼叫的回應傳送路徑 smb3_preauth_hash_rsp（） 讀取 conn->preauth_info 並取消參照 conn->preauth_info->Preauth_HashValue （透過 ksmbd_gen_preauth_integrity_hash（）），而不進行conn_lock。當用戶端在同一連線上驅動兩個 SMB2 協商要求時，當並行傳送路徑背景工作者正在讀取失敗協商路徑時，一個工作角色可以釋放失敗交涉路徑上的連線>preauth_info，從而產生 slab 釋放後使用讀取 （KASAN 確認）。
    傳送路徑讀取測試了 NULL 的 conn->preauth_info，但與 NULL 檢查和取消參照之間發生的釋放爭用，因此單獨的 NULL 防護不會關閉視窗。序列化 ksmbd_conn_lock（conn） 下 smb3_preauth_hash_rsp（） 中的 NEGOTIATE-branch 讀取，並重新檢查鎖定內的 conn->preauth_info。因為交涉處理常式在其 kfree + NULL 指派中保留conn_lock，所以也採用conn_lock的讀取器會在配置之前完全執行，或在 NULL 存放區之後完全執行，而且永遠無法觀察釋放但尚未 NULL 的指標。ksmbd_gen_preauth_integrity_hash（） 本身不進行鎖定（它僅在緩衝區上計算 SHA-512），因此沒有引入鎖定排序反轉，並且conn_lock是一個可休眠互斥，在此發送路徑上是安全的（它已經執行網路 I/O）。（CVE-2026-72422）

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

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

  - openrisc：修正 jump_label smp 同步原始提交 8c30b0018f9d （openrisc：新增跳轉標籤支援） 是從 arm64 複製的，並且沒有正確考慮遠端核心上的 icache 無效在 OpenRISC 中的運作方式。在 OpenRISC 上，遠端 icache 需要失效，否則靜態金鑰在更新後可能會保持狀態。透過以下方式修正 SMP 快取同步： 1. 使用 icache_all_inv 正確使 SMP 系統上的遠端核心 icache 失效。舊代碼使用 kick_all_cpus_sync（），它在遠程 CPU 上運行無操作 IPI 函數調用，該調用確實執行了大量代碼並刷新了進程中的許多緩存行，但不會刷新所有代碼，並且在 OpenRISC 上不正確。2、對於沒有WRITETHROUGH快取的架構，請務必在修補後排清dcache。為了測試這一點，我首先使用自訂測試模組 [0] 重現了該問題。
    測試證實，某些 icache 行在呼叫 static_branch_enable（） 後仍保持過時的static_key程式碼序列。在此修補程式之後，不再有jump_label一致性問題。[0] https://github.com/stffrdhrn/or1k-utils/tree/master/tests/smp_static_key_test （CVE-2026-72154）

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

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

  - 已解決 Linux 核心中的下列弱點：ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd) made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify. (CVE-2026-72381)

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

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

  - netfilter： nf_nat_sip：重新載入可能過時的資料指標引用 sashiko：
    ------------------------------------------------------------------------ [..] 注意到涉及 SIP NAT 協助程式的潛在記憶體錯誤和標頭損毀。在 net/netfilter/nf_nat_sip.c：nf_nat_sip（） 中： if （skb_ensure_writable（skb， skb->len）） { nf_ct_helper_log（skb， ct， cannot mangle packet）; return NF_DROP;
    } uh = （void *）skb->data + protoff;uh->dest = ct_sip_info->forced_dport;if （！nf_nat_mangle_udp_packet（skb， ct， ctinfo， protoff， 0， 0， NULL， 0）） { 如果 skb_ensure_writable（） 重新分配了克隆或片段化的 SKB，則會釋放舊的資料緩衝區。但是，nf_nat_sip（） 無法更新
    *dptr 指向新的緩衝區。它似乎還對可能是 TCP 封包的內容使用 nf_nat_mangle_udp_packet（），這將使用校驗和更新覆蓋序號。
    ------------------------------------------------------------------------ nf_conntrack_sip線化 skb，因此看不到碎片 skb。但是克隆是可能的，所以重建 dptr。停用 TCP 資料流的 nf_nat_mangle_udp_packet（） 分支。這看起來永遠不會發生，否則我們應該已經收到有關此的錯誤報告，所以只需檢查 conntrack 是否為 UDP，否則就刪除。調用conntrack_sip為SIP_HDR_VIA_UDP消息設置 ->forced_dport，因此我認為這對於 TCP 流來說是正確的。（CVE-2026-72251）

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

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

  - rxrpc：rxrpc_verify_data確保每當未配置 rxrpc_call.rx_dec_buffer 時，rx_dec_buffer alloc rxrpc_recvmsg_data（） 呼叫 rxrpc_verify_data（），並假設在成功傳回時必須配置該rx_dec_buffer。但是，如果 rxrpc_skb_priv.len 為零，則 rxrpc_verify_data（） 不會要求分配。此外，配置rx_dec_buffer失敗會導致呼叫具有 NULL 目的地的 skb_copy_bits（），這可能會觸發 NULL 指標解除參照。為防止這些問題，修改 rxrpc_verify_data（） 為一律嘗試配置 rxrpc_call.rx_dec_buffer （如果它是 NULL）。此問題是在私人 sashiko 實例的協助下發現的。（CVE-2026-74435）

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

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

  - ipv4： fib：不要忽略 local/main 表格中的錯誤路由。當啟用CONFIG_IP_MULTIPLE_TABLES但未新增規則時，fib_lookup（） 會直接在兩個表格上執行路由查詢。由於第一次查詢無法正確救助，因此合併的 local/main 表格中的錯誤路由結果可能會被預設表格中的另一個路由覆寫： # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache <local> 新增隨機規則後， 遵循錯誤路由： # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK 答案： 沒有到主機的路由 讓我們修正不一致的行為。（CVE-2026-72421）

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

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

  - powerpc/spufs：修正 spufs_mem_mmap_access（） 中的越界存取 spufs_mem_mmap_access（） 會將本機存放區位移計算為位址 - vma->vm_start，但會針對 vma->vm_end 而不是本機存放區大小進行邊界檢查。在 64 位元上，偏移量始終遠低於 vma->vm_end，因此 clamp 永遠不會觸發，並且 len 對 ctx->ops->get_ls（） 傳回的LS_SIZE緩衝區保持不受限制。拒絕 LS_SIZE 處或超過  的偏移，並將 len 夾在剩餘空間上，鏡像 spufs_mem_mmap_fault（） 和 spufs_ps_fault（） 已經使用的保護。（CVE-2026-68474）

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

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

  - KVM：x86：如果更新 IRTE 以繞過失敗，則使 irqfd->producer 無效 如果更新 IRTE 以繞過失敗，則使 irqfd->producer 無效，因為如果 irqfd 可透過 KVM 的路由連線，但生產者會單獨釋放，則留下懸空指標會導致釋放後使用。例如，對於 VFIO PCI，生產者內嵌在結構vfio_pci_irq_ctx中，並在停用向量時釋放，這可能與路由更新無關。[肖恩：刪除 PPC 更改，按摩變更日誌]（CVE-2026-72283）

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

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

  - ALSA： usb-audio： qcom： 拒絕在沒有活動介面的情況下停用串流 handle_uaudio_stream_req（） 會解析具有 info_idx_from_ifnum（） 的介面索引，當沒有介面相符時，會傳回 -EINVAL。enable 分支和 response： cleanup 標籤都可以防止負索引，但 disable 分支則不然：它形成 info = &uadev[pcm_card_num].info[info_idx] 並取消參照它。uadev[].info 是僅在首次啟用資料流時才配置的指標，因此停用路徑上的負info_idx在兩種方面是不安全的：- 如果卡片從未啟用，則 .info 為 NULL，&info[-EINVAL] 是百用指標;讀取資訊>data_ep_pipe錯誤 （核心 OOPS）。- 如果卡片至少啟用過一次 （已配置 .info），且停用會命名不相符的介面，則 &info[-EINVAL] 會在配置之前指向;
    info->data_ep_pipe / info->sync_ep_pipe 是越界 slab 讀取，當非零時，是越界 4 位元組寫入 （兩個管道欄位都會清除為 0）。這是記憶體損毀，而不僅僅是 NULL 解除參照。可從無權限的本機使用者空間透過 AF_QIPCRTR 連線要求。拒絕沒有已解析介面的停用要求，以符合啟用路徑已有的防護。（CVE-2026-72446）

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

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

  - afs： 修正回呼服務訊息剖析器以傳遞 -EAGAIN AFS 檔案系統用戶端使用 rxrpc 伺服器來接聽回呼通知。每個回呼呼叫類型處理常式都有一個傳遞函式，可剖析傳入的要求資料流，這應該傳回 -EAGAIN 尚未看到最後一個封包，但所有目前排入佇列的接收資料都會被取用。afs_extract_data（） 會執行此操作，但 -EAGAIN 傳回會無意中切換為 0 修正回呼服務訊息剖析器以通過 -EAGAIN （CVE-2026-72374）

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

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

  - ASoC： SOF： ipc4-control： 修正 sof_ipc4_bytes_put 中的 TOCTOU 在 sof_ipc4_bytes_put （） 中，副本大小衍生自緩衝區中的舊資料>大小，而不是來自 ucontrol 的送入新資料大小欄位。如果新資料的大小不同，則複本會使用錯誤的長度：可能會截斷有效資料或複製過時的位元組。在複製之前，驗證並使用 ucontrol 傳入資料的 sof_abi_hdr.size 來修正。（CVE-2026-72304）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: validate attribute values on lookup ntfs_attr_find() and ntfs_external_attr_find() check that generic resident attribute values fit in their attribute records and that fixed-size resident values are large enough. For variable-length resident formats, however, the fixed part is not enough: embedded length fields can still point callers past the resident value. A crafted image can set a small resident $FILE_NAME value_length while leaving file_name_length large. Callers then trust file_name_length and read past the resident value when converting or comparing the name. This was reproduced with a crafted image under KASAN as a slab-out-of-bounds read from the kmalloc-1k MFT record copy. The stack included ntfs_lookup(), ntfs_iget(), ntfs_read_locked_inode(), ntfs_attr_name_get(), ntfs_ucstonls(), and utf16s_to_utf8s(). Add a shared attribute value validator and use it before a lookup path can return an attribute, including the AT_UNUSED enumeration case where callers inspect returned attributes directly. The helper validates resident value bounds, minimum resident value sizes, variable-length $FILE_NAME fields, and non-resident mapping-pairs metadata that was previously checked separately in both lookup paths. This also preserves the intended resident @val matching semantics in the external attribute lookup path. The old duplicated validation block overwrote the actual resident value length with the type-specific minimum length before comparing @val, so variable-length resident values could fail to match even when the bytes were identical. Keep the comparison on the actual value length, and make ntfs_attrlist_entry_add() compare resident attributes with lowest_vcn zero instead of reading the non-resident union member after a successful resident match. Reject non-resident $FILE_NAME records too: the format requires $FILE_NAME to be resident and callers treat returned records as resident. (CVE-2026-72209)

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

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

  - wifi：rtw89：在連結查詢中對韌體mac_id新增邊界檢查 RX 描述元中的 mac_id 欄位為 8 位寬 （0-255），但 assoc_link_on_macid[] 只有 RTW89_MAX_MAC_ID_NUM （128） 個項目。雖然驅動程式目前指派低於 128 的mac_id值，但描述元值來自韌體，而且在做為陣列索引之前不會經過驗證。在 rtw89_assoc_link_rcu_dereference（） 中新增防禦邊界檢查，以防止超出範圍的韌體值。（CVE-2026-74409）

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

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

  - 交握：需要管理員權限才能完成命令 ACCEPT 和 DONE 是交握 genl 系列的兩個向下呼叫，兩者都供受信任的交握代理程式 （tlshd） 使用。ACCEPT 已經需要GENL_ADMIN_PERM;DONE 完全沒有權限檢查。handshake_nl_done_doit（） 中的 fd-lookup 僅確認所提供的 sockfd 存在一些擱置的交握請求;它不會驗證寄件者。因此，猜測或觀察有效 sockfd 的無權限處理程序可以提交 HANDSHAKE_A_DONE_STATUS == 0 的 DONE，讓核心消費者繼續進行，就好像交握成功一樣。偽造的 DONE 上的非零狀態會在 tlshd 報告其實際結果之前破壞合法的進行中交握。（CVE-2026-74270）

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

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

  - nvme-multipath：修正結構中的彈性陣列大小 nvme_ns_head struct nvme_ns_head包含彈性陣列成員， current_path[]該成員使用 NUMA 節點 ID 進行索引：head->current_path[numa_node_id（）] 結構目前分配為：size = sizeof（struct nvme_ns_head） + （num_possible_nodes（） * sizeof（struct nvme_ns *））; head = kzalloc（size， GFP_KERNEL）;此配置假設 NUMA 節點識別碼是循序的，並且從 0 開始密集封裝。num_possible_nodes（） - 1.雖然此假設適用於許多系統，但在某些架構 （例如 powerpc） 上並不總是如此。在某些 powerpc 系統上，NUMA 節點識別碼可能很稀疏。例如： NUMA： NUMA 節點： 6 NUMA 節點0 CPU： 80-159 NUMA 節點8 CPU： 0-79 NUMA 節點252 CPU： NUMA 節點253 CPU： NUMA 節點254 CPU： NUMA 節點255 CPU： 也就是說，可能/線上的 NUMA 節點 ID 為： 0， 8， 252， 253， 254， 255 在此情況下： num_possible_nodes（） = 6 因此，僅為 中的 current_path[]6 個項目配置記憶體。不過，陣列稍後會使用實際的 NUMA 節點識別碼編製索引。因此，諸如 head->current_path[8] 或 head->current_path[252] 之類的存取會越界，導致下列 KASAN splat：
    ================================================================== 錯誤： KASAN：nvme_mpath_revalidate_paths+0x22c/0x290 中的 slab-out-of-bounds [nvme_core] 由任務 kworker/u641：2/1997 在 addr c00020003bda35b8 寫入大小 8 CPU：1 UID：0 PID：1997 Comm：kworker/u641：2 未受污染 7.1.0-rc5-dirty #14 PREEMPT（lazy） 硬體名稱：8335-GTH POWER9 0x4e1202 opal：skiboot-v6.5.3-35-g1851b2a06 PowerNV 工作佇列：
    非同步async_run_entry_fn呼叫追蹤：[c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc （不可靠） [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 ， [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db00 ] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 由任務 1997 在 CPU 1 上的 35.928317s 分配： 有錯誤的位址屬於 c00020003bda3000 的物件，該物件屬於大小為 2048 的快取 kmalloc-rnd-15-2k 有錯誤的位址位於已分配的 1448 位元組區域右側 16 位元組 [c00020003bda3000， c00020003bda35a8） 有錯誤的位址屬於實體頁面： 有錯誤位址周圍的記憶體狀態：
    c00020003bda3480： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580： 00 00 00 00 00 00 fc ^ c00020003bda3600： fc fc fc c00020003bda3680： fc fc fc fc fc fc ================================================================== 透過使用 nr_node_ids 而不是 num_possible_nodes（） 配置彈性陣列來解決此問題。由於 nr_node_ids 代表最大可能的 NUMA 節點 ID，因此即使在節點 ID 稀疏的系統上，使用 numa_node_id（） 進行索引 current_path[] 也會變得安全。（CVE-2026-74384）

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

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

  - 已解決 Linux 核心中的下列弱點：net: Stop leased rxq before uninstalling its memory provider netif_rxq_cleanup_unlease() tears down the memory provider that was installed on a physical RX queue through a netkit queue lease. It currently revokes the provider's DMA mappings before stopping the physical queue: __netif_mp_uninstall_rxq(virt_rxq, p); /* DMA unmap */
    __netif_mp_close_rxq(phys_rxq->dev, rxq_idx, p); /* queue stop */ This inverts the ordering used by the regular teardown paths (normal device unregister and the io_uring zcrx close path), which stop the queue before revoking the provider's mappings. With the physical queue still live, its NAPI can keep consuming net_iov entries from the page_pool alloc cache after the __netif_mp_uninstall_rxq() has already cleared their dma_addr, opening a window for the device to DMA to a stale or zero address. Fix it by swapping the two calls so the queue is stopped (and its NAPI quiesced) before the provider is uninstalled. No functional regression was observed across repeated runs of the nk_qlease.py HW selftest, which exercises the lease teardown path; this was tested against fbnic QEMU emulation. (CVE-2026-74285)

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

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

  - netfilter： ip6tables：標示格式錯誤的 IPv6 延伸標頭以進行熱掉落 ah、hbh 及 rt 相符專案會檢查是否存在固定延伸標頭，然後使用標頭長度欄位衍生通告的延伸標頭長度以進行比對。針對 ah 相符項目，新增缺少的 advertised-length 檢查。針對 hbh 和 rt，更新現有的通告長度檢查。在這三種情況下，請將 hotdrop 設定為 true，然後在通告的延伸模組標頭長度超過可用的 skb 資料時傳回 false。傳回 false 會將封包視為規則不相符。將 hotdrop 設定為 true 並丟棄格式錯誤的封包，以便它們無法繞過旨在丟棄具有這些 IPv6 延伸標頭的封包的規則。（CVE-2026-72348）

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

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

  - bpf：透過遍歷程式 hlist 並線性計算項目，修正有效程序陣列索引，其中 BPF_F_PREORDER replace_effective_prog（） 和 purge_effective_progs（） 位於有效陣列中的插槽。該計數與陣列佈局不匹配：compute_effective_ progs（） 將BPF_F_PREORDER程式放在前面（祖先 cgroup 在前，在 cgroup 內附加順序），其餘程式放在它們之後（後代 cgroup 在前）。因此，當存在預排序程式時，線性 hlist 位置不再等於有效數組中程式的索引。對於 replace_effective_prog（） （bpf_link_update（）），這會覆寫錯誤的槽位，從而破壞有效順序。對於 purge_effective_progs（），它可以模擬出屬於不同程式的插槽，並將分離的程式留在陣列中，而 bpf_prog_put（） 刪除其引用，即釋放後使用。透過在共用 effective_prog_pos（） 協助程式中重播 compute_effective_progs（） 的位置 （包括 per-cgroup 預排序反轉） 來修正這兩個問題。依其結構bpf_prog_list指標而非 （prog， link） 值來識別項目，因此即使相同的bpf_prog附加至階層中的數個 cgroup，查閱也會精確解析為系統呼叫所選取的附件。（CVE-2026-72427）

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

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

  - 已解決 Linux 核心中的下列弱點：rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages. (CVE-2026-74428)

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

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

  - net/sched： sch_multiq：將直接出隊呼叫替換為 peek，qdisc_dequeue_peeked multiq_dequeue（） 在 multiq_peek（） 窺視後，透過直接 ->dequeue（） 呼叫從頻段的子項獲取資料包。當子項不保留工作時，窺視會將 skb 隱藏在子項的gso_skb中，因此直接出列會傳回不同的 skb 並孤立儲存，從而取消同步子項的 qlen/backlog。當透過窺視父項（例如 tbf）到達 qfq 子項時，這會在空白清單中重新輸入子項並取消參照 NULL，從而在普通出口時使核心從 softirq 中出現恐慌。通過 qdisc_dequeue_peeked（） 獲取數據包，就像sch_prio已經做的那樣，正如 sch_red 和 sch_sfb 剛剛固定要做的那樣。當孩子沒有藏匿處時，幫手是無手術的，因此節省工作的孩子不會受到影響。（CVE-2026-72036）

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

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

  - fs/proc/task_mmu：修正 make_uffd_wp_huge_pte（） prot-update 爭用修補程式系列 userfaultfd/pagemap：預先存在的修正。這些是預先存在的錯誤修正，在 userfaultfd RWP 工作集追蹤系列的前面進行，直到 v5 [1]。根據評論反饋，修復不應位於功能系列的中間，它們會被拆分並自行發送;RWP 系列在此基礎上重新發布。所有六款產品均由 Sashiko AI 對 RWP 系列的審查標記，並且獨立於 RWP 攜帶，直接應用於 mm-new，並攜帶 Cc：stable@。1：fs/proc/task_mmu：當 PAGEMAP_SCAN 寫入保護 hugetlb PTE 時，make_uffd_wp_huge_pte（） 中缺少 huge_ptep_modify_prot_start（） 可能會遺失硬體已變更/已存取更新。2：fs/proc/task_mmu：pagemap_scan_hugetlb_entry（） 將範圍與 HPAGE_SIZE 而不是 hstate 頁面大小進行比較，因此它永遠不會寫入保護巨大的 hugetlb 頁面。3：fs/proc/task_mmu：
    PAGEMAP_SCAN在未填充的 hugetlb 範圍內進行PM_SCAN_WP_MATCHING時，會發生自鎖死 -- pagemap_scan_pte_hole（） 調用 uffd_wp_range（），而 walk_hugetlb_range（） 持有 hugetlb vma 鎖進行讀取，然後 hugetlb_change_protection（） 將其用於寫入。請改為內嵌安裝標記。4:
    mm/huge_memory：change_non_present_huge_pmd（） 會在裝置私有 PMD 權限降級時丟棄pmd_swp_uffd_wp，以無訊息方式遺失 uffd-wp 標記。5：userfaultfd：must_wait（） 將 pte_write（） 應用於無鎖定讀取的 PTE，而不檢查 pte_present（），因此交換/遷移項目解碼隨機偏移位，並且執行緒可以保持停駐在過時的錯誤上。6：userfaultfd：__VMA_UFFD_FLAGS無條件地將VMA_UFFD_MINOR_BIT （41） 饋送給 mk_vma_flags（），對 32 位元上的單字vma_flags_t進行越界寫入。
    從配置門控的每個模式遮罩構建遮罩，這樣不可用的位就永遠不會實現。此修補程式（共 6 個）：make_uffd_wp_huge_pte（） 透過調用 huge_ptep_modify_prot_commit（） 來保護當前 HugeTLB PTE 上的UFFD_WP位元，該快照是在沒有相應 huge_ptep_modify_prot_start（） 的情況下擷取的。啟動協助程式會以不可部分完成的方式清除項目，因此核心擁有的快照集會保持一致，直到提交為止;如果沒有它，硬體可能會在原始讀取和提交之間的即時 PTE 中設定 Dirty 或 Accessed，而 huge_ptep_modify_prot_commit（） （其通用實作僅呼叫 set_huge_pte_at（）） 然後將過時的快照寫回即時硬體位元，從而丟失更新。非 hugetlb 同級 make_uffd_wp_pte（） 透過 ptep_modify_prot_start（） / ptep_modify_prot_commit（） 正確執行此操作。針對 present-PTE 分支鏡像該模式。移轉案例會維持原樣 -- 移轉項目不存在，因此沒有硬體更新可供爭用。（CVE-2026-72175）

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

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

  - RDMA/mlx5：修正使用者 RQ WQE 大小的未定義移位 set_rq_size（） 會根據使用者提供的rq_wqe_shift，將 RQ WQE 大小計算為 1 << rq_wqe_shift，僅檢查為大於 32，因此仍接受 32 的移位。移位 31 也會溢出帶正負號的整數，導致未定義的行為。使用 check_shl_overflow（） 計算 RQ WQE 大小並拒絕任何無效值。
    (CVE-2026-74297)

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

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

  - octeontx2-af：修正影響 PF 混雜狀態的 VF 啟動 Mbox 處理 nix_set_rx_mode 對於將混雜和all_multi旗標設定為 false 的 VF 會導致刪除 PF 的混雜和 allmulti MCAM 規則。發生這種情況是因為啟用/停用這些規則的API僅在PF上運作，即使透過VF介面提出mbox要求也是如此。使用 is_vf（） 檢查保護 rvu_npc_enable_allmulti_entry（） 和 rvu_npc_enable_promisc_entry（） 停用路徑，讓啟動或關閉其介面的 VF 不會無意中清除 PF 的 MCAM 規則。（CVE-2026-72312）

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

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

  - iommu/vt-d：在拆除可調整模式內容項目之前清除 Present 位元 device_pasid_table_teardown（） 會以 context_clear_entry（） 將 128 位元可調整模式內容項目歸零，而 Present 位元仍處於設定狀態。這會建立一個窗口，硬體可以在其中擷取撕裂的條目，當 Present 仍設定時，某些欄位已經歸零，從而導致不可預測的行為或虛假故障。只有在項目歸零之後，才會發出內容快取無效，然後 intel_pasid_free_table（） 會釋放 PASID 目錄頁面，因此 IOMMU 可以繼續遍歷指向釋放記憶體的過時 Present=1 項目。雖然 x86 提供強式寫入順序，但編譯器可能會重新排序項目的兩個 64 位寫入，而且硬體擷取不保證相對於多個 CPU 寫入是不可部分完成的。提交 c1e4f1dccbe9d （iommu/vt-d：在拆卸上下文項目之前清除 Present 位元） 修正了 domain_context_clear_one（） 和複製的上下文路徑中的此確切模式，但 device_pasid_table_teardown（） 未轉換。使用與同級修正相同的擁有權交握，將其與 VT-d 規格第 1 節 6.5.3.3中的軟體無效指南保持一致：
    只清除 Present 位，將它排清至 IOMMU，執行內容快取無效，然後才將項目的其餘部分歸零。（CVE-2026-74439）

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

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

  - bpf， sockmap：修正 bpf_msg_pop_data（） 邊界中的整數溢位，檢查 start 和 len 是 u32，所以 u64 last = start + len;以 32 位元計算 start + len，並在將其儲存在 last 之前進行包裝。邊界檢查是否 （start >= offset + l || last > msg->sg.size） return -EINVAL;然後可以使用超出範圍的 start/len 傳遞，之後 pop 迴圈從散點清單的末尾運行，並在空的 msg->sg.end 插槽上sk_msg_shift_left（） 調用 put_page（）：哎呀：一般保護故障，可能用於非規範位址 0xdffffc0000000001：0000 [#1] SMP KASAN PTI KASAN：null-ptr-deref 在 [0x0000000000000008-0x000000000000000f] 範圍內 RIP：0010：sk_msg_shift_left net/core/filter.c：2957 [內聯] RIP：
    0010：____bpf_msg_pop_data net/core/filter.c：3103 [內嵌] RIP：0010：bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c：2984 呼叫追蹤： <TASK> bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h：746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c：934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c：420 [內嵌] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c：583 __sock_sendmsg+0x153/0x1c0net/socket.c：802 __sys_sendto+0x326/0x430 net/socket.c：2265 __x64_sys_sendto+0xe3/0x100 net/socket.c：2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 使用 （u64） 轉換擴大加法範圍，以便以 64 位元評估邊界，並且接近 U32_MAX 的 len 不再在 msg->sg.size 以下換行。在這裡，將 pop 從 int 更改為 u32。它根據未帶正負號的散佈清單長度計算位元組，並且永遠不能為負數，因此帶正負號類型只會在 pop 迴圈中引起符號混淆。（CVE-2026-74256）

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

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

  - 已解決 Linux 核心中的下列弱點：net: dsa: mxl862xx: fix use-after-free of DSA ports in crc_err_work Upon an MDIO CRC error mxl862xx_crc_err_work_fn() walks the DSA ports and closes the CPU port conduits: dsa_switch_for_each_cpu_port(dp, priv->ds) dev_close(dp->conduit);
    mxl862xx_remove() unregisters the switch before cancelling this work: set_bit(MXL862XX_FLAG_WORK_STOPPED, &priv->flags); cancel_delayed_work_sync(&priv->stats_work); dsa_unregister_switch(ds);
    mxl862xx_host_shutdown(priv); dsa_unregister_switch() frees the dsa_port objects. If a CRC error schedules the work during teardown it can run after the ports have been freed and dereference freed memory. Guard the port walk with MXL862XX_FLAG_WORK_STOPPED, which is already set before dsa_unregister_switch(). DSA tears the ports down under rtnl_lock(), so checking the flag under rtnl_lock() means the work either runs before teardown and sees valid ports, or runs afterwards, observes the flag and skips the walk. This mirrors the host_flood_work handler, which skips torn-down ports under rtnl_lock(). (CVE-2026-72411)

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

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

  - netfilter： nf_dup_netdev：新增 nf_dev_xmit_recursion*（） 協助程式並使用它們 更新nft_dup並nft_fwd以使用 nf_dev_xmit_recursion（） 協助程式。此修補程式也會在傳輸 skb 時停用 BH，以解決可能移轉至不同 CPU 的問題，導致遞迴計數器遞減不平衡。這是以 Florian Westphal 的 dev_xmit_recursion*（） API 為模型，自提交 97cdcf37b57e （net：
    將 XMIT 遞迴放在軟網路資料中），根據其在樹狀結構中的目前狀態。（CVE-2026-74260）

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

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

  - fs/ntfs3：防止潛在的 LCN 保持未初始化狀態 在 runs[0] 中找不到所尋找的目標 VCN，導致 run_lookup（） 傳回 false。這會導致 run_lookup_entry（） 傳回 false，進而導致 len 值為 0，並且傳遞給 attr_data_get_block（） 的新參數為 NULL。
    總的來說，這些因素最終導致 attr_data_get_block_locked（） 在沒有初始化 lcn 的情況下過早退出，從而觸發 [1]。為了防止 [1]，ni_seek_data_or_hole（） 內的 clen 檢查已移至在 lcn 檢查之前進行。[1] 錯誤：KMSAN：ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c：2862 中的 uninit-value ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c：2862 ntfs_llseek+0x22a/0x4a0 fs/ntfs3/file.c：1530 vfs_llseek fs/read_write.c：391 [內嵌] （CVE-2026-72471）

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

ID	名稱	嚴重性
337521	Linux Distros 未修補弱點：CVE-2026-68479	high
337520	Linux Distros 未修補弱點：CVE-2026-72232	high
337519	Linux Distros 未修補弱點：CVE-2026-72502	high
337518	Linux Distros 未修補弱點：CVE-2026-74578	high
337517	Linux Distros 未修補弱點：CVE-2026-72491	critical
337516	Linux Distros 未修補弱點：CVE-2026-72196	high
337515	Linux Distros 未修補弱點：CVE-2026-72282	high
337514	Linux Distros 未修補弱點：CVE-2026-72303	high
337513	Linux Distros 未修補弱點：CVE-2026-72217	critical
337512	Linux Distros 未修補弱點：CVE-2026-72164	high
337511	Linux Distros 未修補弱點：CVE-2026-74279	critical
337510	Linux Distros 未修補弱點：CVE-2026-72449	high
337509	Linux Distros 未修補弱點：CVE-2026-72370	medium
337508	Linux Distros 未修補弱點：CVE-2026-74380	high
337507	Linux Distros 未修補弱點：CVE-2026-72269	medium
337506	Linux Distros 未修補弱點：CVE-2026-72149	high
337505	Linux Distros 未修補弱點：CVE-2026-72489	high
337504	Linux Distros 未修補弱點：CVE-2026-74429	high
337503	Linux Distros 未修補弱點：CVE-2026-72314	high
337502	Linux Distros 未修補弱點：CVE-2026-72005	high
337501	Linux Distros 未修補弱點：CVE-2026-74288	high
337500	Linux Distros 未修補弱點：CVE-2026-72395	high
337499	Linux Distros 未修補弱點：CVE-2026-72422	critical
337498	Linux Distros 未修補弱點：CVE-2026-72154	high
337497	Linux Distros 未修補弱點：CVE-2026-72381	critical
337496	Linux Distros 未修補弱點：CVE-2026-72251	critical
337495	Linux Distros 未修補弱點：CVE-2026-74435	high
337494	Linux Distros 未修補弱點：CVE-2026-72421	critical
337493	Linux Distros 未修補弱點：CVE-2026-68474	high
337492	Linux Distros 未修補弱點：CVE-2026-72283	high
337491	Linux Distros 未修補弱點：CVE-2026-72446	high
337490	Linux Distros 未修補弱點：CVE-2026-72374	high
337489	Linux Distros 未修補弱點：CVE-2026-72304	high
337488	Linux Distros 未修補弱點：CVE-2026-72209	critical
337487	Linux Distros 未修補弱點：CVE-2026-74409	high
337486	Linux Distros 未修補弱點：CVE-2026-74270	high
337485	Linux Distros 未修補弱點：CVE-2026-74384	critical
337484	Linux Distros 未修補弱點：CVE-2026-74285	high
337483	Linux Distros 未修補弱點：CVE-2026-72348	critical
337482	Linux Distros 未修補弱點：CVE-2026-72427	high
337481	Linux Distros 未修補弱點：CVE-2026-74428	critical
337480	Linux Distros 未修補弱點：CVE-2026-72036	high
337479	Linux Distros 未修補弱點：CVE-2026-72175	high
337478	Linux Distros 未修補弱點：CVE-2026-74297	high
337477	Linux Distros 未修補弱點：CVE-2026-72312	high
337476	Linux Distros 未修補弱點：CVE-2026-74439	critical
337475	Linux Distros 未修補弱點：CVE-2026-74256	high
337474	Linux Distros 未修補弱點：CVE-2026-72411	high
337473	Linux Distros 未修補弱點：CVE-2026-74260	high
337472	Linux Distros 未修補弱點：CVE-2026-72471	high

偵測

Nessus 的 Misc. 系列

high

high

high

high

critical

high

high

high

critical

high

critical

high

medium

high

medium

high

high

high

high

high

high

high

critical

high

critical

critical

high

critical

high

high

high

high

high

critical

high

high

critical

high

critical

high

critical

high

high

high

high

critical

high

high

high

high