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

  - sched_ext：將SCX_RQ_BAL_KEEP替換為分派判定傳回，SCX_RQ_BAL_KEEP告訴揀貨繼續執行上一個任務，這是平衡和揀選是單獨作業時的遺留物。rq 層級旗標僅在分派和揀貨配對一對一時有效，核心排程會中斷：
    選取項目會透過 dispatch 的 lock drops 交錯，而選擇可能會耗用過時旗標，保留已出佇的任務。修復核心排程支援需要決定與進行調度的調度一起旅行。改為讓 scx_dispatch_sched（） 和 balance_one（） 傳回明確的判定，並從工具 autogen 列舉標頭中刪除旗標的管道。也要考慮取貨端叫用、其後續佇列，以及從 do_pick_task_scx（） 到 dispatch_pick（） 的分派後簽出。無意進行功能變更。v2：也從工具 autogen 列舉標頭中刪除SCX_RQ_BAL_KEEP管道 （Andrea）。（CVE-2026-89519）

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

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

  - NFS：修正 nfs4_server_common_setup（） 失敗時的delegation_hash_table洩露 nfs4_server_common_setup（） 首先配置 server->delegation_hash_table，但 server->destroy - 通過 nfs4_destroy_server（） 釋放表的唯一路徑 - 直到函數的最後才被分配。如果任何中間步驟失敗 （is_ds_only_client（） 檢查、nfs4_init_session（）、nfs4_get_rootfh（） 或 nfs_probe_server（）），則函式會傳回 server->destroy 仍為 NULL，因此呼叫端的 nfs_free_server（） 會跳過 destroy 回呼，且雜湊表會洩漏 （每次嘗試 4 KiB，具有預設委派浮水印）。這可從使用者空間輕鬆實現：每個失敗的 NFSv4 掛載都會洩漏一個分配。持續重試無法成功的掛載的用戶端會無限制地洩漏核心記憶體。在生產環境中觀察到，Longhorn 備份輪詢器每秒大約針對僅限 NFSv3 的伺服器重試 mount.nfs4 10 次，每天洩漏 ~3.4 GiB 的無法回收的 slab （kmalloc-rnd-13-4k）; 在透過 kmem：kmalloc 追蹤點識別來源之前，節點累積了 12 GiB 的洩漏 slab （call_site=nfs4_delegation_hash_alloc）。Reproducer： # 伺服器僅匯出 NFSv3 （或 v4 缺少匯出路徑），而 ：;do mount -t nfs4 <server>：/missing /mnt; done # 觀察 /proc/meminfo 中的 SUnreclaim 每次反覆運算增長 4 KiB 釋放有關 server->destroy 分配和分配之間錯誤路徑的表格。（CVE-2026-89714）

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

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

  - misc： nsm：綁定裝置報告的回應長度 nsm_sendrecv_msg_locked（） 將 NSM 裝置報告的 virtqueue used-ring 長度儲存到 msg->resp.len 中，而不將其綁定到回應緩衝區。惡意或有錯誤的後端可能會報告大於回應緩衝區的長度;然後，parse_resp_raw（） 會將固定緩衝區中這麼多位元組複製到使用者空間，以揭露相鄰的核心堆積 （越界讀取）。請求路徑已在 fill_req_raw（） 中限制其長度;回應路徑缺少對稱檢查。將儲存的長度限制為回應緩衝區的大小。行為良好的裝置報告的緩衝區大小不超過張貼的緩衝區大小，因此符合規範的流量不受影響。（CVE-2026-89743）

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

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

  - net： openvswitch：修正流刪除時的流遮罩釋放後使用 下面 Fixes 標籤中的提交，以便在從流程表中移除流遮罩後立即通過 RCU 安排流>遮罩釋放。指標停留在流程結構中，並且可以在相同的 RCU 關鍵區段中存取它。這樣做是為了避免要求對 ovs_flow_free（） 進行ovs_mutex。然而，在處理CMD_DEL過程中刪除流時，我們不會在刪除之前進行 RCU 讀取鎖定，並且 ovs_flow_cmd_fill_info（） 之後使用 flow->mask 指標。RCU 讀取鎖定已取得，但此時已經很晚了。該行的評論承認鎖是裝飾性的，沒有真正的用途。如果 RCU 寬限期在移除和填充之間經過，則會導致釋放後使用。這是一個很短的爭用視窗，但它確實存在，如果資訊的記憶體分配需要更長的時間，可能會導致真正的當機： 錯誤：KASAN：__ovs_nla_put_key net/openvswitch/flow_netlink.c：1996 中的 slab-use-after-free 錯誤：KASAN：ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c：2250 在 addr ffff88801ee89970 處讀取大小 4 由任務 ovs_flow_del_ec/9487 呼叫追蹤： <TASK> __ovs_nla_put_key net/openvswitch/flow_netlink.c：1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c：2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c：930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c：1467 ...
    netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c：2556 </TASK> 由任務 9487 分配： mask_alloc net/openvswitch/flow_table.c：967 flow_mask_insert net/openvswitch/flow_table.c：1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c：1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c：1086 ...netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c：2556 由任務 9485 釋放： rcu_free_sheaf+0x1e/0x100 mm/slub.c：5978 rcu_do_batch kernel/rcu/tree.c：2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c：2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c：622 ...
    instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c：1062 ovs_flow_tbl_remove（） 必須在 ovs_flow_cmd_fill_info（） 之後呼叫，以避免此爭用。這也有助於清理強制投射和外觀 RCU 讀取鎖定。在 Fixes 標籤中提交之前，只要流程物件本身未釋放，順序就無關緊要。更廣泛的 RCU 關鍵部分可能是另一種選擇，但我們有一個GFP_KERNEL的分配。趨勢科技零時差計畫報告為 ZDI-CAN-32042。
    (CVE-2026-80994)

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

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

  - nfsd：依xpt_locallen fh_verify伺服器 sockaddr 插槽大小 nfsd_fh_verify 及 nfsd_fh_verify_err 追蹤點會宣告依 xpt_remotelen 大小的伺服器 sockaddr 插槽，但會使用 xpt_locallen 從xpt_local填入它： TP_STRUCT__entry（ ... __sockaddr（server， rqstp->rq_xprt->xpt_remotelen） ... ）TP_fast_assign（ ... __assign_sockaddr（伺服器， &rqstp->rq_xprt->xpt_local， rqstp->rq_xprt->xpt_locallen）;
    ... )當xpt_locallen超過 xpt_remotelen時，__assign_sockaddr 的 memcpy 寫入會超過保留的環形緩衝區插槽。在相反方向 （xpt_locallen < xpt_remotelen） 中，插槽過大，未寫入的尾部會洩漏先前的環形緩衝區內容以追蹤消費者。在 NFS/UDP 上可連線寫入結束情況。svc_xprt_set_remote（） 僅從 svc_tcp_accept（） （net/sunrpc/svcsock.c） 和 RDMA 連接路徑呼叫;svc_create_socket（） 用於 UDP 僅調用 svc_xprt_set_local（），因此xpt_remotelen在 xprt 的存留期內保持 0。然後，NFSv2/v3-over-UDP 要求的每個 fh_verify 追蹤都會將 16 或 28 位元組從 xpt_local 複製到零位元組插槽中。記錄伺服器位址的其他 NFSD 追蹤點 （NFSD_TRACE_PROC_CALL_FIELDS、NFSD_TRACE_PROC_RES_FIELDS、SVC_RQST_ENDPOINT_FIELDS） 已依 xpt_locallen 調整伺服器插槽大小;nfsd_fh_verify和nfsd_fh_verify_err是唯一的例外。透過使用 xpt_locallen 調整伺服器插槽的大小來修正，使宣告的插槽符合副本長度。用戶端插槽及其指派已就xpt_remotelen達成一致，且保持不變。（CVE-2026-89702）

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

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

  - wifi：mt76：mt7925：取消擱置的mlo_pm_work 如果裝置在該窗口內重設、暫停或取消註冊，擱置的工作仍然可以運行並存取可能已經釋放的 vif/bss 數據，或在韌體不可用時發送 MCU 命令。在所有相關的拆卸和暫停路徑中新增 cancel_delayed_work_sync（&dev->mlo_pm_work）： - mt7925_mac_reset_work（） （晶片重設復原） - mt7925e_unregister_device（） （PCIe 解除綁定） - mt7925_pci_suspend（） （PCIe 匯流排暫停） - mt7925_suspend（） （mac80211 暫停） - mt7925u_suspend（） （USB 匯流排/執行階段暫停） 這可確保在裝置狀態失效之前停止工作。（CVE-2026-89523）

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

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

  - nfsd：修正 nfsd_direct_write nfsd_direct_write（） 中的部分寫入偵測 遍歷寫入區段清單，並在每個 vfs_iocb_iter_write（） 之後嘗試偵測短寫入，以便在將下一個區段放置在錯誤的檔案偏移量之前停止迴圈：host_err = vfs_iocb_iter_write（file， kiocb， &segments[i].iter）;
    if （host_err < 0） 傳回 host_err;*cnt += host_err;if （host_err < segments[i].iter.count） 中斷;/* 部分寫入 */ vfs_iocb_iter_write（） 透過 ->write_iter（） 運行 iter，這會將 iter 推進寫入的位元組數。當檢查執行時，segments[i].iter.count 是殘差，而不是原始要求長度： write_iter 之前： iter.count == original_len write_iter之後： iter.count == original_len - host_err 然後條件會減少為 host_err < original_len - host_err，因此只有在寫入區段少於一半時才會觸發中斷。任何完成區段 50% 到 99% 之間的短寫入都會溜走;迴圈會前進到下一個區段，而 kiocb->ki_pos 只會增加少量，以錯誤的位移寫入下一個區段的有效負載，並向 NFS 用戶端多報 *cnt。在寫入之前對區段的位元組計數進行快照，並將host_err與該快照進行比較，以便任何短寫入都會中斷迴圈。(CVE-2026-89678)

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

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

  - 金鑰：受信任：修正 TPM 拆卸排序 trusted_tpm_exit（） 會刪除 TPM 晶片參照並釋放摘要陣列，然後再取消註冊受信任的金鑰類型。key_type_lookup（） 保留 key_types_sem 以供讀取，直到金鑰操作完成，而 unregister_key_type（） 則將其用於寫入。因此，它提供後端拆卸之前必須的同步點。目前的順序允許這種交錯：
    CPU 0 CPU 1 trusted_tpm_exit（） key_type_lookup（信任） put_device（&chip->dev） trusted_tpm_seal（） kfree（digests） pcrlock（） unregister_key_type（） tpm_pcr_extend（...， digests） CPU 1 可以因此取消參照釋放的摘要陣列。晶片也可以在回呼停止使用之前釋放。KASAN 報告： 錯誤：KASAN：在 tpm_pcr_extend+0x1f0/0x200 中釋放後使用 slab-use-after-free by task poc/89 在 addr ffff88810872d000 讀取大小 2 呼叫追蹤：tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [信任] trusted_tpm_seal+0x1b6/0x570 [信任] trusted_instantiate+0x293/0x340 [信任]
    __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 由任務 88 分配：__kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 由任務 90 釋放：kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [受信任]
    __do_sys_delete_module+0x346/0x510 在釋放任一資源之前移動 unregister_key_type（）。這會停止新的查詢，並等待正在進行的金鑰作業完成，然後再破壞後端狀態。
    (CVE-2026-89763)

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

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

  - iommu：修正 iommu_mock_device_add iommu_mock_device_add（） 首次調用 iommu_fwspec_init（） 中 device_add 失敗時dev_iommu記憶體洩漏，成功時會配置 dev->iommu （透過 dev_iommu_get（）） 和 dev->iommu->fwspec。如果後續的 device_add（dev） 呼叫失敗，錯誤路徑只會呼叫 iommu_fwspec_free（dev），這會釋放 fwspec，但仍會配置 dev->iommu。當使用 Syzkaller 進行模糊測試時，這會觸發以下 kmemleak 報告： 錯誤：記憶體洩漏未參照的物件0xffff888011e0a200（大小 192）：comm syz.1.1695、pid 24885、jiffies 4295222527十六進位轉儲（前 32 個位元組）：
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 AD 4e ad de .............N..ff ff ff ff 00 00 00 00 ff ................回溯 （crc 25df5bb3）：kmemleak_alloc_recursive include/linux/kmemleak.h：44 [內聯] slab_post_alloc_hook mm/slub.c：4575 [內聯] slab_alloc_node mm/slub.c：4899 [內聯]
    __kmalloc_cache_noprof+0x47a/0x710 mm/slub.c：5415 kmalloc_noprof include/linux/slab.h：950 [內聯] kzalloc_noprof include/linux/slab.h：1188 [內聯] dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c：408 iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c：3087 iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c：385 mock_dev_create drivers/iommu/iommufd/selftest.c：1025 [內聯] iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c：1066 [內聯] iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c：2072 iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c：533 vfs_ioctl fs/ioctl.c：51 [inline] __do_sys_ioctl fs/ioctl.c：597 [inline] __se_sys_ioctl fs/ioctl.c：583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c：583 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 修正這是透過在 device_add（） 失敗路徑中呼叫 dev_iommu_free（dev） 而不是 iommu_fwspec_free（dev） 來實現的。
    dev_iommu_free（） 會釋放 fwspec 和外部 dev_iommu 結構，並清除 dev->iommu。（CVE-2026-89449）

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

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

  - mm， swap：不要釋放交換快取中的休眠插槽 交換快取中具有對開本的插槽會在對開本離開快取時釋放，而不是在其計數下降時釋放。swap_put_entries_cluster（） 遵循該規則。swap_free_hibernation_slot（） 不會，它會呼叫 __swap_cluster_free_entries（），無論對開本是否位於插槽上。叢集預讀可以在那裡放置一個。它會在錯誤項目周圍遍歷原始page_cluster大小的偏移窗口，並且休眠槽會通過 __swap_cache_add_check（），因為它不是對開本，其計數不是零。然後釋放插槽會清除該對開本下的項目。現在無法從交換表存取對開本，而且偏移會回到配置器。不過，對開本仍在 LRU 上，因此回收可以稍後取回它。然後，它從對開本>交換中取出舊的偏移量並覆蓋那裡的表格條目，屆時該表條目可能屬於其他人。此錯誤可能會在完全不相關的使用者空間應用程式中觸發無訊息記憶體損毀、進程當機或資料不穩定 - 通常發生在 uswsusp 準備休眠映像檔時。我在嘗試在交換表中為休眠槽提供自己的標記時發現了這一點，我曾與 Kairui 討論過。
    （https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/） 據我所知，沒有報告，因此沒有報告者/關閉者可添加。釋放前檢查是否有已快取的對開本。然後，插槽會保持只有交換快取保留的正常狀態，並在對開本離開快取時釋放插槽，無論是透過下面的回收還是稍後的正常回收。（CVE-2026-89760）

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

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

  - power： supply： twl4030_charger：透過 devm 取消背景工作角色 BCI 是 devm 配置的。兩個工作角色 （bci->work 和 bci->current_worker） 取消參照它。twl4030_bci_remove（） 會停用充電並遮罩中斷。它不會取消任何工作者。在 devm 釋放 bci 之後，可以在 remove（） 處擱置的工作程式執行。USB 收發器來自 devm_usb_get_phy_by_node（）。devm 只有在 remove（） 傳回後才會取消註冊其通知程式。然後，remove（） 中的 cancel_work_sync（） 可以爭用通知程式重新排程。devm_work_autocancel（） 和 devm_delayed_work_autocancel（） 可以避免這種情況。他們在 devm 發布期間取消工作角色，在釋放 bci 之前。current_worker會先註冊，因為 devm 會以相反的順序取消，而 bci->work 可以重新排程current_worker。[將有關順序的註解移至提交訊息中]（CVE-2026-89464）

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

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

  - svcrdma： 在重建之前驗證讀取區塊位置 RPC/RDMA 讀取區塊位置欄位由遠端用戶端提供，並逐字儲存在剖析的區塊清單中。xdr_count_read_segments（） 僅檢查 4 位元組對齊方式;它從不將位置與接收到的內嵌主體長度進行比較。在單一區塊路徑中，svc_rdma_read_complete_one（） 會在ch_position處分割頭部和尾部 kvecs。超過內聯主體的位置會溢出尾部長度，將相鄰的平板記憶體暴露給上部 XDR 解碼器。在多區塊路徑中，svc_rdma_read_multiple_chunks（） 將區塊之間的間隙長度計算為ch_position的無符號減法。重疊的讀取區塊會導致這些減法反向溢位。經過內聯主體的最終位置同樣會下溢於尾隨間隙長度。
    然後，svc_rdma_copy_inline_range（） 會複製到透過回覆通道傳回給用戶端的要求頁面中。將 svc_rdma_copy_inline_range（） 中的內嵌範圍副本綁定到儲存在 rc_saved_arg 中的解碼內嵌RPC內文。拒絕位於該主體之外的單一讀取區塊，並拒絕累積讀取位元組超過下一個區塊位置的多區塊清單。在呼叫區塊交錯路徑中套用相同的位置和重疊檢查。（CVE-2026-89526）

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

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

  - wifi：mt76：mt7915：在 EFUSE 複製 mt7915_mcu_get_eeprom（） 將固定的 EFUSE 區塊複製到驅動程式的 dev->mt76.eeprom.data 緩衝區之前，在 MCU 回應 （res->addr，裝置控制的__le32） 所報告的位移量之前，繫結裝置 EEPROM 位址，而不針對緩衝區大小進行檢查。惡意或故障裝置可報告任意位址，並驅動 16 位元組越界寫入 eeprom.data。拒絕其位址會在衍生目的地指標之前將複本放在 eeprom.data 外部的回應。回應所要求的輸入偏移的裝置不會受到影響。（CVE-2026-80937）

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

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

  - svcrdma：在解碼時拒絕過大的讀取區段 RPC/RDMA 讀取清單解碼器儲存有線提供的區段長度，而不經過驗證。xdr_count_read_segments（） 會檢查 4 位元組對齊方式是否有非零位置值，但不會限制區段長度。過大的rs_length會到達 svc_rdma_build_read_segment（），（） 會從中衍生出nr_bvec，並可在驗證是否剩餘足夠的 rq_pages之前驅動大型動態 bvec 配置。如果觸發配置後頁面溢位防護，則不會傳回新取得的 rw 內容，進而洩漏資源。在讀取清單解碼期間，拒絕任何長度超過接收內容頁面預算的區段，這與 xdr_check_write_chunk（） 邊界寫入區段計入rc_maxpages的方式一致。此外，在 svc_rdma_build_read_segment（） 中現有的配置後溢位路徑上傳回 rw 內容，以保持防禦防護的平衡。
    (CVE-2026-89529)

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

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

  - nfsd：修正配置柵欄工作程序雙重參照爭用 工作佇列核心會在叫用回呼之前清除WORK_STRUCT_PENDING，因此 lm_breaker_timedout（） 中的 delayed_work_pending（） 可以在柵欄工作程序已執行時傳回 false。這可讓中斷器取得重複的sc_count參考，並排程與進行中工作合併的新工作者。永遠不會放置額外的引用，從而洩露佈局 stateid。將 racy delayed_work_pending（） 檢查替換為在 ls_lock 下以 refcount_inc_not_zero（） 原子方式設定的 ls_fence_inflight 布林值，並在處置路徑上的最後一個 nfs4_put_stid（） 之前在 ls_lock 下清除;重試路徑會刻意保留它。移除工作器頂端的自行重新武裝 mod_delayed_work（）。（CVE-2026-89681）

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

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

  - 互連：修正 icc_get（） 和 of_icc_get_by_index（） 中的釋放後使用 在 of_icc_get_by_index（） 和 icc_get（） 中，如果透過 kasprintf（） 對 path->name 的動態分配失敗，錯誤處理路徑會直接呼叫 kfree（path） 釋放路徑物件並傳回錯誤。然而，在此之前，path_find（） 呼叫 path_init（），它已經透過 hlist_add_head（） 將路徑的請求連結到各個互連節點的req_list中。直接叫用 kfree（path） 會在 hlist 中留下懸空的指標。後續調用 icc_get（） 或 icc_set_bw（） 將遍歷或修改這些損毀的清單，觸發 slab use afterfree。KASAN 報告顯示透過 debugfs 重現時的弱點： 錯誤：
    KASAN：slab-use-after-free in path_find+0x6f8/0xcfc 任務 sh/1 在 addr fff000000d43f748 寫入大小 8 ... 通話追蹤：kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... 由工作 1 釋放：kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 透過將 kfree（path） 替換為適當的拆卸函式 icc_put（path） 來解決此問題，該函式會使用 hlist_del（） 安全地從req_list中移除要求，並在釋放記憶體之前刪除提供者使用參考。
    此外，在 icc_get（） 中，請確保在呼叫 icc_put（path） 之前釋放icc_lock互斥以避免鎖死，因為 icc_put（） 在內部取得相同的鎖。（CVE-2026-81008）

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

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

  - nfsd：修正 nfsd4_setattr 中用於委派時間戳記 attrs 的空取消參照 當 SETATTR 要求在屬性點陣圖中包含 FATTR4_WORD2_TIME_DELEG_ACCESS 或 FATTR4_WORD2_TIME_DELEG_MODIFY 時，nfsd4_setattr（） 會設定 deleg_attrs=true 並呼叫 nfs4_preprocess_stateid_op（） 來驗證 stateid。如果用戶端提供 NFSv4 一個 stateid （全0xFF位元組），則 check_special_stateids（） 會傳回 nfs_ok，而不填入輸出nfs4_stid指標，因為 nfs4_preprocess_stateid_op（） 中的 special-stateid 路徑會跳至 done： with s==NULL，且會跳過會設定 *cstid 的 if （s） 區塊。本機變數「st」維持為 NULL。回到 nfsd4_setattr（） 中，if （deleg_attrs） 區塊會無條件地解除參照 st->sc_type（在 NULL 的偏移量 4 處），導致核心 oops。這可由任何 NFSv4 用戶端遠端觸發：發送 COMPOUND [PUTROOTFH， SETATTR（ONE_STATEID， {bmval2=FATTR4_WORD2_TIME_DELEG_ACCESS， ...}）]。不需要驗證、委派或先前狀態。透過在取消參照之前新增 NULL 檢查來修正。
    特殊的 stateid 不是委派 stateid，因此現有的 nfserr_bad_stateid 傳回值已經正確;我們只需要保護指標解除參照本身。（CVE-2026-89679）

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

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

  - 他的： omap_ssi_core：修正 SSI 控制器裝置缺少的 DMA 遮罩設定 OMAP SSI 驅動程式使用透過 hsi_alloc_controller（） 分配的合成 HSI 控制器裝置，該裝置不經過正常的 OF/平台裝置初始化路徑。因此，預設內嵌結構裝置沒有初始化 DMA 遮罩。在最近的 DMA API 強化變更之後，dma_map_sg（） 和相關協助程式現在需要存在有效的dma_mask，否則驅動程式可能會在嘗試 DMA 對應作業時當機或觸發警告。藉由明確初始化 SSI 控制器裝置的 DMA 遮罩，並設定符合硬體功能的 32 位 DMA 遮罩，以修正此問題。（CVE-2026-89594）

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

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

  - platform/x86： hp-bioscfg：修正 sk_store（） 和 kek_store（） 中的堆積 OOB 讀取 sk_store（） 和 kek_store（） 在配置金鑰緩衝區之前，從 sysfs 寫入中剝離尾端換行符：長度 = 計數;if （buf[length - 1] == '\n'） length--; bioscfg_drv.spm_data.signing_key = kmemdup（buf， length， GFP_KERNEL）; 但隨後將原始計數 （不是長度） 作為副本大小傳遞給 hp_wmi_perform_query（），這會從長度大小的分配中讀取那麼多位元組，每當寫入以換行符結束時，就會讀取一個位元組，這是 shell echo 到 sysfs 的正常情況。KASAN 直接確認了這一點： 錯誤：KASAN：hp_wmi_perform_query+0x1e9/0x460 中的 slab-out-of-bounds [hp_bioscfg] 任務 python3/16022 在 addr ffff88813c8e2b80 讀取大小 28 ...sk_store+0xa7/0x240 [hp_bioscfg] kernfs_fop_write_iter+0x3e1/0x5d0 ... 有錯誤的位址位於分配的 27 位元組區域內的 0 位元組 [ffff88813c8e2b80， ffff88813c8e2b9b） 以相同的方式重現 kek_store，並且以多種寫入大小（28、57、201 位元組），每次讀取的 kmemdup（） 分配恰好是一個位元組，比寫入小一個位元組。透過在這兩個函式中向 hp_wmi_perform_query（） 傳遞長度而不是計數來修復。（CVE-2026-81014）

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

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

  - svcrdma：ADDR_CHANGE替換失敗時清除sc_cm_id 當 svc_rdma_listen_handler（） 處理RDMA_CM_EVENT_ADDR_CHANGE時，它會建立一個替換接聽程式cm_id並傳回 1，告訴 CM 核心銷毀舊的接聽程式。如果取代配置失敗，sc_cm_id仍會指向 CM 核心即將銷毀的舊cm_id。任何後續的 sc_cm_id 解除參照 （例如 svc_rdma_detach（） 的 rdma_disconnect（） 呼叫 — 都是釋放後使用。NULL sc_cm_id故障路徑上，並保護 svc_rdma_detach（） 的 rdma_disconnect（） 呼叫免受 NULL 的影響，以便在伺服器關閉時可以安全地拆除接聽程式。（CVE-2026-89534）

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

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

  - ceph：在 NFS 匯出 get_name ceph_get_name（） 中綁定複製的 dentry 名稱長度會使用 memcpy（name， rinfo->dname， rinfo->dname_len） 將 MDS 提供的名稱複製到呼叫端的 NAME_MAX 大小緩衝區中，然後寫入 name[rinfo->dname_len] = 0，而不檢查dname_len NAME_MAX。傳回帶有 dname_len > NAME_MAX 的 LOOKUPNAME 回覆的惡意或有錯誤的 MDS 會使緩衝區溢位。__get_snap_name（） 以相同的未檢查方式複製 rde->name / rde->name_len。影響：惡意或已入侵的 Ceph MDS 使用戶端 NFS 匯出get_name路徑中的 NAME_MAX 名稱緩衝區溢位，這是 KASAN 報告的 Slab 越界寫入。透過 NFS 重新匯出 CephFS 掛載時可連線。新增 ceph_export_copy_name（），在複製之前使用 -ENAMETOOLONG 拒絕超過 NAME_MAX 的長度，並在 ceph_get_name（） 和
    __get_snap_name（）。（CVE-2026-89652）

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

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

  - net/smc：在佇列項目 smc_llc_rmt_delete_rkey（） 和 smc_llc_save_add_link_rkeys（） 中攜帶過大的 SMC-Rv2 LLC 訊息，讀取 v2 訊息中不適合 44 位元組聯合smc_llc_msg的部分，並且兩者都受其著陸的緩衝區大小的約束，而不是由到達的內容約束。在具有共用 v2 接收緩衝區的連結上，宣告 255 個 rkey 的 44 位元組DELETE_RKEY_V2在 lgr->wr_rx_buf_v2 中留下的任何先前訊息中都會到達 rkey[9..254]，並將每個 rkey 傳遞給 smc_rtoken_delete（）。這 255 個中的一個與已註冊的 rtoken 匹配並將其刪除。這類連結上的ADD_LINK會從相同的位元組安裝最多 255 個 rtoken。將尾部複製到佇列項目中，使其長度是到達訊息的長度，並將內嵌的 rkey 宣告為聯集的成員，而不是透過轉換到達它們。現在，同一DELETE_RKEY_V2處理它攜帶的 9 個 rkey。副本僅限於兩個函式可以讀取的最長尾部，因此對等不會挑選項目的大小。不再需要先前修補程式放置在沒有共用 v2 接收緩衝區的連結上的繫結。
    (CVE-2026-80985)

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

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

  - nfsd：在釋放複合 arg 時清除 opcnt 以防止 OOB 讀取 nfsd4_release_compoundargs（） 在釋放動態配置的 ops 緩衝區時，將 args->ops 重設為內嵌 iops[8] 陣列，但將 args->opcnt 保留為原始值 （NFSv4.1+ 化合物最多可為 200）。如果 rq_status_counter 停留在奇數值（當 nfsd_dispatch（） 在將其設定為奇數後到達錯誤路徑時，可能會發生這種情況），則RPC狀態轉儲處理常式會從 args->ops[] 讀取 min（opcnt， 16） 條目。由於 iops 只有 8 個元素，並且是結構 nfsd4_compoundargs 中的最後一個字段，因此讀取索引 8-15 會存取相鄰的 slab 記憶體，並透過網路連結將其洩漏到使用者空間。在 nfsd4_release_compoundargs（） 中無條件地零 opcnt，因此永遠不會透過狀態介面公開過時的複合中繼資料。[ cel：從曝光視窗中移除 kvfree_rcu_mightsleep（） 睡眠 ]（CVE-2026-89691）

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

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

  - 當 tarfile 在不支援連結的系統上擷取連結時，它會回復為從封存中擷取成員。在此情況下，篩選函式會執行兩次：一次針對擷取的成員，另一次將名稱設定為連結的位置。針對其中一個呼叫，傳回值會被忽略。相反地，如果任一呼叫傳回 None，則應該略過成員。（CVE-2026-87910）

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

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

  - nfsd：拒絕 NFSv3 SETATTR 中超出範圍的 nseconds 並建立操作 用戶端可以傳送 NFSv3 SETATTR、CREATE、MKDIR、SYMLINK 或 MKNOD，其中包含 nseconds 欄位超出範圍的 atime 或 mtime。該值在網路上格式正確，並且可以乾淨地解碼為有效的 uint32，但它不是有效的 timespec64：
    tv_nsec必須小於NSEC_PER_SEC。setattr 路徑中沒有任何內容限制它。notify_change（） 通過 timestamp_truncate（） 運行時間，當文件系統支持納秒粒度 （s_time_gran == 1） 時，它不會將tv_nsec減少到 NSEC_PER_SEC 以下，並且 inode atime/mtime setter 逐字存儲它（只有 ctime 通過 inode_set_ctime_to_ts（））進行標準化）。然後，未正規化的值會損毀磁碟上的中繼資料：ext4 的 ext4_encode_extra_time（） tv_nsec EXT4_EPOCH_BITS左移位，這會溢出 32 位元額外欄位並破壞秒元位元，因此儲存的秒數（以及年份）在回讀時是錯誤的。出於同樣的原因，帶有 bigtime 的 XFS 錯誤儲存了時間戳記。在 proc 處理常式中驗證用戶端提供的 atime/mtime，並在變更任何內容之前傳回 NFS3ERR_INVAL。RFC 1813 列出了 SETATTR 的NFS3ERR_INVAL，並將其描述為伺服器「無法儲存...在它自己的代表中“;用戶端會將其對應至 EINVAL。簽入 proc 處理常式，而不是在 nfsd_setattr（） 中簽入，會將拒絕保留在物件建立之前。建立作業會在 nfsd_create_setattr（） 執行之前建立物件，因此延遲失敗會留下新物件，並將非冪等要求變成報告失敗的命名空間變更。因此，在建立物件之前，會針對建立作業預先完成檢查。tv_nsec 是一個長，因此比較將其轉換為無符號長（相同寬度）而不是 u32，與 timespec64_valid（） 匹配。u32 轉換會在 64 位元上截斷;未帶正負號的長轉換也會拒絕當超出範圍的 u32 線 n秒 被指派給 32 位長時變成負數的值。僅檢查用戶端提供的時間：SET_TO_SERVER_TIME要求不帶有用戶端值。sattrguard3 ctime 被故意保留：超出範圍的保護根本永遠不會匹配對象的 ctime，並通過現有的 guardtime 比較產生NFS3ERR_NOT_SYNC，這是協議正確的結果，而不是拒絕請求。（CVE-2026-89666）

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

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

  - bpf：在 __bpf_get_stack get_perf_callchain（） 中停用搶佔會傳回每個 CPU 的 perf_callchain_entry 緩衝區，並在返回之前透過 put_callchain_entry（） 釋放其遞迴插槽，因此當 __bpf_get_stack（） 在下方耗用該條目時，沒有任何內容會保留該條目。可以在取得項目和副本之間安排搶佔式 BPF 程式（例如，PREEMPT 核心上的不可休眠原始追蹤點程式，該程式在 migrate_disable（） 下運行，而不是在 preempt_disable（）） 下運行）。然後，在相同 CPU 上排程的另一個工作會重複使用相同的每個 CPU 緩衝區，並以較大的值覆寫 trace->nr。然後從膨脹的 trace->nr 計算copy_len，並且可能會超過調用方的緩衝區，從而導致 memcpy（） 和 build_id 路徑中越界寫入。僅此處採用的 rcu_read_lock（） 並不能阻止這一點。它僅在may_fault路徑上進行，在CONFIG_PREEMPT_RCU下不會停用搶佔;它只是使 perf 的呼叫鏈緩衝區陣列保持活動狀態（透過 call_rcu（））釋放），並且不會阻止另一個任務重複使用該條目。停用取得呼叫鏈專案並將它複製到呼叫端緩衝區的先佔，因此無法在我們下方重複使用專案，且 trace->nr 仍受 max_depth 限制。
    組建識別碼解析可能會出錯，因此會延遲到重新啟用搶佔之後;此時指令指標已複製到 BUF 中，因此它只會在該私有副本上運作。請注意，preempt_disable（） 也包含 rcu_read_lock（） 提供的緩衝區存留期保證，因為搶佔停用區段是呼叫鏈緩衝區 call_rcu（） 回收的 RCU 讀取端關鍵區段。[ 已變更 修正：提交 ]（CVE-2026-89580）

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

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

  - PCI/sysfs：修正 pci_write_legacy_io（） 中的越界讀取 pci_write_legacy_io（） 會從 kernfs 寫入緩衝區載入 4 個位元組，無論使用者空間寫入多少位元組： if （count ！= 1 &&; count ！= 2 &&; count ！= 4） return -EINVAL;return pci_legacy_write（bus， off， *（u32 *）buf， count）;kernfs_fop_write_iter（） 會使用 kmalloc（len + 1） 配置緩衝區，因此對 legacy_io sysfs 檔案的 1 位元組寫入會配置 2 個位元組，而無條件的 u32 載入會在配置結束後讀取最多 2 個位元組，KASAN 會將其報告為 slab-out-of-bounds 讀取。同樣地，2 位元組的寫入會過度讀取 1 個位元組。因此，針對 2 和 4 位元組情況，僅讀取使用 get_unaligned_le16（） 和 get_unaligned_le32（） 請求的位元組數，將緩衝區解釋為小端，以符合 PCI I/O 連接埠空間的位元組順序。PowerPC 實作先前會針對 1 和 2 位元組案例將值移至適當的位置，以補償泛型程式碼的原生端 32 位元負載。這些移位僅在大端核心上是正確的。在 little-endian PowerPC （POWER8 及更新版本） 上，他們擷取了錯誤的位元組，因此 1 位元組寫入會寫入越界位元組，而不是要求的值。在 big-endian 上，本機負載也會導致 out_le16（） 和 out_le32（） 反轉使用者在網路上的位元組，以進行 2 和 4 位元組寫入。little-endian 協助程式解決了這兩個問題，因此移除了班次。Alpha 平台不需要任何變更。legacy_io 檔案是僅限 root 檔案，且僅存在於 Alpha 和 PowerPC 上，這是定義 HAVE_PCI_LEGACY 的兩種架構。（CVE-2026-89722）

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

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

  - power： supply： MAX17040： 暫停時同步工作取消 max17040_work（） 會在每次輪詢之後重新排入佇列。cancel_delayed_work（） 只會取消擱置中的執行個體，不會等待已執行的回呼。如果系統暫停與輪詢回呼爭用，回呼可以繼續存取電量計，並在暫停回呼傳回後重新排隊。使用 cancel_delayed_work_sync（） 確保輪詢在暫停完成之前靜止。（CVE-2026-89461）

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

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

  - 調節器： as3722_get_regulator_dt_data：修正過早of_node_put留下懸空of_node指標 在 as3722_get_regulator_dt_data（） 中，of_get_child_by_name（） 取得 np 上的參照，然後將其指派給 pdev->dev.of_node。函式會立即呼叫 of_node_put（np），釋放參照，並將 pdev->dev.of_node 保留為懸空指標。移除 of_node_put（np） 呼叫，讓裝置保留參照。（CVE-2026-89504）

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

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

  - nfsd：在失敗的委派撤回佇列上清除CALLBACK_RUNNING nfsd_break_one_deleg（） 透過 test_and_set_bit at entry 設定NFSD4_CALLBACK_RUNNING序列化撤回工作，然後呼叫 nfsd4_run_cb（） 將撤回排入佇列。當佇列嘗試失敗時，參照計數凸起會復原，但 RUNNING 位仍會保留設定。唯一清除位元的站點是 nfsd41_destroy_cb（） （fs/nfsd/nfs4callback.c），它從工作佇列執行，因此當沒有任何內容排入佇列時，無法連線。該位成為 dp->dl_recall.cb_flags 上的永久鎖存：同一委派上的每個後續 break_lease（） 都會命中 nfsd_break_one_deleg（） 中的提前返回防護並默默地跳過召回，因此委派永遠不會中斷，並且衝突的開啟或鎖定停止。透過清除 ！queued 分支上的 NFSD4_CALLBACK_RUNNING 與refcount_dec一起修正。CVE-2026-89692

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

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

  - jackson-databind 透過將原始字串逐字傳遞給 CoreXMLDeserializers.Std._deserialize 中的 DatatypeFactory.newDuration（value） 或 newXMLGregorianCalendar（value），將 JSON 字串綁定到 javax.xml.datatype.Duration 或 javax.xml.datatype.XMLGregorianCalendar 欄位。這些還原序列化程式預設為註冊，無需選擇加入，因此沒有多態類型且沒有特殊設定的普通 ObjectMapper 或 JsonMapper 會到達此路徑。XML 結構描述詞彙文法允許任意長度的數值元件，JDK 會透過原生 BigInteger（String） 和 BigDecimal（String） 建構函式實現這些元件，這兩個建構函式的位數計數都是二次的。由於數字位於 JSON 字串權杖內，而不是 JSON 數字權杖中，因此 jackson-core 的 StreamReadConstraints.maxNumberLength 防護永遠不會套用;jackson 自己的 NumberDeserializers 會在剖析字串化數字之前呼叫 validateIntegerLength 或 validateFPLength，但 XML 資料類型還原序列化程式會省略該預先檢查。因此，未經身份驗證的攻擊者可以提交幾兆位元組的單一請求，例如由字母 P 後面接著數百萬位數字和字母 Y 組成的 Duration 值，並強制數十秒到幾分鐘的單執行緒 CPU 工作;少數並行要求可能會使伺服器的工作執行緒飽和。這會影響 com.fasterxml.jackson.core：jackson-databind from 2.0.0 before ， from 2.19.0 before 2.21.6和 2.22.22.22.0 from before ，以及 tools.jackson.core：jackson-databind 3.1.63.0.0 from before 和 3.2.0 from before3.2.2。2.18.10 使用者應升級至 2.18.10、 2.21.6、 2.22.23.1.6、 或 3.2.2。（CVE-2026-68497）

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

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

  - cifs：在 cifs_do_truncate（） 中使用 cifs_invalidate_cache（），因為 O_TRUNC cifs_do_truncate（） 是從 cifs_open（） 叫用而沒有i_rwsem，因此它無法使用 cifs_resize_file_locked（） 來執行適當的 fscache cookie 大小調整。相反，請在 cifs_setsize（） 之後新增 cifs_invalidate_cache（）。cifs_invalidate_cache（） 會呼叫 fscache_invalidate（），該 （） 無需保留 i_rwsem即可運作：它無條件地遞增 inval_counter 並設定 FSCACHE_COOKIE_NO_DATA_TO_READ，確保一旦 cookie 稍後被 fscache_use_cookie（） 啟動，就不會提供過時的快取資料。截斷為零不會留下任何有效的快取資料，因此無效是此處的正確語義。（CVE-2026-89639）

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

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

  - scsi： core：在 scsi_alloc_sgtables（） 中填寫 DMA 填充位元組在模糊測試期間，發現以下問題： 錯誤：KMSAN：__dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 中的 uninit-value
    __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340
    __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420
    __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit 是在以下位置建立的：__alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70
    __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 16 個位元組中的 14-15 個位元組未初始化 大小 16 的記憶體存取從 ffff88800cbdb000 開始 當處理散佈清單的最後一個未對齊元素時，會補充 pad_len 的遺漏位元組。這些位元組保持未初始化狀態，這會導致問題。先將 last_sg->length 擴充 pad_len，然後使用 sg_zero_buffer（） 將這些 pad_len 位元組歸零。
    sg_zero_buffer（） 在內部使用 sg_miter，它可以正確處理跨越多個頁面的 sg 項目和跨越頁面邊界的填充。由 Linux 驗證中心 （linuxtesting.org） 與 Syzkaller 一起找到。（CVE-2026-89515）

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

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

  - power： supply： qcom_battmgr：終止韌體的字串 當韌體傳送字串時，qcom_battmgr_sc8280xp_strcpy（） 會採用 Pascal 式字串。否則，它會複製所有BATTMGR_STRING_LEN位元組，並在沒有終止符的情況下離開目的地。這些目的地是 model_number、serial_number 和 oem_info，每個目的地都彼此相鄰BATTMGR_STRING_LEN和宣告。它們以 val->strval 的形式傳入使用者空間，power_supply_format_property（） 以 %s 列印，因此填充整個欄位的韌體字串會使讀取進入以下成員。使用 strscpy（），使副本始終終止，就像路徑已經針對同一欄位所做的那樣 SM8350 。（CVE-2026-89466）

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

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

  - i3c： master：修正裝置取消註冊路徑中的資訊洩露和 UAF i3c_master_unregister_i3c_devs（） 會在呼叫 device_unregister（） 之前清除 i3cdev->dev->desc。在 device_unregister（） 期間，device_del（） 會發出KOBJ_REMOVE uevent，並在裝置描述元仍預期有效時解除綁定驅動程式。因此，i3c_device_uevent（） 和爭用 modalias_show（） 可以觀察到 NULL desc 並回歸到未初始化的堆疊結構i3c_device_info，從而洩露生成的模態中的核心堆疊內容。
    驅動程式 .remove（） 回呼在解除綁定期間也可能遇到非預期的 NULL desc。在 device_unregister（） 完成之前，保持 desc 有效。由於 device_unregister（） 會刪除裝置參照並可能釋放裝置，因此在取消註冊之前，請使用 get_device（） 進行額外的參照。之後清除 desc 並使用 put_device（） 釋放額外的參照。這會保留 desc 必須為 NULL 的發行時間不變量，同時避免資訊洩漏，以及在裝置發行之後寫入 desc 的潛在釋放後使用。（CVE-2026-80952）

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

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

  - ALSA： portman2x4：在探測時檢查卡片索引有效性 雖然 portman2x4 驅動程式會檢查指定的 devptr->id 值，但它不會檢查負 ID，當透過 sysfs 繫結時，負 ID 通常會指定為 none 或此類值。這可能會導致 index[] 和其他參數的 OOB 存取。新增卡片索引的健全性檢查，並在值超出範圍時警告/更正。（CVE-2026-80966）

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

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

  - ceph：拒絕 mdsmap 解碼 MDSMap 中export_targets排名 >= CEPH_MAX_MDS export_targets項目由監控控制。check_new_map（） 使用每個項目作為固定堆疊點陣圖中的位數，因此協定命名空間之外的排名可以使 set_bit（） 寫入陣列結尾。在解碼地圖時拒絕CEPH_MAX_MDS之外的排名。不要針對此處的possible_max_rank進行驗證，因為地圖可能會合法地引用暫時減少的max_mds之外的排名。（CVE-2026-89653）

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

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

  - ata： libata-scsi：修正磁區大小大於 2048 位元組的 DSM TRIM ata_scsi_write_same_xlat（） 會將設定 UNMAP 位元的 SCSI WRITE SAME 命令轉換為 ATA DATA SET MANAGEMENT TRIM 命令。
    TRIM 描述項由 ata_format_dsm_trim_descr（） 建置到 2048 位元組的 ata_scsi_rbuf 暫存緩衝區中，並由調用方將複製的位元組數與邏輯磁區大小進行比較：size = ata_format_dsm_trim_descr（scmd， trmax， block， n_block）;if （size ！= len） /* len == sdp->sector_size */ 轉至 invalid_param_len;ata_format_dsm_trim_descr（） 將副本長度限制為 ATA_SCSI_RBUF_SIZE （2048）。
    在邏輯磁區大小超過該磁區大小的裝置 （例如 4Kn 裝置，其中 sector_size == 4096） 上，函式永遠不會傳回超過 2048，而呼叫端預期它會傳回 sector_size。因此，比較總是失敗，因此每次嘗試時，每個 TRIM 都會被拒絕，並出現參數清單長度錯誤和 WARN_ON（） splat。因此，TRIM/丟棄在此類設備上完全被破壞。根據邏輯磁區大小，描述元的大小不正確。DSM 修剪承載是 512 位元組頁面的清單，每個頁面最多可容納 ATA_MAX_TRIM_RNUM （64） 個 LBA 範圍項目，且與邏輯磁區大小無關。「區塊限制」VPD 頁面已將單一此類頁面通告為最大 WRITE SAME 長度 （65535 * ATA_MAX_TRIM_RNUM 邏輯區塊），因此區塊層永遠不會傳送需要多個頁面的要求。
    只發出一個 512 位元組的頁面，與邏輯磁區大小無關，並且只傳輸該頁面 （COUNT == 1）。對於 512 位元組磁區裝置，這不會改變;具有較大邏輯磁區的裝置現在可以工作，而不是每次 TRIM 都失敗。（CVE-2026-89586）

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

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

  - ocfs2：根據 refcount 區塊驗證器中的 rl_count 驗證 rl_used 驗證器 ocfs2_find_refcount_rec_in_rl（） 使用下列命令遍歷磁碟上的 refcount 記錄陣列： for （; i < le16_to_cpu（rb->rf_records.rl_used）; i++） { rec = &rb->rf_records.rl_recs[i]; ... rl_recs[] 位於單一中繼資料區塊 （通用配置為 4096 位元組） 中，因此其實際容量由 ocfs2_refcount_recs_per_rb（SB） 固定（具有 16 位元組ocfs2_refcount_rec的 4K 區塊為 247 筆記錄）。rl_used 和 rl_count 都由 ocfs2_validate_refcount_block（） 直接從磁碟中讀取，並且在任何 refcount/reflink/CoW 操作遍歷陣列之前，絕不會根據該容量或彼此進行檢查。具有 rl_used == 0xffff 的特製（或損毀）參照計數區塊會使上面的迴圈遠遠超過區塊的末尾，將 i 的 rl_recs[i] 取消引用，最高可達 65534。然後將產生的索引傳遞給同級 ocfs2_insert_refcount_rec（），其插入移位執行：if （index < le16_to_cpu（rf_list->rl_used）） memmove（&rf_list->rl_recs[index + 1]， &rf_list->rl_recs[index]， （le16_to_cpu（rf_list->rl_used） - index） * sizeof（struct ocfs2_refcount_rec））;
    即，最多 （0xffff - index） * 16 位元組 （~1 MiB） 的 memmove（） 距離已經超過區塊的偏移量。這可從針對特製/損毀的 ocfs2 影像的普通參照連結 （FICLONE） 來存取：附加範圍，其 cpos 排序經過葉中的每個實際記錄，會強制查詢從結尾執行，而不是在匹配時儘早返回。攻擊者模型是本地的：CAP_SYS_ADMIN掛載特製或損毀的 ocfs2 映像，或原始寫入支援已掛載的 ocfs2 檔案系統的區塊裝置。
    ocfs2_validate_refcount_block（） 已經驗證了區塊的 ECC、簽名、rf_blkno和rf_fs_generation，但從未根據區塊的實際磁碟容量進行rl_count/rl_used。這與 ocfs2_validate_extent_block（） （fs/ocfs2/alloc.c） 已經為同級範圍清單標頭縮小的間隙類別相同，該標頭在任何程式碼遍歷之前都會檢查記錄容量和已h_list界。：l_recs[] if （le16_to_cpu（eb->h_list.l_count） ！= ocfs2_extent_recs_per_eb（sb）） { rc = ocfs2_error（...）; goto bail; } if （le16_to_cpu（eb->h_list.l_next_free_rec） > le16_to_cpu（eb->h_list.l_count）） { rc =ocfs2_error（...）;戈托保釋;} 將對等效的檢查新增至 ocfs2_validate_refcount_block（）：拒絕rl_count與 ocfs2_refcount_recs_per_rb（） 傳回的固定每個區塊容量不符的 refcount 區塊，並拒絕rl_used > rl_count。設定 OCFS2_REFCOUNT_TREE_FL 時，會略過這兩項檢查，因為在這種情況下，相同的聯集位元組會保留 ocfs2_extent_list （rf_list），而不是參照計數記錄清單 （rf_records） -- 當讀取參考範圍區塊時，該配置已由 ocfs2_validate_extent_block（） 單獨驗證。這反映了現有的 ！（rb->rf_flags &; OCFS2_REFCOUNT_TREE_FL） 此檔案中其他地方使用的防護 （例如
    ocfs2_get_refcount_rec（）） 來決定 rf_records 或 rf_list 是聯盟的即時成員。有了這個，就會在區塊驗證時 （ocfs2_error（）） 捕獲偽造的 rl_used/rl_count，這與此函式中的所有其他損毀檢查一致，而不是驅動 ocfs2_find_refcount_rec_in_rl（） 中的越界讀取和 ocfs2_insert_refcount_rec（） 中的後續越界 memmove（）。
    根據 v6.19 KASAN （KASAN_GENERIC） 版本上的特製映像進行驗證：在此修補程式之前，重播相同的參照連結 （FICLONE） 可靠地命中了 __ocfs2_increase_refcount（）/ocfs2_insert_refcount_rec（） 中的 KASAN 報告，並且一旦 ocfs2_validate_refcount_block（） 拒絕偽造的 rl_used/rl_count，則不會觸發任何報告。（CVE-2026-89493）

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

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

  - lockd：將下一個檔案固定在 lock-drop nlm_inspect_file lock-drop nlm_traverse_files（） 會以 f_count++ 固定目前檔案，用於 nlm_inspect_file（） 的mutex_unlock，但沒有任何內容會固定已儲存的下一個指標。並行 nlm_release_file（） 可以在解鎖窗口期間釋放下一個文件，迭代器在下一個循環步驟中解除參照釋放的記憶體。在鎖定丟棄之前將當前和下一個都固定住。透過在每次迭代結束時交換固定的游標來前進，以便下一個游標在解鎖過程中始終保持活動狀態。一律在卸除反覆專案針腳之後呼叫 nlm_file_release（），不論檔案是否符合述詞。使用 nlm_file_inuse（），它會即時遍歷 inode 鎖定清單，而不是快取的 f_locks 欄位，以便正確評估從未執行 nlm_inspect_file（） 的跳過檔案。
    由於雜湊儲存桶中的每個檔案現在都已釘選並釋放，因此在遊走期間會刪除is_failover_file述詞跳過且沒有鎖定、區塊、共用或外部參照的檔案。舊程式碼從未評估跳過的檔案進行清理。新行為是有意為之：這類檔案已過時，不應保留在表格中。（CVE-2026-89485）

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

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

  - cxl/features：繫結至輸入緩衝區的 fwctl 命令承載 fwctl_cmd_rpc（） 會將 cmd->in_len 位元組複製到 inbuf = kvzalloc（cmd->in_len） 中，並將 inbuf 和 in_len 傳遞至 ->fw_rpc（）。CXL 回呼 cxlctl_fw_rpc（） 會忽略in_len，而且絕不會針對它檢查使用者控制的op_size。
    cxlctl_set_feature（） 僅從下方op_size邊界 （op_size <= sizeof（feat_in->hdr）），然後透過 cxl_set_feature（） 從 feat_in->feat_data 讀取 op_size - sizeof（hdr） 位元組。對於小in_len和大op_size，第一個 memcpy（） 已經讀取過 kvzalloc（in_len） 緩衝區;越界位元組被放置在郵箱承載中並發送到設備，足夠大的op_size可以進入未映射的內存並導致內核 oops。取得路徑op_size固定大小，但同樣地讀取輸入結構而不檢查in_len。在單一分派點，拒絕其固定標頭加上 op_size 不符合複製緩衝區的任何要求。下限測試保護減法並確保op_size在讀取之前被複製。（CVE-2026-89571）

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

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

  - NFSD：在使用 list_for_each_entry_safe（ni， tmp， ...） 捨棄 nfsd_ssc_lock nfsd4_ssc_expire_umount（） 遍歷 nn->nfsd_ssc_mount_list 之後，重新啟動ssc_expire_umount遍歷。對於每個過期的項目，它設定為 nsui_busy = true，刪除nfsd_ssc_lock以在來源 vfsmount 上執行 mntput（），然後重新取得鎖定以 list_del + kfree 項目，並透過巨集儲存的 tmp 指標繼續反覆運算。nsui_busy 標誌保護當前 ni 在鎖定放置窗口期間免受並發 nfsd4_ssc_setup_dul（） 查找器的影響，但它不會固定 tmp。另一個 nfsd RPC執行緒如果無法掛載來源伺服器並達到 nfsd4_ssc_cancel_dul（），將在同一視窗內接受 nfsd_ssc_lock，list_del + kfree 自己的ssc_umount項，然後釋放鎖定。如果該項目是到期遍歷的已儲存 tmp，則下一次反覆運算會解除參照已釋放的nfsd4_ssc_umount_item。在 mntput（） 解鎖視窗之後從頭部重新啟動遍歷，因此不會有已儲存的下一個指標在鎖定刪除後倖存下來。此清單以作用中伺服器間來源掛載的數目 （通常較小） 為界，且到期的延遲工作會定期執行，而不是每個 IO 執行，因此重新啟動的成本很低。（CVE-2026-89712）

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

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

  - nfsd：在nfsd4_drop_revoked_stid中為委派設定SC_STATUS_FREED nfsd4_drop_revoked_stid（） 會處理管理員撤銷委派的FREE_STATEID，但不會在發行委派之前設定SC_STATUS_FREED cl_lock。
    revoke_delegation（） 使用此標誌來檢測FREE_STATEID是否已經處理了委派 -- 如果沒有它，釋放的委派將通過 list_add（） 添加到cl_revoked中，當稍後在 __destroy_client（） 中遍歷 cl_revoked 時，會產生釋放後使用。nfsd4_free_stateid（） 中的SC_STATUS_REVOKED路徑（第 7983 行）已正確設定SC_STATUS_FREED。將相同的模式套用至 nfsd4_drop_revoked_stid（） 中的SC_STATUS_ADMIN_REVOKED路徑。（CVE-2026-89703）

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

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

  - nfsd：驗證 NFSv4 中的符號連結目標長度 CREATE nfsd4_decode_create（） 接受來自網路的 NF4LNK 符號連結目標的無限cr_datalen，允許用戶端強制每個 COMPOUND 操作的 kmalloc 最多達到最大 RPC 負載大小 （數 MiB），該容量會持續到複合拆卸為止。VFS 會拒絕具有 ENAMETOOLONG 的過大目標，但已進行分配。使用 nfserr_inval 提前拒絕 cr_datalen == 0，並cr_datalen大於 NFS4_MAXPATHLEN （PATH_MAX），並有 nfserr_nametoolong 來限制分配。（CVE-2026-89699）

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

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

  - clocksource/drivers/nxp-pit：修正錯誤路徑cpuhp_setup_state IRQ 洩漏 當 pit_clockevent_per_cpu_init 成功呼叫 request_irq 後 cpuhp_setup_state 失敗時，錯誤處理會直接跳轉至 out_pit_clocksource_unregister，而不會釋放已註冊的 IRQ。這會洩露 IRQ 行，並且由於 kfree（pit） 緊隨其後，會留下一個懸空指標註冊為中斷處理常式的dev_id，如果 IRQ 隨後觸發，可能會導致釋放後使用。透過呼叫 pit_clockevent_per_cpu_exit 來修正它，以便在落入現有清理鏈之前正確釋放 IRQ。（CVE-2026-89769）

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

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

  - fanotify：修正檔案範圍資訊的釋放後使用 fsnotify_pre_content（） 在觸發任務的堆疊上建立其file_range。fanotify_alloc_perm_event（） 會在堆積分配的權限事件中儲存指向 range.pos 的指標，以便 copy_range_info_to_user（） 稍後可以報告偏移。事件讀取器可以將事件狀態設定為FAN_EVENT_REPORTED，然後在準備檔案描述元時休眠。如果訊號在該點中斷觸發任務，fanotify_get_response（） 會將狀態變更為 FAN_EVENT_CANCELED 並返回。這會在讀者仍擁有事件時展開file_range堆疊框架。然後，閱讀器取消參照 pevent->ppos，並將過時的堆疊值複製到使用者空間。KASAN 報告： 錯誤：KASAN：fanotify_read+0x293e/0x2970 中的釋放後使用 任務 fanotify_inotif/95 在 addr ffff88811434fc50 讀取大小 8 呼叫追蹤：fanotify_read+0x293e/0x2970 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f 將範圍位置直接儲存在權限事件中，並在範圍資訊不可用時使用FANOTIFY_NO_RANGE。
    在閱讀器完成之前，事件會保持作用中，因此報告的偏移不再取決於觸發任務的堆疊。（CVE-2026-89600）

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

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

  - nouveau/gem：在 vma 查詢周圍的資訊 ioctl 中保留 bo 在非 uvmm 路徑中，資訊查詢找到 vma 與關閉 vma 的 gem 關閉路徑之間可能會發生爭用，導致釋放後使用。在 Opus 4.6的幫助下發現。（CVE-2026-89553）

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

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

  - nfsd：驗證TIME_DELEG解碼路徑中的 n秒 以 xdrgen 為基礎的 TIME_DELEG_ACCESS 和 TIME_DELEG_MODIFY 解碼臂會將原始uint32_t n秒直接儲存到 tv_nsec 中，而不會強制執行 n秒< NSEC_PER_SEC。舊版nfsd4_decode_nfstime4有此檢查，但TIME_DELEG路徑沒有。
    格式錯誤的時間規格可以透過 notify_change（） 傳播到磁碟。在 nfs4xdr.c （SETATTR 路徑） 和 nfs4callback.c （CB_GETATTR路徑） 中新增範圍檢查。（CVE-2026-89701）

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

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

  - SUNRPC：檢查 svc 集區 percpu 計數器配置 __svc_create（） 會初始化三個每個集區percpu_counter統計資料，並忽略每個傳回值。在 SMP 上，當 __alloc_percpu_gfp（） 無法滿足分配時，percpu_counter_init（） 就會失敗，導致失敗的計數器 fbc->counters == NULL，並且其內嵌的 raw_spinlock_t、list_head 和 count 從未初始化。無論如何，__svc_create（） 都會將半建構的svc_serv傳回給 nfsd、lockd 或 NFS 回呼服務。一旦該服務上線，svc_xprt_enqueue（）、svc_handle_xprt（） 和 svc_pool_wake_idle_thread（） 中的熱路徑就會到達支援指標為 NULL 的計數器。指標是每個 CPU 的偏移量，因此存取不會出錯：它解析為偏移當前 CPU 的每個 CPU 區域的零，並靜默地損壞存在於其中的任何變數。/proc/fs/nfsd/pool_stats 讀取會遍歷相同的 NULL 每個 CPU 儲存並傳回垃圾，並且在 CONFIG_DEBUG_SPINLOCK 或 lockdep 上，它會在從未初始化的鎖定上進行 splats。建立損毀的服務需要在 RPC 伺服器啟動期間發生 percpu 配置失敗，因此只有本機管理員在記憶體壓力或錯誤插入下才能存取;遠端對等體無法自行誘發不良狀態。檢查 __svc_create（） 中的每個 percpu_counter_init（） 傳回值，並在配置失敗時失敗，展開目前集區和之前初始化的每個集區中已設定的計數器。拆卸時每個計數器的離散 percpu_counter_destroy（） 只會釋放每個 CPU 分配一次。
    (CVE-2026-89547)

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

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

  - nfsd：確保 nfsd_file_do_acquire（） 不使用未開啟的檔案 ->atomic_open 允許在不實際開啟檔案的情況下傳回 SUCCESS。它透過呼叫 finish_no_open（） 來指示這一點。這意味著 dentry_create（） 可以傳回尚未開啟的檔案。這極不可能，因為 ->atomic_open 處理常式通常僅對現有檔案使用 finish_no_open（），在這種情況下不會呼叫 dentry_create（），並且被鎖定的父項應該防止爭用。然而，出於謹慎考慮，如果設定了 FMODE_OPENED，則教導 nfsd 僅使用 dentry_create（） 傳回的檔案，表示它實際上已被開啟，這似乎是明智之舉。（CVE-2026-89687）

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

ID	名稱	嚴重性
345146	Linux Distros 未修補弱點：CVE-2026-89519	high
345145	Linux Distros 未修補弱點：CVE-2026-89714	high
345144	Linux Distros 未修補弱點：CVE-2026-89743	high
345143	Linux Distros 未修補弱點：CVE-2026-80994	high
345142	Linux Distros 未修補弱點：CVE-2026-89702	critical
345141	Linux Distros 未修補弱點：CVE-2026-89523	high
345140	Linux Distros 未修補弱點：CVE-2026-89678	high
345139	Linux Distros 未修補弱點：CVE-2026-89763	high
345138	Linux Distros 未修補弱點：CVE-2026-89449	medium
345137	Linux Distros 未修補弱點：CVE-2026-89760	high
345136	Linux Distros 未修補弱點：CVE-2026-89464	medium
345135	Linux Distros 未修補弱點：CVE-2026-89526	critical
345134	Linux Distros 未修補弱點：CVE-2026-80937	high
345133	Linux Distros 未修補弱點：CVE-2026-89529	high
345132	Linux Distros 未修補弱點：CVE-2026-89681	critical
345131	Linux Distros 未修補弱點：CVE-2026-81008	high
345130	Linux Distros 未修補弱點：CVE-2026-89679	high
345129	Linux Distros 未修補弱點：CVE-2026-89594	high
345128	Linux Distros 未修補弱點：CVE-2026-81014	high
345127	Linux Distros 未修補弱點：CVE-2026-89534	high
345126	Linux Distros 未修補弱點：CVE-2026-89652	critical
345125	Linux Distros 未修補弱點：CVE-2026-80985	high
345124	Linux Distros 未修補弱點：CVE-2026-89691	high
345123	Linux Distros 未修補弱點：CVE-2026-87910	medium
345122	Linux Distros 未修補弱點：CVE-2026-89666	medium
345121	Linux Distros 未修補弱點：CVE-2026-89580	high
345120	Linux Distros 未修補弱點：CVE-2026-89722	high
345119	Linux Distros 未修補弱點：CVE-2026-89461	high
345118	Linux Distros 未修補弱點：CVE-2026-89504	high
345117	Linux Distros 未修補弱點：CVE-2026-89692	high
345116	Linux Distros 未修補弱點：CVE-2026-68497	high
345115	Linux Distros 未修補弱點：CVE-2026-89639	high
345114	Linux Distros 未修補弱點：CVE-2026-89515	high
345113	Linux Distros 未修補弱點：CVE-2026-89466	high
345112	Linux Distros 未修補弱點：CVE-2026-80952	high
345111	Linux Distros 未修補弱點：CVE-2026-80966	medium
345110	Linux Distros 未修補弱點：CVE-2026-89653	critical
345109	Linux Distros 未修補弱點：CVE-2026-89586	high
345108	Linux Distros 未修補弱點：CVE-2026-89493	high
345107	Linux Distros 未修補弱點：CVE-2026-89485	critical
345106	Linux Distros 未修補弱點：CVE-2026-89571	high
345105	Linux Distros 未修補弱點：CVE-2026-89712	critical
345104	Linux Distros 未修補弱點：CVE-2026-89703	critical
345103	Linux Distros 未修補弱點：CVE-2026-89699	high
345102	Linux Distros 未修補弱點：CVE-2026-89769	high
345101	Linux Distros 未修補弱點：CVE-2026-89600	high
345100	Linux Distros 未修補弱點：CVE-2026-89553	high
345099	Linux Distros 未修補弱點：CVE-2026-89701	medium
345098	Linux Distros 未修補弱點：CVE-2026-89547	high
345097	Linux Distros 未修補弱點：CVE-2026-89687	high

偵測

Nessus 的 Misc. 系列

high

high

high

high

critical

high

high

high

medium

high

medium

critical

high

high

critical

high

high

high

high

high

critical

high

high

medium

medium

high

high

high

high

high

high

high

high

high

high

medium

critical

high

high

critical

high

critical

critical

high

high

high

high

medium

high

high