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

  - ext4：在提交 I/O 之前分割時，不要設定 EXT4_GET_BLOCKS_CONVERT 在啟用 dioread_nolock 的情況下，在 EOF 內 DIO 和回寫期間配置區塊時，EXT4_GET_BLOCKS_PRE_IO 設定為分割現有的大型未寫入範圍。但是，調用 ext4_split_convert_extents（） 時設定了 EXT4_GET_BLOCKS_CONVERT，這可能會導致過時的資料問題。假設我們有一個未寫入的範圍，然後 DIO 寫入後半部分。[UUUUUUUUUUUUUUUUUUUU] 磁碟範圍 U：未寫入的範圍 [UUUUUUUUUUUUUUUUU] 範圍狀態樹狀結構 |<- ->|----> dio 寫入此範圍 首先，ext4_iomap_alloc（） 調用 ext4_map_blocks（），並設定了 EXT4_GET_BLOCKS_PRE_IO、EXT4_GET_BLOCKS_UNWRIT_EXT 和 EXT4_GET_BLOCKS_CREATE 標誌。ext4_map_blocks（） 找到此範圍並呼叫 ext4_split_convert_extents（），並設定EXT4_GET_BLOCKS_CONVERT並設定上述旗標。然後，ext4_split_convert_extents（） 調用設定了 EXT4_EXT_MAY_ZEROOUT、EXT4_EXT_MARK_UNWRIT2 和 EXT4_EXT_DATA_VALID2 旗標的 ext4_split_extent（），並調用 ext4_split_extent_at（） 來分割設定了 EXT4_EXT_DATA_VALID2、EXT4_EXT_MARK_UNWRIT1、EXT4_EXT_MAY_ZEROOUT 和 EXT4_EXT_MARK_UNWRIT2 旗標的後半部分。但是，ext4_split_extent_at（） 由於暫時缺少 -ENOSPC，因此無法插入範圍。它會將前半部分歸零，但會將整個磁碟上的範圍轉換為自設定EXT4_EXT_DATA_VALID2旗標設定以來的寫入範圍，但將後半部分保留為範圍狀態樹狀結構中的未寫入。[00000000000SSSSSS] 資料 S：過時資料，0：歸零 [WWWWWWWWWWWWWWWW] 磁碟範圍 W：寫入範圍 [WWWWWWWUUUUUUU] 範圍狀態樹狀結構 最後，如果 DIO 無法將資料寫入磁碟，則一旦快取的範圍項目消失，後半部分的過時資料就會暴露。在提交 I/O 之前分割未寫入的範圍時不傳遞EXT4_GET_BLOCKS_CONVERT來修正此問題，並在此情況下使 ext4_split_convert_extents（） 將整個範圍範圍歸零，並在範圍狀態樹狀結構中標示範圍以保持一致性。（CVE-2026-45985）

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

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

  - KVM： SVM：如果是 EFER，則為 INVLPGA 注入 #UD。SVME=0 INVLPGA 應在 EFER 時引起 #UD。未設定 SVME。新增檢查，以便在 EFER 時正確插入 #UD。SVME=0。[肖恩：stable@標籤]（CVE-2026-46082）

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

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

  - nfsd：絕不在 idmap 查詢期間延遲請求 在 v4 請求複合 arg 解碼期間，某些操作 （例如
    SETATTR） 可以觸發 idmap 查詢呼叫。當這些上調回應延遲超過允許的時間限制時，cache_check（） 會將要求標示為延遲，並導致其遭到捨棄。這會防止執行nfs4svc_encode_compoundres，因此永遠不會清除工作階段插槽旗標NFSD4_SLOT_INUSE。後續的用戶端要求會失敗，並NFSERR_JUKEBOX，因為插槽會標示為使用中，使 SEQUENCE 操作失敗。透過確保 RQ_USEDEFERRAL 旗標在 nfs4svc_decode_compoundargs（） 期間始終清晰來解決此問題，因為不應延遲任何 v4 請求。（CVE-2026-45983）

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

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

  - net：qrtr：ns：在 ctrl_cmd_bye（） 期間釋放節點 當節點即將關閉時，節點會傳送 BYE 封包。因此，名稱伺服器應該向所有遠端和本機觀察者通告刪除節點，並最終釋放節點。但目前，名稱伺服器即使在處理 BYE 封包後也不會釋放節點記憶體。這會導致節點記憶體洩漏。因此，請從 Xarray 清單中移除節點，並在 ctrl_cmd_bye（） 的成功和失敗情況下釋放節點記憶體。（CVE-2026-46038）

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

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

  - iommu/vt-d：在卸除內容項目之前清除 Present 位 卸除內容項目時，目前的實作會使用多個 64 位寫入，將整個 128 位項目歸零。這會建立一個窗口，硬體可以在其中擷取撕裂的條目，其中某些欄位已經歸零，而「存在」位仍處於設定狀態，導致不可預測的行為或虛假故障。雖然 x86 提供強式寫入排序，但編譯器可能會重新排序內容項目的兩個 64 位半寫入。即使沒有編譯器重新排序，也不保證硬體擷取對於多個 CPU 寫入是不可部分完成的。透過實施建議的所有權握手，與 VT-d 規範（部分 6.5.3.3）中的軟體無效指南保持一致： 1. 首先僅清除上下文項目的「存在」（P） 位，以表示所有權從硬體過渡到軟體。2. 使用 dma_wmb（） 確保清除的位對 IOMMU 可見。3. 執行所需的快取和上下文快取無效，以確保硬體不再具有對項目的快取參照。4. 只有在無效完成後才將條目完全歸零。此外，將 dma_wmb（） 新增至 context_set_present（），以確保在「Present」位元可見之前項目已完全初始化。（CVE-2026-45944）

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

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

  - RDMA/mana_ib：在 RSS QP 銷毀時停用 RX 轉向 當 RSS QP 被銷毀時 （例如 DPDK 退出），mana_ib_destroy_qp_rss（） 會銷毀 RX WQ 物件，但不會停用韌體中的 vPort RX 轉向。
    這會留下過時的轉向組態，仍指向已損毀的 RX 物件。如果流量繼續到達 （例如，對等虛擬機器仍在傳輸） ，且 VF 介面隨後啟動 （mana_open），韌體可能會使用舊 RX 物件中的過時 CQ ID 來傳遞完成。乙太網路驅動程式可以將這些 CQ ID 重複用於新的 TX CQ，導致 RX 完成登陸 TX CQ：警告：
    mana_poll_tx_cq+0x1b8/0x220 [mana] （is_sq == false） 警告： mana_gd_process_eq_events+0x209/0x290 （cq_table 查詢失敗） 在銷毀 RX WQ 物件之前，請先停用 vPort RX 轉向，以修正此問題。請注意，此處不能使用 mana_fence_rqs（），因為柵欄完成是在 CQ 上傳遞的，CQ 由使用者模式 （例如 DPDK） 輪詢，核心驅動程式不可見。將停用邏輯重構為 mana_en 中的共用 mana_disable_vport_rx（），匯出以供mana_ib使用，取代重複的程式碼。乙太網路驅動程式的 mana_dealloc_queues（） 也會更新，以呼叫此通用函式。（CVE-2026-46084）

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

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

  - libceph：防止 ceph_handle_auth_reply（） 中潛在的 null-ptr-deref 如果 CEPH_MSG_AUTH_REPLY 類型的訊息包含通訊協定和結果的零值，則目前不會將其視為錯誤。如果 ac->negotiating == true 且 ac->protocol > 0，則會導致設定 ac->protocol = 0 且 ac->ops = NULL。此後，對 ac->protocol ！= 通訊協定的檢查傳回 false，並且不會呼叫 init_protocol（）。隨後，調用 ac->ops->handle_reply（），這會導致 null 指標解除參照，因為 ac->ops 仍然是 NULL。此修補程式將 ac->protocol ！= 通訊協定的檢查變更為 ！ac->protocol，因為這也包括在訊息中將通訊協定設定為零的情況。這會導致訊息被視為包含錯誤的驗證通訊協定。（CVE-2026-46024）

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

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

  - netfilter： nfnetlink_queue：在分割之前進行共用未確認檢查 Ulrich 報告帶有 nfqueue 的迴歸： 如果應用程式未設定「F_GSO」功能標誌，並且收到具有未確認nf_conn項目的 GSO 封包，則現在所有封包都會被丟棄而不是排入佇列，因為檢查發生在 skb_gso_segment（） 之後。在這種情況下，我們確實擁有 skb 及其相關 conntrack 條目的獨家所有權。使用計數增加是由於透過 skb_gso_segment（） 發生skb_clone。
    移動檢查，使其已執行的封包與聚集的封包不同。然後，註釋除第一個區段之外的各個區段，以便我們可以在重新插入時進行第二次檢查。在正常情況下，使用者空間會依序重新插入，這可以避免封包丟棄：第一個重新插入的區段繼續遍歷並確認進入，其餘區段觀察已確認的入口。同時，簡化 nf_ct_drop_unconfirmed（）：我們只關心帶有 refcnt > 1 的未確認條目，沒有必要對垂死條目進行特殊情況。
    這只會發生在 UDP 上。使用 TCP 時，唯一未確認的封包將是 TCP SYN，這些封包不會由 GRO 彙總。下一個修補程式會新增 udpgro 測試案例來涵蓋此案例。（CVE-2026-45859）

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

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

  - FastNetMon 社群版透過 1.2.9 在連接埠 50052 上公開 gRPC API 伺服器，沒有驗證機制。伺服器使用 grpc：：InsecureServerCredentials（） 初始化 （src/fastnetmon.cpp 第 477 行），並且原始程式碼註解明確確認「在沒有任何身份驗證機制的情況下偵聽給定位址」。src/api.cpp中的RPC方法（ExecuteBan、ExecuteUnBan、GetBanlist、GetTotalTrafficCounters 等）均不會執行任何認證驗證。ExecuteBan 和 ExecuteUnBan 方法會觸發安全關鍵動作：可能黑洞網路流量的 BGP 路由公告，以及透過 popen（） 執行外部通知指令碼。具有本機網路存取權的攻擊者可禁止任意 IP 位址 （對合法流量造成拒絕服務）、取消禁止主動攻擊 （停用 DDoS 緩解措施），以及觸發指令碼執行。此外，也沒有將唯讀監控與破壞性系統管理作業區分開來的角色型存取控制。（CVE-2026-48692）

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

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

  - misc： ibmasm：修正 ibmasm_handle_mouse_interrupt（） 中的 OOB MMIO 讀取 當硬體的佇列讀取器或寫入器索引超過 REMOTE_QUEUE_SIZE （60） 時，ibmasm_handle_mouse_interrupt（） 會執行越界 MMIO 讀取。受損的服務處理器可以在宣告中斷之前，將超出範圍的值寫入讀取器或寫入器 MMIO 暫存器，以觸發此觸發。由於寫入器會在每次迴圈反覆專案時從硬體重新讀取，因此也可以在迴圈開始之後將其設定為超出範圍的值。
    根本原因是 get_queue_reader（） 和 get_queue_writer（） 傳回直接傳遞到 get_queue_entry（） 的原始 readl（） 值，該值計算：queue_begin + reader * sizeof（struct remote_input），沒有邊界檢查。然後將此未檢查的 MMIO 位址傳遞給 memcpy_fromio（），從非預期的裝置暫存器讀取 8 個位元組。對於足夠大的值，位址會完全超出 PCI BAR 對應，從而觸發機器檢查例外狀況。在呼叫 get_queue_entry（） 之前，根據迴圈主體頂端的REMOTE_QUEUE_SIZE檢查這兩個索引來修正。在超出範圍的值上，在中斷之前透過 set_queue_reader（） 將讀取器暫存器重設為 0，以便在損毀的硬體狀態暫時性時，可以恢復正常佇列作業。（CVE-2026-46022）

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

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

  - PCI： 端點：pci-epf-ntb：移除重複的資源拆卸 epf_ntb_epc_destroy（） 會複製呼叫端稍後應該執行的拆卸。當.allow_link失敗或執行.drop_link時，這會導致 oops。移除協助程式。同時刪除 pci_epc_put（）。EPC 裝置參照計數與 configfs EPC 群組存留期相關聯，.drop_link路徑中的 pci_epc_put（） 就足夠了。（CVE-2026-46009）

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

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

  - ocfs2：在 dio 完成中拆分交易以避免信用耗盡 在 ocfs2 dio 操作期間，JBD2 可能會透過以下呼叫追蹤報告警告： ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle 輸出： JBD2： kworker/6:2 想要太多的點數 credits：5450 rsv_credits：0 max：5449 若要防止超出點數限制，請修改 ocfs2_dio_end_io_write（） 以處理交易批次中的範圍。此外，重新定位 ocfs2_del_inode_from_orphan（）。只有在範圍樹狀結構更新完成後，才應從孤立清單中移除孤立的 inode。如此可確保如果在範圍樹狀結構更新期間發生損毀，我們不會在 EOF 之外留下過時的區塊。此修補程式還更改了更新 inode 大小和刪除孤立的邏輯，使其類似於 ext4_dio_write_end_io（）。只有在一切看起來都不錯時才會執行這兩項操作。最後，感謝 Jans 和 Joseph 提供錯誤修復原型和建議。（CVE-2026-46080）

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

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

  - net：qrtr：ns：限制節點總數 目前，名稱伺服器不會限制其處理的節點數量。如果惡意用戶端開始註冊隨機節點，這可能是攻擊媒介，導致記憶體耗盡。因此，將節點數目上限限制為 64。請注意，64 個的限制是根據目前的平台需求來選擇的。如果未來需求變更，可以增加此限制。
    (CVE-2026-46003)

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

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

  - net： qrtr： ns： 限制查詢數目上限 目前的程式碼不會限制用戶端可以執行的查詢數目。雖然程式碼將查詢限制為本機用戶端，但仍有可能惡意本機用戶端透過相同的通訊端傳送大量NEW_LOOKUP訊息。藉由將查詢數目上限限制為全域 64 個，以修正此問題。由於名稱伺服器最多只允許一個本機觀察者，因此此全域查詢計數將確保查詢保持在限制內。
    請注意，64 個的限制是根據目前的平台需求來選擇的。如果未來需求變更，可以增加此限制。（CVE-2026-46026）

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

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

  - scsi：sd：修正 device_add（&disk_dev） 失敗時遺失的 put_disk（） 如果 device_add（&sdkp->disk_dev） 失敗，put_device（） 會執行 scsi_disk_release（），這會釋放 scsi_disk，但保留 gendisk 參照。sd_probe（） 中的 device_add_disk（） 錯誤路徑呼叫 put_disk（gd）;在這裡呼叫 put_disk（GD） 以鏡像該清理。（CVE-2026-45997）

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

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

  - FastNetMon 社群版 1.2.9 包含 Juniper 路由器整合外掛程式中的設定插入弱點。在 src/juniper_plugin/fastnetmon_juniper.php 中， $IP_ATTACK 變數 （從 argv[1] 接收） 在第 69 行和第 90 行直接內插到Juniper NETCONF set-configuration 命令中，無需任何驗證或清理。第 69 行： $conn->load_set_configuration（set routing-options static route {$IP_ATTACK} community 65535:666 discard）。第 90 行： $conn->load_set_configuration（刪除 routing-options 靜態路由 {$IP_ATTACK}/32）。可以控制 IP 位址字串的攻擊者可以透過嵌入新行字元，然後嵌入任意 set/delete 命令，注入額外的 Juniper CLI 組態命令。這可能會修改路由器的路由表、防火牆過濾器、使用者帳戶或可透過 NETCONF 存取的任何其他組態元素。影響是路由器完全受損。（CVE-2026-48694）

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

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

  - KVM：nSVM：在第一個 L2 VMRUN 之後，一律使用 NextRIP 作為 vmcb02 的 NextRIP 對於停用 NRIPS 的客體，L1 在執行具有插入軟中斷的 L2 時不會提供 NextRIP，而是會在執行之前推進目前的 RIP。KVM 使用目前的 RIP 作為 vmcb02 中的 NextRIP 來模擬沒有 NRIPS 的 CPU。但是，在 L2 第一次執行之後，CPU 和/或 KVM 會更新 NextRIP ，且目前的 RIP 不再是 vmcb02 中使用的正確值。因此，在儲存/還原之後，當且僅當巢狀執行擱置中時，才使用目前的 RIP，否則使用 NextRIP。給soft_int_next_rip相同的處理方式，因為它是相同的邏輯，只是針對更狹窄的用例。[肖恩：給soft_int_next_rip同樣的待遇]（CVE-2026-46059）

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: algif_aead - snapshot IV for async AEAD requests AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling. Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.
    (CVE-2026-46028)

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

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

  - powerpc/eeh：修正 EEH 事件處理中的遞迴pci_lock_rescan_remove鎖定 最近的提交 1010b4c012b0 （powerpc/eeh：使 EEH 驅動程式裝置熱插拔安全） 重組了 EEH 驅動程式，以改善與 PCI 熱插拔層的同步。然而，它無意中將 pci_lock_rescan_remove（） 移出了 eeh_handle_normal_event（） 中的預期範圍，導致 PCI 錯誤報告中斷和不當觸發 EEH 事件。具體來說，eeh_handle_normal_event（） 在調用 eeh_pe_bus_get（） 之前獲取了 pci_lock_rescan_remove（），但 eeh_pe_bus_get（） 本身嘗試在內部獲取相同的鎖，從而導致巢狀鎖定並中斷正常的 EEH 事件處理路徑。此修補程式將布林參數do_lock新增至 _eeh_pe_bus_get（），並具有兩個公開包裝函式：啟用鎖定的 eeh_pe_bus_get（）。
    跳過鎖定的 eeh_pe_bus_get_nolock（）。已持有 pci_lock_rescan_remove（） 的呼叫端現在使用 eeh_pe_bus_get_nolock（） 來避免遞迴鎖定取得。此外，pci_lock_rescan_remove（） 呼叫會在 eeh_pe_bus_get（） 之後和反覆運算受影響的 PE 和裝置之前還原到正確的位置。這可確保在適當的匯流排重新掃描鎖定下發生 EEH 觸發的 PCI 移除，而不會發生遞迴鎖定爭用。eeh_pe_loc_get（） 函數已拆分為兩個函數：
    eeh_pe_loc_get（struct eeh_pe *pe），擷取指定 PE 的 loc。eeh_pe_loc_get_bus（struct pci_bus
    *bus），以擷取指定匯流排的位置代碼。這解決了 lockdep 警告，例如： <snip> [] [ T928] ============================================ [ 84.964304] [ T928] 警告：偵測到可能的遞迴鎖定 [ 84.964311] [ T928] 6.18.0-rc3 #51 未受污染 [ 84.964315] [ T92884.964298]
    -------------------------------------------- [ 84.964320] T928[ ] eehd/928 正在嘗試取得鎖定： [84.964324] [ T928] c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}，位於：
    pci_lock_rescan_remove+0x28/0x40 [ 84.964342] T928[ ] 但任務已處於鎖定狀態： [ 84.964347] [T928] c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}， at： pci_lock_rescan_remove+0x28/0x40 [84.964357] T928[ ] 其他可能有助於我們偵錯的資訊： [ 84.964363] [ T928] [ ] 可能的不安全鎖定場景： [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock（pci_rescan_remove_lock）;[ 84.964378] [ T928] lock（pci_rescan_remove_lock）;[ 84.964383] [ T928] *** 鎖死 *** [ 84.964388] [ T928] 可能是因為缺少鎖定巢狀表示法 [ 84.964393] [ ] 1 T928個由 EEHD/928 持有的鎖定： [ 84.964397] [ T928] #0： c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}，位於：
    pci_lock_rescan_remove+0x28/0x40 [ 84.964408] T928[ ] 堆疊回溯：[ 84.964414] [ T928] CPU：2 UID：0 PID：928 通訊：eehd 未受污染 6.18.0-rc3 #51 自願性 [ 84.964417] [ T928] 硬體名稱：IBM，9080-HEX POWER10 （架構） 0x800200 0xf000006：IBM，FW1060.00 （NH1060_022） hv：phyp pSeries [ 84.964419] [] 呼叫T928追蹤：[ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 （不可靠） [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated--- （CVE-2026-45904）

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

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

  - md/raid5：在存取日誌中繼資料之前驗證承載大小 r5c_recovery_analyze_meta_block（） 和 r5l_recovery_verify_data_checksum_for_mb（） 使用磁碟上的承載大小欄位反覆運算日誌中繼資料區塊中的承載，而不針對中繼資料區塊中的剩餘空間進行驗證。損毀的日誌包含超出PAGE_SIZE界限的承載大小，在存取承載欄位或計算位移時，可能會導致越界讀取。為每個承載類型新增邊界驗證，以確保完整的承載符合處理前的meta_size。（CVE-2026-46070）

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

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

  - FastNetMon Community Edition through 在 1.2.9 NetFlow v9 選項範本剖析器中包含越界讀取。在 process_netflow_v9_options_template（） （src/netflow_plugin/netflow_v9_collector.cpp） 中，範圍剖析迴圈 （行 224-229） 會反覆運算，直到scopes_offset達到攻擊者控制的option_scope_length值，並在每個步驟讀取netflow9_template_flowset_record_t結構。無邊界檢查會驗證 （zone_address + scopes_offset + sizeof（record）） 是否保留在流程集中。同樣的問題會影響帶有option_length的選項欄位迴圈（行 241-257）。此外，option_scope_length未被驗證為 sizeof（netflow9_template_flowset_record_t） 的倍數，可能會導致讀取未對齊。攻擊者可觸發超過 UDP 封包緩衝區末端的讀取。（CVE-2026-48684）

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

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

  - tpm：st33zp24：修正 get_burstcount（） 錯誤中缺少的清理 get_burstcount（） 可以在逾時時傳回 -EBUSY。發生這種情況時，st33zp24_send（） 會直接傳回，而不會釋放先前取得的位置性。使用 goto out_err確保在 get_burstcount（） 失敗時正確清除。（CVE-2026-45871）

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

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

  - bpf：修正未提供 prog fd 時的 tcx/netkit 分離權限 此提交修正了一個安全問題，即當未提供程式 fd 時，任何使用者都可以執行 tcx 或 netkit 裝置上的BPF_PROG_DETACH，繞過權限檢查。在此情況下，此修正程式會新增CAP_NET_ADMIN或CAP_SYS_ADMIN功能檢查。（CVE-2026-45932）

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

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

  - power： supply： sbs-battery： 修正 power_supply_changed（） 中的釋放後使用 'devm_' 變體來請求 IRQ _before_ 用於配置/註冊 'power_supply' 句柄的 'devm_' 變體，意味著 'power_supply' 句柄將在中斷處理常式之前 _ 解除配置/取消註冊（因為 'devm_' 自然地以相反的分配順序解除分配）。這表示在移除期間，會發生爭用情形，即中斷可能會在 'power_supply' 控制碼被釋放之後觸發，*但是* 就在 IRQ 處理常式的對應取消註冊執行之前。這將導致 IRQ 處理常式呼叫具有釋放的 'power_supply' 句柄的 'power_supply_changed（）'。這通常會使系統崩潰或以其他方式無聲地損壞記憶體... 請注意，在「probe（）」期間也可能發生類似的情況;在註冊 'power_supply' 控制碼之前_中斷觸發的可能性。這將導致在「power_supply_changed（）」中使用「power_supply」句柄*未初始化*的惡劣情況。透過確保在註冊 'power_supply' 控制碼之後 _ 請求 IRQ，來修正此 racy 釋放後使用。保留舊的行為，即在 IRQ 要求期間發生任何故障並成功完成探測時列印警告。（CVE-2026-45916）

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

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

  - 已解決 Linux 核心中的下列弱點：md/md-llbitmap: raise barrier before state machine transition Move the barrier raise operation before calling llbitmap_state_machine() in both llbitmap_start_write() and llbitmap_start_discard(). This ensures the barrier is in place before any state transitions occur, preventing potential race conditions where the state machine could complete before the barrier is properly raised. (CVE-2026-46095)

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

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

  - net： mctp：確保我們的 nlmsg 回應已初始化 Zellic 的 Syed Faraz Abrar （@farazsth98） 和與 Trend Micro Zero Day Initiative 合作的 DEVCORE 研究團隊的 Pumpkin （@u1f383） 報告說，RTM_GETNEIGH 將在 ndmsg 資料的 pad 位元組中傳回未初始化的資料。確保我們將 link、addr 和 neigh 回應訊息中的網路連結資料初始化為零。（CVE-2026-45930）

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

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

  - FastNetMon Community Edition through 不會 1.2.9 驗證出埠 HTTPS 連線上的 TLS 憑證。
    src/fast_library.cpp 中的 execute_web_request_secure（） 函式會建立具有 tls_client 模式的 boost：：asio：：ssl：：context，並呼叫 set_default_verify_paths（） 以載入CA憑證，但絕不呼叫 set_verify_mode（boost：：asio：：ssl：：verify_peer）。如果沒有此呼叫，OpenSSL 會在不驗證伺服器憑證鏈的情況下執行 TLS 交握，使所有 HTTPS 連線都容易受到中間人攻擊。此功能用於向 community-stats.fastnetmon.com 進行遙測報告， 會傳送系統資訊，包括 CPU 型號、核心版本、流量統計資料和軟體配置。攻擊者可以攔截和修改這些資料，或將其重新導向到惡意伺服器。
    (CVE-2026-48697)

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

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

  - rxrpc： 修正 rxkad_verify_response（） 中的記憶體洩漏 修正 rxkad_verify_response（） 以釋放票證和伺服器金鑰，方法是將票證指標初始化為 NULL，然後在完成第一次分配後使通過函數的所有路徑都經過一個共同尾聲，該尾聲只會釋放所有內容 - 其中所有版本都跳過 NULL 指標。（CVE-2026-46012）

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

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

  - apparmor：修正 aa_sock_file_perm 中的 NULL 襪子 處理在通訊端設定或拆卸期間 sock 和 sock-sk 可能為 NULL 的可能性。這可能會導致哎呀。中 NULL 指標解除參照的修正
    __unix_needs_revalidation表明這至少對於af_unix通訊端來說是可能的。雖然af_unix通訊端的修正程式適用於較新的調解，但這仍然是較舊af_unix調解及其他通訊端的後援路徑，因此請確定已涵蓋它。（CVE-2026-45848）

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

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

  - netfilter：拒絕 nft_bitwise 中的零移位 在初始化期間拒絕nft_bitwise左右移位運算式的零移位運算元。進位傳播邏輯使用 BITS_PER_TYPE（u32） - 移位計算相鄰 32 位字的進位。零移位運算元將其轉換為 32 位移位，這是未定義的行為。拒絕控制平面中的零移位運算元，以及對大於或等於 32 的值進行現有檢查，因此格式錯誤的規則永遠不會到達封包路徑。（CVE-2026-46101）

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

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

  - ntfs3：將緩衝區邊界檢查新增至 run_unpack（） run_unpack（） 檢查 while 迴圈頂端的「run_buf < run_last」，然後透過 run_unpack_s64（） 讀取 size_size 和 offset_size 位元組，而不驗證它們是否適合剩餘緩衝區。在 MFT 屬性中具有截斷執行資料的特製 NTFS 映像檔會在掛載檔案系統時觸發最多 15 位元組的 OOB 堆積讀取。在每次 run_unpack_s64（） 呼叫之前新增邊界檢查，以確保宣告的欄位大小不會超過剩餘的緩衝區。透過使用原始碼修補的工具 （LibAFL + QEMU） 進行模糊測試找到。（CVE-2026-46072）

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

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

  - wifi： rtw88：如果裝置位於根匯流排上，檢查 PCI 上游橋接器是否存在 pci_upstream_bridge（） 會傳回 NULL。如果 8821CE 安裝在具有這類 PCI 拓蹼的系統中，探查常式將會當機。這可能沒有被注意到，因為 8821CE 主要在筆記本電腦中提供，其中設備上游有一個 PCI 到 PCI 橋接器。但是，該卡可能安裝在具有不同配置的系統上。檢查橋接器是否存在，以便套用特定的因應措施。由 Linux 驗證中心 （linuxtesting.org） 使用 Svace 靜態分析工具找到。（CVE-2026-46092）

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

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

  - crypto：atmel-aes - 修正 atmel_aes_buff_cleanup atmel_aes_buff_init（） 中的 3 頁記憶體洩漏：使用 __get_free_pages（） 和 ATMEL_AES_BUFFER_ORDER 分配 4 個頁面，但 atmel_aes_buff_cleanup（） 僅使用 free_page（） 釋放第一頁，從而洩露剩餘的 3 個頁面。搭配 ATMEL_AES_BUFFER_ORDER 使用 free_pages（） 來修正記憶體洩漏。（CVE-2026-46019）

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

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

  - inotify：修正 fsnotify_add_inode_mark_locked（） 失敗時的監視計數洩漏 當 inotify_new_watch（） 中的 fsnotify_add_inode_mark_locked（） 失敗時，錯誤路徑會呼叫 inotify_remove_from_idr（），但不會呼叫 dec_inotify_watches（） 來復原前面的 inc_inotify_watches（）。這會洩漏監控計數，即使沒有監控處於作用中狀態，重複失敗也可能會耗盡 -ENOSPC 的max_user_watches限制。在提交 1cce1eea0aff （inotify： 轉換為使用每個名稱空間限制） 之前，fsnotify_add_mark_locked（） 成功後會遞增監視計數，因此此路徑不會受到影響。轉換在標記插入之前移動了 inc_inotify_watches（），但沒有新增對應的復原。在錯誤路徑中新增缺少的 dec_inotify_watches（） 呼叫。
    (CVE-2026-46040)

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

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

  - IO：：Compress 之前2.220的 2.207 Perl 版本會附帶一個 zipdetails CLI 工具，該工具會在具有 8 位元組 UID 或 GID 的 Info-ZIP Unix 額外欄位上因未定義的子常式而崩潰。當 bin/zipdetails 中的 decode_ux（） 處理 UID 大小或 GID 大小設定為 8 的 Info-ZIP Unix 額外欄位 （標籤 0x7875） 時，導致 zipdetails 解碼 8 位元組的 UID 或 GID 值，它會透過 decodeLitteEndian（） 分派，這會呼叫命名錯誤的協助程式 unpackValueQ。在同一檔中定義的實際函數是unpackValue_Q的（帶有底線）;呼叫會引發「Undefined subroutine &main：：unpackValueQ」，且指令碼會結束，狀態為 255。IO：：Compress 和 IO：：Uncompress 的程式庫呼叫端不受影響;缺陷存在於隨附的 CLI 工具中。（CVE-2026-48961）

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

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

  - Perl 的 HTTP::Daemon 6.17 之前版本允許透過 send_file() 插入作業系統命令。send_file() 使用 Perl 的 2-arg open() 開啟其字串引數。2-arg 形式解釋 magic 前置詞：'|cmd' 和 'cmd |' 會開啟通往子處理程序的管道，'> path' 和 '>> path' 則會開啟寫入或附加的路徑。傳遞給 send_file() 的不受信任輸入可以在程序處理程序 UID 上執行作業系統命令。讀取管道表單 ('cmd |') 也會將子程序 stdout 洩漏到 HTTP 回應內文中。寫入模式表單可以在攻擊者選擇的路徑上建立或截斷檔案。(CVE-2026-8450)

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

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

  - IO：：Uncompress：：Unzip 之前的版本 2.215 Perl剖析具有格式錯誤的 DOS 日期的 zip 標頭時，會傳播未捕獲的異常。 _dosToUnixTime（） 解碼 local-file-header last-modification date 欄位，並在沒有評估保護的情況下呼叫 Time：：Local：：timelocal（）。其日期欄位解碼為超出範圍的月、日或小時的標頭會導致 timelocal（） 終止。例外狀況會傳播出 IO：：Uncompress：：Unzip->new（$file），其中呼叫端預期 undef 加上 $UnzipError。（CVE-2025-15649）

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

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

  - 在之前和1.32.x之前1.34.x1.34.4的 MediaWiki 1.31.10 中，Special：UserRights 暴露了隱藏用戶的存在。（CVE-2020-25813）

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

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

  - IO：：Compress 之前 2.220 的版本 Perl 可以透過攻擊者控制的輸出 glob 在 File：：GlobMapper 中執行任意程式碼。 _parseOutputGlob（） 將呼叫端提供的輸出 glob 字串包裝在雙引號中，並將其儲存在剖析器狀態;_getFiles（） 然後透過 eval STRING 執行儲存的運算式。
    輸出 glob 中的文字雙引號會關閉 dquote 包裝函式，後面的字元會評估為 Perl。輸出 glob 中的任意 Perl 會以呼叫處理程序的權限執行。
    (CVE-2026-48962)

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

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

  - Perl 之前 2.220 的 IO：：Uncompress：：Unzip 版本允許透過 fastForward 中的每位元組讀取迴圈耗盡 CPU。 fastForward（） 將長度 $offset （偏移的位數，1 到 19）與區塊大小 $c 而不是 $offset 本身進行比較，因此 $c 每次迭代從 16 KiB 縮小到 1-19 位元組。透過 IO：：Uncompress：：Unzip->new（$zip， Name => $target） 從攻擊者提供的 zip 擷取具名項目，會驅動每位元組讀取迴圈與項目的壓縮大小縮放，最高可達非 Zip64 4 GiB 上限。
    (CVE-2026-48959)

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

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

  - Symfony：Polyfill 反向移植 PHP 功能，並為擴充功能和功能提供相容層。
    From 1.17.1 until 1.38.1， symfony/polyfill-intl-idn 接受 xn-- Punycode 負載為空的標籤或解碼為僅 ASCII 字碼點，因為 Idn：:p rocess（） 不會強制執行 UTS #46 修訂版 33 的要求，即解碼的 ACE 標籤至少包含一個非 ASCII 字碼點。原本不相等的網域名稱可以被視為相等，這可能會導致使用 polyfill 來規範或比較主機名稱的應用程式中繞過黑名單、URL 解析不一致以及伺服器端請求偽造。1.38.1 版已修正此問題。(CVE-2026-46644)

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

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

  - net/sched： taprio：修正類別轉儲中的 NULL 指標解除參照 透過 RTM_DELQDISC 刪除 TAPRIO 子 qdisc 時，會以 new == NULL 呼叫 taprio_graft（），並將 NULL 儲存到 q->qdiscs[cl - 1] 中。後續的RTM_GETTCLASS轉儲作業會透過 taprio_walk（） 遍歷所有類別並呼叫 taprio_dump_class（），這會呼叫傳回 NULL 指標的 taprio_leaf（），然後將其取消參照以讀取 child->handle，從而導致核心 NULL 指標解除參照。在任何啟用了 CONFIG_NET_SCH_TAPRIO 的核心上，使用命名空間範圍的CAP_NET_ADMIN都可以解決此錯誤。在已啟用無特權使用者名稱空間的系統上，無特權本端使用者可藉由在新網路名稱空間內建立 taprio qdisc、嫁接明確子 qdisc、刪除它，以及要求類別傾出，以觸發核心錯誤。RTM_GETTCLASS傾印本身不需要任何功能。哎呀：一般保護故障，可能用於非規範位址 0xdffffc0000000007：0000 [#1] SMP KASAN NOPTI KASAN：null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP：
    0010：taprio_dump_class （net/sched/sch_taprio.c：2478） 呼叫追蹤： <TASK> tc_fill_tclass （net/sched/sch_api.c：1966） qdisc_class_dump （net/sched/sch_api.c：2326） taprio_walk （net/sched/sch_taprio.c：2514） tc_dump_tclass_qdisc （net/sched/sch_api.c：2352） tc_dump_tclass_root （net/sched/sch_api.c：2370） tc_dump_tclass （net/sched/sch_api.c：2431） rtnl_dumpit （net/core/rtnetlink.c：6864） netlink_dump （net/netlink/af_netlink.c：2325） rtnetlink_rcv_msg （net/core/rtnetlink.c：6959） netlink_rcv_skb （net/netlink/af_netlink.c：2550） </TASK> 透過在 taprio_graft（） 中替換 &noop_qdisc 來修正此問題，這是其他 qdisc （例如 multiq_graft（）） 常用的模式，以確保 q->qdiscs[] 插槽永遠不會為 NULL。這可讓控制平面傾印路徑安全無虞，而不需要個別 NULL 檢查。由於資料平面路徑 （taprio_enqueue 和 taprio_dequeue_from_txq） 先前具有明確的 NULL 防護，可清除掉落/略過封包，因此請更新這些檢查以測試 &noop_qdisc。如果沒有這個，封包將到達 taprio_enqueue_one（），這會在呼叫子項的入隊之前遞增根 qdisc 的 qlen 和 backlog;noop_qdisc丟棄封包，但這些計數器永遠不會復原，從而永久誇大根 qdisc 的統計資料。在此變更之後，*old 可以是有效的 qdisc、NULL 或 &noop_qdisc。僅在第一種情況下調用 qdisc_put（*old），以避免減少 noop_qdisc 的參照計數，該計數從未增加。
    (CVE-2026-45845)

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

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

  - openvswitch：上限 upcall PID 陣列大小和預先大小 vport 回覆 vport netlink 回覆協助程式會使用 nlmsg_new（NLMSG_DEFAULT_SIZE， ...） 配置固定大小的 skb，但會透過 ovs_vport_get_upcall_portids（） 序列化完整的 upcall PID 陣列。由於 ovs_vport_set_upcall_portids（） 接受任何沒有上限的 sizeof（u32） 的非零倍數，因此CAP_NET_ADMIN使用者可以安裝足夠大的 PID 陣列，以使回覆緩衝區溢位，導致 nla_put（） 以 -EMSGSIZE 失敗並命中 BUG_ON（錯誤< 0）。在啟用了非特權使用者命名空間的系統上 （例如，Ubuntu預設），這可以透過 unshare -Urn 實現，因為 OVS vport 突變作業使用 GENL_UNS_ADMIN_PERM。net/openvswitch/datapath.c：2414 的核心錯誤！哎呀：
    無效操作碼：0000 [#1] SMP KASAN NOPTI CPU：1 UID：0 PID：65 通訊：poc 未受污染 7.0.0-rc7-00195-geb216e422044 #1 RIP：0010：ovs_vport_cmd_set+0x34c/0x400 呼叫追蹤： <TASK> genl_family_rcv_msg_doit （net/netlink/genetlink.c：1116） genl_rcv_msg （net/netlink/genetlink.c：1194） netlink_rcv_skb （net/netlink/af_netlink.c：2550） genl_rcv （net/netlink/genetlink.c：1219） netlink_unicast （net/netlink/af_netlink.c：1344） netlink_sendmsg （net/netlink/af_netlink.c：1894） __sys_sendto （net/socket.c：2206） __x64_sys_sendto （net/socket.c：2209） do_syscall_64 （arch/x86/entry/syscall_64.c：63） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：130） </TASK> 核心錯誤 - 未同步： 致命異常 拒絕嘗試在 ovs_vport_set_upcall_portids（） 中設定多於 nr_cpu_ids 的 PID，並根據該界限預先計算 ovs_vport_cmd_msg_size（） 中最壞情況下的回覆大小， 與現有的 ovs_dp_cmd_msg_size（） 類似。nr_cpu_ids符合資料路徑端每個 CPU 分派組態已使用的上限 （ovs_dp_cmd_fill_info（） 序列化最多 nr_cpu_ids 個 PID），因此兩端保持一致。（CVE-2026-45840）

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

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

  - bpf：修正 fork arena_vm_open（） 上 arena_vm_close 中的釋放後使用只會使 vml->mmap_count 增加，但絕不會在 arena->vma_list 中註冊子 VMA。vml->vma 一律指向父 VMA，因此在父 munmap 之後，指標會懸空。如果子項隨後呼叫 bpf_arena_free_pages（），則 zap_pages（） 會讀取過時的 vml->vma，觸發釋放後使用。透過防止競技場 VMA 透過 VM_DONTCOPY 跨分支繼承，並透過 may_split 回呼防止 VMA 分割來修正此問題。也使用傳回 -EINVAL 的 .mremap 回呼來拒絕 mremap。整個競技場上相同大小的 mremap（MREMAP_FIXED） VMA 透過以下路徑到達 copy_vma（）： check_prep_vma（） - 提前傳回 0：new_len == old_len跳過VM_DONTEXPAND檢查 prep_move_vma（） - vm_start == old_addr 和 vm_end == old_addr + old_len因此永遠不會呼叫 may_split move_vma（） copy_vma_and_data（） copy_vma（） vm_area_dup（） - 複製vm_private_data （VML 指標） vm_ops->open（） - 凸起 vml->mmap_countvm_ops->mremap（） - 傳回 -EINVAL，復原取消對應新的 VMA 參照計數可確保復原的arena_vm_close不會釋放與原始 VMA 共用的 VML。
    (CVE-2026-45837)

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

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

  - slip：bound decode（） 針對壓縮的封包長度進行讀取 slhc_uncompress（） 透過 decode（） 和 pull16（） 將指標推進封包，從而剖析 VJ 壓縮的 TCP 標頭。兩個協助程式都不會對 isize 進行邊界檢查，並且 decode（） 會用 & 0xffff遮罩其傳回，因此它永遠不會傳回呼叫者測試的 -1 -- 這些錯誤路徑是死代碼。一個簡短的壓縮框架，其更改位元組請求可選字段，允許 decode（） 讀取資料包末尾。過度讀取的位元組會摺疊到快取的 cstate 中，並反映到後續重建的封包中。使 decode（） 和 pull16（） 獲取數據包結束指標並在用盡時返回 -1。在讀取 TCP 總和檢查碼之前新增邊界檢查。現有的 == -1 測試現在可以執行它們一直想要做的事情。（CVE-2026-45843）

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

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

  - bpf：拒絕 bpf_core_parse_spec（） 中的負 CO-RE 存取子索引 CO-RE 存取子字串是冒號分隔的索引，描述從根 BTF 類型到目標欄位的路徑，例如 0：1：2 遍歷巢狀結構成員。bpf_core_parse_spec（） 會使用 sscanf（%d） 剖析每個元件，因此會以無訊息方式接受 -1 等負值。後續邊界檢查 （access_idx >= btf_vlen（t）） 只會保護上限，且一律傳遞負值，因為 C 整數提升會將__u16 btf_vlen結果轉換成 int，使得任何正 N 的比較 （int）（-1） >= （int）（N） 為假。當 -1 到達 btf_member_bit_offset（） 時，它會轉換為 u32 0xffffffff，從而產生遠遠超出成員陣列的越界讀取。在 vmlinux BTF 中存在的任何結構上具有負 CO-RE 存取子的特製 BPF 程式 （例如 task_struct） 會在任何具有 CONFIG_DEBUG_INFO_BTF=y （主要發行版的預設值） 上的任何系統上，在BPF_PROG_LOAD期間確定性地當機核心。此錯誤可透過 CAP_BPF： 錯誤：無法處理位址的頁面錯誤：ffffed11818b6626 #PF：核心模式下的主管讀取存取權 #PF：
    error_code（0x0000） - 不存在頁面 哎呀：哎呀：0000 [#1] SMP KASAN NOPTI CPU：0 UID：0 PID：85 Comm：
    poc 未受污染 7.0.0-rc6 #18 搶佔（完整） RIP：0010：bpf_core_parse_spec （tools/lib/bpf/relo_core.c：354） RAX：00000000ffffffff 呼叫追蹤： <TASK> bpf_core_calc_relo_insn （tools/lib/bpf/relo_core.c：1321） bpf_core_apply （kernel/bpf/btf.c：9507） check_core_relo （kernel/bpf/verifier.c：19475） bpf_check （kernel/bpf/verifier.c：26031） bpf_prog_load （kernel/bpf/syscall.c：3089） __sys_bpf （kernel/bpf/syscall.c：6228） </TASK> CO-RE 存取子索引本質上是非負的 （結構成員索引、陣列元素索引或列舉值索引） ，因此在剖析之後立即拒絕它們。
    (CVE-2026-45839)

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

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

  - bpf：修正 cgroup_storage_get_next_key（） 中的清單結尾偵測 list_next_entry（） 從不傳回 NULL -- 當目前元素是最後一個項目時，它會透過 container_of（） 包裝到清單頭。因此，後續的 NULL 檢查是死代碼，並且 get_next_key（） 永遠不會返回最後一個元素的 -ENOENT，而是從為內部映射欄位別名的虛假指標中讀取 storage->key 並將結果複製到使用者空間。將其替換為 list_entry_is_head（），以便在沒有更多條目時函數正確傳回 -ENOENT。（CVE-2026-45838）

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

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

  - bareudp：修正 bareudp_fill_metadata_dst（） 中的 NULL 指標解除參照 bareudp_fill_metadata_dst（） 將 bareudp->sock 傳遞給 IPv6 路徑中的 udp_tunnel6_dst_lookup（），而無需 NULL 檢查。通訊端僅在 bareudp_open（） 中建立，並在 bareudp_stop（） 中為 NULL，因此在裝置關閉時呼叫此函式會透過 sock->sk 觸發 NULL 取消參照。錯誤：核心 NULL 指標解除參照，位址：0000000000000018 RIP：0010：udp_tunnel6_dst_lookup （net/ipv6/ip6_udp_tunnel.c：160） 呼叫追蹤： <TASK> bareudp_fill_metadata_dst （drivers/net/bareudp.c：532） do_execute_actions （net/openvswitch/actions.c：901） ovs_execute_actions （net/openvswitch/actions.c：1589） ovs_packet_cmd_execute （net/openvswitch/datapath.c：700） genl_family_rcv_msg_doit （net/netlink/genetlink.c：1114） genl_rcv_msg （net/netlink/genetlink.c：1209） netlink_rcv_skb（net/netlink/af_netlink.c：2550） </TASK> 新增傳回 -ESHUTDOWN 的 NULL 檢查，與相同驅動程式中的 xmit 路徑一致。（CVE-2026-45846）

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

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

  - netfilter： arp_tables：修正 IEEE1394 ARP 負載剖析 石未明說：arp_packet_match（） 會無條件地剖析 ARP 負載，假設存在兩個硬體位址 （來源和目標）。
    不過，IPv4-over-IEEE1394 ARP （RFC 2734） 會省略目標硬體位址欄位，而 arp_hdr_len（） 已透過傳回較短的裝置長度來說明這一點ARPHRD_IEEE1394。因此，在介面上 IEEE1394 ，arp_packet_match（） 會越過不存在的目標硬體位址，並讀取目標裝置位址比較和目標 IP 位址的錯誤位元組。這會導致 arptables 規則與垃圾資料相符，從而導致不正確的過濾決策：應該接受的封包可能會被丟棄，反之亦然。net/ipv4/arp.c （arp_create 和 arp_process） 中的 ARP 堆疊已透過跳過目標硬體位址來正確處理此問題ARPHRD_IEEE1394。將相同的模式套用至 arp_packet_match（）。破壞原始修補程式，以一律傳回 0 （不相符），以防使用者在目標硬體位址上相符，而 中從未存在 IEEE1394。請注意，這會傳回 0 （不相符） 用於正常比對和反向比對，因為 arptables 從未支援 ARPHRD_IEEE1394 中目標硬體位址的比對。這是有意為之，目標硬體位址上的比對不應針對ARPHRD_IEEE1394評估為 true。此外，按照 AI 的建議調整arpt_mangle以丟棄封包：在 arpt_mangle 中，邏輯採用標準 ARP 佈局。由於 （FireWire） 省略了目標硬體位址，因此 IEEE1394 線性指標算術會錯誤計算目標 IP 位址的位移。這會導致修改作業寫入錯誤的位置，進而導致封包損毀。為確保安全，此修補程式會在要求對裝置上的 IEEE1394 這些欄位進行修改時丟棄封包 （NF_DROP），因為目前的實作無法正確對應 FireWire ARP 承載。
    這會同時省略錯誤目標硬體和 IP 位址。即使 中應該可以 IEEE1394修改 IP 位址，這也需要調整偏移計算，而這從未受到支援arpt_mangle。
    基於 Weiming Shi <bestswngs@gmail.com>的補丁。（CVE-2026-45844）

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

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

  - netfilter： nfnetlink_osf：修正 OSF_WSS_MODULO nf_osf_match_one（） 中的除以零問題，計算 OSF_WSS_MODULO 分支中的 ctx->window % f->wss.val，而沒有對 f->wss.val == 0 的保護。CAP_NET_ADMIN使用者可以透過 nfnetlink 新增此類指紋;後續相符的 TCP SYN 除以零並使核心發生錯誤。
    拒絕 per-option for 迴圈上方的 nfnl_osf_add_callback（） 中的虛假指紋。f->wss 是每個指紋，而不是每個選項，因此無論 f->opt_num （包括 0） 如何，都必須執行檢查。也拒絕 wss.wc >= OSF_WSS_MAX;nf_osf_match_one（） 已經將這種情況視為不應該發生。當機：哎呀：除法錯誤：0000 [#1] SMP KASAN NOPTI RIP：0010：nf_osf_match_one （net/netfilter/nfnetlink_osf.c：98） 呼叫追蹤：
    <IRQ> nf_osf_match （net/netfilter/nfnetlink_osf.c：220） xt_osf_match_packet （net/netfilter/xt_osf.c：32） ipt_do_table （net/ipv4/netfilter/ip_tables.c：348） nf_hook_slow （net/netfilter/core.c：622） ip_local_deliver （net/ipv4/ip_input.c：265） ip_rcv （include/linux/skbuff.h：1162） __netif_receive_skb_one_core （net/core/dev.c：6181） process_backlog （net/core/dev.c：6642） __napi_poll （net/core/dev.c：7710） net_rx_action （net/core/dev.c：7945）handle_softirqs （kernel/softirq.c：622） （CVE-2026-45841）

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

ID	名稱	嚴重性
317151	Linux Distros 未修補的弱點：CVE-2026-45985	medium
317150	Linux Distros 未修補弱點：CVE-2026-46082	medium
317149	Linux Distros 未修補弱點：CVE-2026-45983	medium
317148	Linux Distros 未修補的弱點：CVE-2026-46038	medium
317147	Linux Distros 未修補弱點：CVE-2026-45944	high
317146	Linux Distros 未修補弱點：CVE-2026-46084	high
317145	Linux Distros 未修補的弱點：CVE-2026-46024	high
317144	Linux Distros 未修補弱點：CVE-2026-45859	high
317143	Linux Distros 未修補弱點：CVE-2026-48692	high
317142	Linux Distros 未修補弱點：CVE-2026-46022	high
317141	Linux Distros 未修補弱點：CVE-2026-46009	medium
317140	Linux Distros 未修補弱點：CVE-2026-46080	medium
317139	Linux Distros 未修補的弱點：CVE-2026-46003	medium
317138	Linux Distros 未修補的弱點：CVE-2026-46026	medium
317137	Linux Distros 未修補的弱點：CVE-2026-45997	medium
317136	Linux Distros 未修補的弱點：CVE-2026-48694	high
317135	Linux Distros 未修補的弱點：CVE-2026-46059	medium
317134	Linux Distros 未修補弱點：CVE-2026-46028	medium
317133	Linux Distros 未修補弱點：CVE-2026-45904	medium
317132	Linux Distros 未修補弱點：CVE-2026-46070	high
317131	Linux Distros 未修補的弱點：CVE-2026-48684	medium
317130	Linux Distros 未修補弱點：CVE-2026-45871	medium
317129	Linux Distros 未修補弱點：CVE-2026-45932	high
317128	Linux Distros 未修補的弱點：CVE-2026-45916	high
317127	Linux Distros 未修補弱點：CVE-2026-46095	medium
317126	Linux Distros 未修補弱點：CVE-2026-45930	medium
317125	Linux Distros 未修補的弱點：CVE-2026-48697	high
317124	Linux Distros 未修補的弱點：CVE-2026-46012	medium
317123	Linux Distros 未修補弱點：CVE-2026-45848	medium
317122	Linux Distros 未修補的弱點：CVE-2026-46101	medium
317121	Linux Distros 未修補弱點：CVE-2026-46072	medium
317120	Linux Distros 未修補弱點：CVE-2026-46092	medium
317119	Linux Distros 未修補弱點：CVE-2026-46019	medium
317118	Linux Distros 未修補弱點：CVE-2026-46040	medium
317091	Linux Distros 未修補的弱點：CVE-2026-48961	high
317090	Linux Distros 未修補弱點：CVE-2026-8450	high
317089	Linux Distros 未修補的弱點：CVE-2025-15649	medium
317088	Linux Distros 未修補的弱點：CVE-2020-25813	medium
317087	Linux Distros 未修補的弱點：CVE-2026-48962	high
317086	Linux Distros 未修補的弱點：CVE-2026-48959	high
317085	Linux Distros 未修補弱點：CVE-2026-46644	medium
317081	Linux Distros 未修補的弱點：CVE-2026-45845	medium
317080	Linux Distros 未修補的弱點：CVE-2026-45840	medium
317079	Linux Distros 未修補弱點：CVE-2026-45837	high
317078	Linux Distros 未修補弱點：CVE-2026-45843	high
317077	Linux Distros 未修補弱點：CVE-2026-45839	high
317076	Linux Distros 未修補的弱點：CVE-2026-45838	medium
317075	Linux Distros 未修補的弱點：CVE-2026-45846	medium
317074	Linux Distros 未修補的弱點：CVE-2026-45844	medium
317073	Linux Distros 未修補的弱點：CVE-2026-45841	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

high

high

high

high

high

high

medium

medium

medium

medium

medium

high

medium

medium

medium

high

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium

high

high

medium

medium

medium

high

high

high

medium

medium

medium

medium