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

  - ALSA： 6fire：綁定來自裝置的 MIDI 事件長度 usb6fire_comm_receiver_handler（） 使用裝置提供的長度位元組轉發 MIDI 事件，沒有綁定，也沒有檢查傳輸是否傳遞了那麼多位元組： if （！urb->status） { if （rt->receiver_buffer[0] == 0x10） /* 事件中的 MIDI */ if （midi_rt） midi_rt->in_received（midi_rt， rt->receiver_buffer + 2，rt->receiver_buffer[1]）;} receiver_buffer 是一個 64 位元組的 kzalloc（） 緩衝區 （COMM_RECEIVER_BUFSIZE），因此只有 62 個位元組在兩個位元組標頭後面。
    receiver_buffer[1] 是裝置選擇的 u8，因此以 0x10 和長度 0xFF 回應的裝置會使 snd_rawmidi_receive（） 讀取 255 位元組，從兩個位元組開始進入 64 位元組的物件。通過緩衝區的位元組會透過 rawmidi 讀取路徑傳遞給使用者空間。也不諮詢 urb->actual_length，因此短傳輸會將類型位元組和長度位元組保留為其先前的值，並且處理常式會對過時的資料採取行動。接收器 URB 是在探測時從 usb6fire_comm_init（） 提交的，因此讀取發生在插頭上，沒有使用者動作;轉發到使用者空間也需要開啟 MIDI 輸入子流，因為 usb6fire_midi_in_received（） 僅在設定 rt->in 時呼叫 snd_rawmidi_receive（）。7.2.0-rc5 （arm64） 上的 KASAN，來自模擬裝置的單一封包： 錯誤：KASAN：由任務 bash/183 在 addr ffff000009f64682 處讀取大小為 255 的 snd_rawmidi_receive 中的 slab-out-of-bounds __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] 由任務 11 分配：usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] 錯誤位址位於分配的 64- 的 2 個位元組內位元組區域 [ffff000009f64680， ffff000009f646c0） 當長度超過標頭後面的位元組時，拒絕事件，並要求傳輸已傳遞標頭加上該位元組。接收方 URB 會以 64 位元組的transfer_buffer_length提交，因此正版裝置無法傳遞超過這 62 位元組的事件，而且不會捨棄任何有效的事件。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-80973）

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

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

  - sctp：修正重複 RECONF 回應上的 stream->outcnt 反向溢位 快取的 RECONF 區塊可能包含多個要求參數。因此，重複回應可以在另一個參數仍未完成時再次尋找並處理相同的 ADD_OUT 要求，復原兩次，並可能使其下溢。以位元形式追蹤未完成的要求類型，並在第一次回應後清除每個位元。然後會忽略相同要求的稍後回應。（CVE-2026-89476）

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

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

  - platform/x86：think-lmi：免費系統憑證簽章 多重憑證支援也允許系統驗證物件儲存 ->signature 和 ->save_signature，這在移除驅動程式時會洩漏。釋放簽章以避免記憶體洩漏。（CVE-2026-81018）

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

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

  - zram：驗證 deflate 參數 我們必須先驗證使用者提供的 deflate winbits，然後再將其傳遞給 zlib_deflate_workspacesize（），如果 winbits 值超出有效範圍，則會觸發 BUG_ON（）。
    (CVE-2026-89716)

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

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

  - nothings stb commit 31c1ad3 的 stbsp_vsnprintf 函式 （stb_sprintf.h） 中的越界讀取允許攻擊者透過傳送特製的輸入來造成拒絕服務 （DoS）。（CVE-2026-79516）

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

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

  - platform/x86： int1092：修正 sar_probe（） 中潛在的記憶體洩漏 在 sar_probe（） 中的某些錯誤路徑中，未釋放 sar_get_data（） 呼叫的 parse_package（） 中配置給device_mode_info的記憶體。透過轉換為使用裝置管理的配置來修正此問題。（CVE-2026-89437）

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

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

  - iommu/tegra241-cmdqv：拒絕比 SID_MATCH 欄位寬的 vSID tegra241_vintf_init_vsid（） 將客體提供的 vSID 程式設計成 SID_MATCH，其VIRT_SID欄位跨越位元 [20:1]，其中位元 0 作為比對啟用標誌。因此，硬體僅符合 20 位資料流程識別碼。繫結檢查僅拒絕 virt_sid > UINT_MAX，其允許的值遠大於欄位。寫入virt_sid << 1 |然後，0x1 每比 20 以上一點就會下降一次：0x80000000的virt_sid會顯示為 SID_MATCH = 0x1，這是 vSID 0 上的有效相符項，因此項目會使用錯誤的串流識別碼別名。由於 vdev->virt_id 是客體控制，因此 VMM 可以觸發它。使用 FIELD_MAX（） 針對欄位寬度驗證virt_sid，並使用 FIELD_PREP（） 對暫存器進行程式設計，使值和欄位保持一致。（CVE-2026-89450）

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

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

  - RISC-V： KVM：修正 PMU 事件資訊陣列大小溢位 SBI PMU EVENT_GET_INFO以 32 位元整數儲存客體控制的 num_events * sizeof（*einfo）。在 RV64上，num_events = 0x10000001 會使0x100000010截斷為 16。然後，KVM 會配置一個項目，但會迴圈原始num_events，從而造成越界讀取和寫入。觸發巢狀客體： 錯誤：KASAN：kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 中的 slab-out-of-bounds 透過任務 init/1 在 addr ff600000074d46b0 讀取大小 4 呼叫追蹤：[<ffffffff8006471c>] kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 [<ffffffff800690c0>] kvm_sbi_ext_pmu_handler+0xca/0x268 [<ffffffff8006779e>] kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 [<ffffffff8006008c>] kvm_riscv_vcpu_exit+0x48c/0x540 [<ffffffff8005ea0a>] kvm_arch_vcpu_ioctl_run+0x37e/0xc80 由工作 1 分配： __kmalloc_noprof+0x19e/0x4b0 kvm_riscv_vcpu_pmu_event_info+0x72/0x142 kvm_sbi_ext_pmu_handler+0xca/0x268 kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 kvm_riscv_vcpu_exit+0x48c/0x540 kvm_arch_vcpu_ioctl_run+0x37e/0xc80 錯誤位址位於已分配的 16 位元組區域右側 0 位元組處 [ff600000074d46a0， ff600000074d46b0） 將共用記憶體大小儲存在 size_t 中，並拒絕乘法溢位。使用 GFP_KERNEL_ACCOUNT 配置客體驅動陣列，以便向 kmemcg 收費，並使用 __GFP_NOWARN 來抑制配置失敗警告。使用 kvcalloc（） 允許 vmalloc 後援和未帶正負號的長迴圈索引比對num_events。（CVE-2026-89513）

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

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

  - smb： client：修正 symlink_data（） 錯誤上下文迴圈中的 ALIGN（） 溢位 提交 7d9a7f1f96cd （smb/client：修正 symlink_data（）） 中可能的無限迴圈和 OOB 讀取）新增的檢查將 ALIGN 後長度與剩餘緩衝區進行了比較，但 ALIGN（） 本身可能會溢位：對於接近 UINT32_MAX 的 ErrorDataLength（例如 0xFFFFFFF9），ALIGN（x， 8） 換行為 0，因此後續邊界檢查通過， 迴圈前進零位元組，留下「p」指向過時的資料。透過在套用 ALIGN（） 之前檢查原始 ErrorDataLength 與剩餘空間，然後在之後再次檢查來修正。由於 raw_len 受緩衝區限制，因此 raw_len + 7 不能溢位，因此第二個檢查是精確的對齊後邊界保護。
    (CVE-2026-89634)

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: bound the free-cluster bitmap scan to the volume vol->lcn_empty_bits_per_page is sized from vol->nr_clusters at mount, but ntfs_cluster_alloc() bounds its scan of that array by the size of $Bitmap. Those are independent on-disk quantities and the mount-time check only rejects a $Bitmap that is too small, so an image whose $Bitmap covers more clusters than the volume has lets the scan index past the array. A run whose LCN lies in that gap takes the allocator straight there, since the caller passes the file's own last LCN as its locality hint. KASAN reports a slab out-of-bounds read when a file on such a volume is extended. Clamp the scan to what that array covers, mirroring the max_index calculation the mount-time scan already uses, and reject a decoded LCN at or beyond nr_clusters in the mapping pairs decoder. Conforming volumes are unaffected.
    (CVE-2026-89614)

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

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

  - RDMA/uverbs：將UVERBS_ATTR_UHW新增至 UVERBS_METHOD_REG_MR 原始認可遺漏了三個驅動程式 （mthca、irdma、siw） 具有與無法通過 ioctl 的reg_mr相關聯的 UHW 資料。他們也會假設 udata 不能是 NULL，因此無法傳遞有效的 udata 可能會在這些驅動程式中觸發 NULL udata 損毀。這在實際系統中永遠不會發生，因為在 rdma-core ibv_cmd_reg_mr_ex（） 中不接受 udata，並且這三個驅動程式不使用它，但惡意使用者空間可能會觸發它。
    (CVE-2026-89506)

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

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

  - MPLS：當 MPLS 路由具有多個 nexthop 時，在 pskb_may_pull（） mpls_select_multipath（） 呼叫 mpls_multipath_hash（） 選擇 nexthop 後重新載入標頭。在遍歷 MPLS 標籤堆疊時，雜湊常式會快取目前標籤的 hdr。找到堆疊底部標籤後，它會在讀取內部 IP 標頭之前呼叫 pskb_may_pull（）。如果 skb 是用非線性資料中的內部 IP 標頭建構的，而線性頭中的尾部空間不足，則 pskb_may_pull（） 會呼叫 pskb_expand_head（） 來取代 skb 頭並釋放舊的。這會留下 hdr 指向釋放的記憶體。IPv6 路徑在對較大標頭執行第二次提取時，可能會再次使 hdr 失效。該問題是透過靜態分析發現的。透過 bareudp/MPLS 多路徑設定傳送合法 Geneve 封包的再生程式在 2 次未修補的執行中，有 2 次觸發相同的 KASAN 報告： 錯誤：KASAN：任務 ksoftirqd/1/23 在 addr ffff88800ecc6e20 處讀取大小為 1 的 mpls_select_multipath 中的 slab-use-afterfree 呼叫追蹤：mpls_select_multipath mpls_forward
    __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action 由工作 23 釋放： kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath 每次成功提取後，從目前的 skb 頭重新載入 hdr，然後再衍生內部 IPv4 或 IPv6 標頭指標。（CVE-2026-89555）

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

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

  - 藍牙：RFCOMM：序列化安全性確認處理 rfcomm_security_cfm（） 會在 session_list 上查詢工作階段，然後遍歷其 DLC 清單，而不保留rfcomm_mutex。由於 RFCOMM 工作階段拆卸使用 rfcomm_mutex，因此 krfcommd 可以同時關閉和釋放相同的工作階段和 DLC：hci_rx_work krfcommd
    ----------- --------- rfcomm_session_get（） rfcomm_lock（） rfcomm_session_close（） rfcomm_dlc_unlink（） rfcomm_session_del（） kfree（s） rfcomm_unlock（） 遍歷 s->dlcs 然後，回呼可以讀取釋放的工作階段清單頭，並在更新其旗標或計時器時觸摸釋放的 DLC。使用 rfcomm_mutex 序列化 rfcomm_security_cfm（） 中的工作階段查詢和 DLC 遊走。這符合現有的 RFCOMM 工作階段存留期規則，並防止並行 rfcomm_session_del（） / rfcomm_dlc_unlink（） 在回呼使用物件時將其拆除。KASAN 報告： 錯誤：KASAN：rfcomm_security_cfm+0x41c/0x440 中的 slab-use-after-free 由任務 kworker/u17：1/89 在 addr ffff888111fb3960 讀取大小 8 工作佇列：hci0 hci_rx_work 呼叫追蹤：rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 由任務 69 分配： rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 任務 69 釋放：kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0 （CVE-2026-89569）

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

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

  - io_uring/查詢：傳遞給 copy_struct_to_user io_handle_query_entry（） 的 cap 使用者大小會限制傳入 copy_from_user（） 的 hdr.size，但會將原始使用者值保留為 usize。copy_struct_to_user（） 使用該 usize，當它大於核心結果時，clear_user（） 尾隨位元組。由於 hdr.size 是
    __u32，查詢可以要求將近 4 GiB 的清零，包括在 res_size 保持 0 的錯誤路徑上。
    介面無需響鈴即可透過IORING_REGISTER_QUERY連線。拒絕大於 PAGE_SIZE 的大小，如 copy_struct_* 介面的建議。（CVE-2026-81009）

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

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

  - HID： mcp2221：驗證 mcp2221_raw_event（） 中的報告大小 mcp2221_raw_event（） 絕不會驗證傳入的 HID 報告的大小。在MCP2221_I2C_GET_DATA路徑中，它信任裝置提供的 data[3] 作為複製長度，而不檢查收到的報告中是否實際存在 4 + data[3] 位元組。惡意或行為不當的 USB 裝置可以傳送包含大量資料的簡短報告[3]，導致 memcpy 讀取 HID 傳輸緩衝區中的有效報告資料，並透過 I2C/SMBus 讀取路徑將未初始化的核心記憶體洩漏回使用者空間。在輸入時新增最小大小檢查，並驗證來源範圍是否符合副本前收到的報告。CVE-2026-89621

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

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

  - cifs：在 cifs_file_set_size（） 中 cifsFileInfo_put（） 之後清除 tcon當 cifs_file_set_size（） 的 else 分支透過 find_writable_file（） 找到可寫入的檔案句柄時，它會從句柄的 tlink 中借用 tcon 和 server，嘗試以句柄為基礎的 set_file_size（） RPC，然後使用 cifsFileInfo_put（） 釋放句柄。如果 set_file_size（） 失敗，執行將下降到基於路徑的後援，該後援在 if （tcon == NULL） 保護下重複使用借用的 tcon 和伺服器。由於 tcon 此時不是 NULL，因此會略過保護。如果 cifsFileInfo_put（） 刪除了已從 tlink 樹中刪除的 tlink 上的最後一個參照（TCON_LINK_IN_TREE清除，就像在重新連接或工作階段拆卸期間發生的那樣），則 cifs_put_tlink（） 將釋放 tcon;隨後的 set_path_size（） 呼叫是釋放後使用。在 cifsFileInfo_put（） 之後設定 tcon = NULL 會導致現有守衛採用 cifs_sb_tlink（） 路徑，這會取得路徑型作業的新參照，或者在工作階段消失時完全失敗。（CVE-2026-89641）

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

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

  - libceph：拒絕 CRUSH ID 不相符的儲存桶 crush_decode（） 會依陣列插槽儲存儲存桶資料，對應程式稍後會從解碼的儲存區識別碼衍生每個儲存桶工作區索引。因此，格式錯誤的對應可能會透過編碼與 -1 - 插槽不同的 ID 來使一個儲存貯體重複使用另一個儲存貯體的工作區。對於統一儲存貯體，第二個複本選取範圍會將來源儲存貯體的排列擴展至該別名工作區緩衝區。如果來源儲存區大於別名儲存區，則寫入會經過較小的排列陣列，並可以逸出 kvmalloc 的 CRUSH 工作區。KASAN 報告 bucket_perm_choose（） 中 4 個位元組的 slab OOB 寫入。拒絕編碼 ID 不符合其陣列插槽的儲存貯體。有效的 CRUSH 對應已使用與儲存區插槽對應的規範負 ID，因此這會還原 work->work[-1 - in->id] 預期的不變量，而不會變更有效的對應行為。（CVE-2026-89656）

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

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

  - nfsd：cap 解碼的 POSIX ACL 計數到綁定排序成本 nfsd4_decode_posixacl（） 從線路上讀取 u32 條目計數，並將其直接傳遞給 posix_acl_alloc（） 和 sort_pacl_range（）。後者是 O（n^2） 冒泡排序，因此用戶端選擇的計數會在伺服器的複合處理路徑中驅動不受限制的 CPU。
    nfsd4_decode_posixacl（） xdr_stream_decode_u32（&count） /* 無上限的 u32 */ posix_acl_alloc（count， GFP_KERNEL） sort_pacl_range（*acl， 0， count - 1） /* O（n^2） 冒泡排序 */ 同一檔案中的編碼器端已經拒絕a_count超過 NFS_ACL_MAX_ENTRIES 的 ACL，但提交 5fc51dfc2eb1 （NFSD：新增對 XDR 解碼 POSIX 草稿 ACL 的支援） 中引入的解碼器省略了對稱檢查。透過在任何分配之前拒絕帶有 nfserr_inval 的大於 NFS_ACL_MAX_ENTRIES 的配線計數來修正，因此排序以 NFS_ACL_MAX_ENTRIES^2 比較為界。當我們在這裡時，如果 posix_acl_alloc（） 失敗，還要修正 nfserr_resource 返回。這不是 v4.1+ 的合法錯誤代碼。將其變更為傳回nfserr_jukebox，因為這更適合記憶體配置失敗。（CVE-2026-89695）

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

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

  - mmc： via-sdmmc：取消 remove 時的 card-detect 工作 停用裝置中斷並釋放 IRQ 可防止新的 card-detect 工作排入佇列，但處理常式已排入佇列的carddet_work在 via_sd_remove（） 傳回後仍可執行。via_sdc_card_detect（） 透過 container_of（） 恢復主機並取消參照其 MMIO 基礎;一旦 remove（） 傳回，主機就可以被釋放，這樣工作就會觸及釋放的記憶體。在釋放 IRQ 之後和取消 finish_bh_work之前取消carddet_work，卡片偵測處理常式也可以將其排入佇列。carddet_work可以透過 via_reset_pcictrl（） 重新啟用中斷;之後再次遮蓋它。此問題由內部靜態分析工具發現，並透過手動程式碼審查確認。（CVE-2026-89441）

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

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

  - HID： intel-thc-hid： intel-quickspi：綁定GET_REPORT對呼叫端緩衝區的回應 quickspi_hid_raw_request（） 以 len 為單位接收調用方的緩衝區長度，但 quickspi_get_report（） 永遠不會看到它，並且無論如何都會將整個裝置提供的回應複製到 buf 中：memcpy（buf， qsdev->report_buf， qsdev->report_len）;qsdev->report_len 來自觸控控制器傳回的輸入報告，而 buf 的大小會調整為呼叫端透過 HIDIOCGFEATURE 或 HIDIOCGINPUT 要求 HIDRAW 的任何內容。大於此的回應會使裝置控制的內容溢位 buf。intel-quicki2c 同級已經將呼叫端長度向下傳遞給 quicki2c_get_report（），並在複製之前針對它驗證回應。在這裡做同樣的事情。（CVE-2026-89619）

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

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

  - sched_ext：修正分派 kfuncs 中的 this_rq（） 假設 在核心排程下，分派從全核心選擇內執行，並且可以以同級 rq 為目標，因此 ops.dispatch（） 可能會在與分派 rq 不同的 CPU 上執行。幾個 kfunc 路徑假設兩者總是重合：- scx_dsq_move（） 透過測試 this_rq（） 的 rq 旗標來決定是否持有 rq 鎖，並相應地進行 lock-dance。同級的分派採用 unlocked-context 分支，並在可能鎖死的已持有的分派 rq 鎖定之上取得來源 rq 鎖定。- scx_bpf_sub_dispatch（） 分派 this_rq（） 及其隱藏的sub_dispatch_prev，為同級分派時為 NULL。- finish_dispatch（）、scx_bpf_dsq_reenq（） 和 scx_bpf_dsq_nr_queued（） 解析SCX_DSQ_LOCAL此 CPU 的本機 DSQ，而不是分派的 rq。
    後兩者也可以從其他 rq 鎖定操作調用，其中 SCX_DSQ_LOCAL 現在同樣解析為操作的 rq。這也會在沒有核心調度的情況下改變行為，例如，對於在喚醒的 CPU 上執行遠端喚醒的 ops.enqueue（），並且預期：哪個 CPU 碰巧執行操作是偶然的，操作的 rq 是它正在操作的內容，並且解析現在與 SCX_DSQ_LOCAL 分派落在任務 rq 上的插入端相匹配。使用 scx_locked_rq（） 追蹤的 rq，該 rq 設定為操作叫用周圍的分派 rq，並在未鎖定的內容中為 NULL。（CVE-2026-89518）

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

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

  - s390/dasd：針對未分配的私人資料保護 sysfs 紀律回呼 數個 sysfs 顯示/儲存處理常式會呼叫紀律回呼，直接或透過 DASD_DEFINE_ATTR（） 巨集取消參照 device->private。在 dasd_generic_set_online（） 期間，系統會在 check_device（） 配置 device->private 之前指派紀律，因此在該視窗中無權限讀取其中一個全球可讀屬性時，會解除參照 NULL 指標並發生錯誤。保護每個實際接觸 device->private 的回呼內的取消參照。（CVE-2026-89457）

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

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

  - accel/rocket：在清理路徑之前初始化工作網域 rocket_ioctl_submit_job（） 會在配置錯誤路徑上透過 rocket_job_put（） 釋放 rjob。rocket_job_cleanup（） 無條件呼叫 rocket_iommu_domain_put（job->domain），但只有在任務複製和 BO 查詢之後才會指派 job->domain。
    因此，該指派之前的失敗可能會清除具有 NULL 網域指標的工作。在第一個錯誤路徑可以釋放 rjob 之前，先獲取每個檔案的網域參照。在 rocket_copy_tasks（） 中釋放 rjob->tasks 之後，也要清除它，因此通用清理路徑在任務複製錯誤後無法再次釋放任務陣列。（CVE-2026-89591）

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

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

  - mfd：sm501：修正移除期間潛在的記憶體洩漏 對應的移除函式 sm501_pci_remove（） 和 sm501_plat_remove（） 未釋放配置給 sm501_pci_probe（） 和 sm501_plat_probe（） 中結構sm501_devdata的記憶體。透過新增對 kfree（） 的呼叫來解決此問題。（CVE-2026-80974）

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

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

  - Google go-attestation 版本（含） 0.6.1 的 Windows SIPA 事件記錄剖析器中有一個不受控制的遞迴弱點，攻擊者可讓攻擊者造成拒絕服務 （DoS）。（*WinEvents）.readELAMAggregation 函式會針對每個巢狀 elamAggregation 子事件遞迴，而不強制執行遞迴深度限制上限，而在遞迴執行路徑上會略過大小防護。
    透過提交包含深度巢狀 elamAggregation 標頭的特製 Windows 事件日誌，攻擊者可以耗盡 goroutine 呼叫堆疊，觸發無法恢復的致命運行時錯誤（堆疊溢位），從而立即使驗證程式應用程式崩潰。（CVE-2026-19201）

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

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

  - wifi： brcmfmac：修正 brcmf_sdio_read_control（） 中的記憶體洩漏 在 brcmf_sdio_read_control（） 中的某些錯誤路徑中，未釋放配置給 buf 的記憶體。透過新增 vfree（） 呼叫來解決此問題。[arend：按照 Johannes 的建議進行返工]（CVE-2026-80949）

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

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

  - wifi： mt76： mt7996：修正 AddBA req 幀的 TX DMA 映射洩露 mt7996/mt7992 將韌體交給韌體 HW MAC-TXP 用於 AddBA req 動作幀（MT_TXD7_MAC_TXD，在 mt7996_mac_write_txwi_80211（） 中設定），但其他方面是 FW-TXP 設備。因此，在 tx 上釋放 mt76_connac_txp_skb_unmap（） 將每幀 txp 解碼為結構mt76_connac_fw_txp。對於 MAC-TXP，fw_txp.nbuf 位元組別名 AddBA TID 字 （MT_TXP1_TID_ADDBA），該字始終為零，因此取消映射迴圈運行零次，並且 buf[1] 中的 skb DMA 映射永遠不會取消映射。buf[1].skip_unmap 是無條件設定的，因此通用 DMA 環清理也會跳過它。因此，每個 AddBA req 都會洩漏一個 TX DMA 映射，大約每個（重新）關聯一個。啟用 WED 後，這些對應會透過 WED swiotlb 集區反彈，因此在持續的用戶端重新連接流失下，集區會在 ~1-2 天後耗盡，之後 WED、WiFi MCU 和其他 SoC 上取用者的 DMA 對應會失敗。
    保留設計所依賴的延遲 （令牌釋放） 取消映射，並新增 mt7996 特定的 txp 取消映射，用於檢查這些幀的 MAC-TXP 佈局中的 MT_TXD7_MAC_TXD 並取消映射 buf[1]，否則委派給 mt76_connac_txp_skb_unmap（）。（CVE-2026-80934）

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

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

  - dm-pcache：將讀取的尾部 kset 限制為區段資料區域 在 cache_replay（）、回寫工作程式和 GC 背景工作程式中讀取的尾部 kset 會以 PCACHE_SEG_SIZE - seg_off （原始區段大小） 而不是資料區域來限制其長度。靠近線段末端的尾部會越過線段資料讀入下列控制區域。將讀取限制為資料區域 cache_seg_remain（）。（CVE-2026-80958）

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

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

  - nfsd：修正 nfsd4_create_file（） 中錯誤 dentry 的可能fh_compose dentry_create（） 假設可以提供與傳入的 dentry 不同的 dentry。例如，如果匯出的檔案系統是 NFS，而伺服器傳回以開啟與 dcache 中已有目錄的目錄相符的檔案控點，則可能會發生這種情況。顯然這是意料之外的！如果發生這種情況，已經儲存在 resfhp 中的 dentry （子項） 可能會被釋放，然後再取消參照。在確定我們有最終的 dentry 之前，我們不應該調用 fh_compose（），因此此補丁將 fh_compose（） 調用移動到兩個位置：一個用於目標已經存在的情況，另一個用於創建目標的 dentry_create（） 之後。
    (CVE-2026-89677)

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

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

  - SUNRPC：拒絕 gss_krb5_verify_mic_v2 gss_krb5_verify_mic_v2（） 中的短 RFC 4121 MIC 權杖，讀取 ptr[0..1] 處的權杖 ID、ptr[2] 處的旗標位元組和 ptr[3..7] 處的填充，然後將 ptr + GSS_KRB5_TOK_HDR_LEN 和 cksum_len 傳遞給 gss_krb5_mic_build_sg（）。這些存取都不會先檢查 read_token->len。最小安全權杖大小為 GSS_KRB5_TOK_HDR_LEN （16） 加上 ctx->krb5e->cksum_len （12-24，視 enctype） 而定。所有呼叫端都接受來自網路的較短權杖：- gss_unwrap_resp_integ（） 在配置 mic.data = kmalloc（len） 並將其傳遞給 gss_verify_mic（） 之前，僅強制執行上限 （位移量 + len <= rcv_buf->len）。因此，惡意 NFS 伺服器可以提供不透明的短總和檢查碼，從而產生 Kerberos MIC 驗證程式讀取過去的小型 slab 配置。- gss_validate（） 在將有線提供的長度傳遞給 gss_validate_seqno_mic（） 之前僅強制執行 len <= RPC_MAX_AUTH_SIZE （400），後者建構麥克風xdr_netobj並呼叫 gss_verify_mic（）。- svcauth_gss_verify_header（） 在分派至 gss_verify_mic（） 之前僅強制執行 checksum.len >= XDR_UNIT （4 位元組）。- svcauth_gss_unwrap_integ（） 僅檢查總和檢查碼是否適合 gsd->gsd_scratch。在任何 ptr[] 存取或散佈清單建構之前，在 gss_krb5_verify_mic_v2（） 的頂端新增長度保護。來自 gss_krb5_get_mic_v2（） 的格式正確的 MIC 權杖已經恰好具有 GSS_KRB5_TOK_HDR_LEN + cksum_len 位元組，因此有效流量不受影響。（CVE-2026-89537）

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

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

  - 已解決 Linux 核心中的下列弱點：nfsd: fix layout fence worker double-reference race The workqueue core clears WORK_STRUCT_PENDING before the callback is invoked, so delayed_work_pending() in lm_breaker_timedout() can return false while the fence worker is already running. This lets the breaker take a duplicate sc_count reference and schedule a new worker that coalesces with the in-progress one. The extra reference is never put, leaking the layout stateid. Replace the racy delayed_work_pending() check with an ls_fence_inflight boolean set atomically with refcount_inc_not_zero() under ls_lock, and cleared under ls_lock before the final nfs4_put_stid() on the dispose path; the retry path intentionally retains it. Remove the self-rearm mod_delayed_work() at the top of the worker. (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 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
345176	Linux Distros 未修補弱點：CVE-2026-80973	medium
345175	Linux Distros 未修補弱點：CVE-2026-89476	high
345174	Linux Distros 未修補弱點：CVE-2026-81018	high
345173	Linux Distros 未修補弱點：CVE-2026-89716	high
345172	Linux Distros 未修補弱點：CVE-2026-79516	medium
345171	Linux Distros 未修補弱點：CVE-2026-89437	medium
345170	Linux Distros 未修補弱點：CVE-2026-89450	high
345169	Linux Distros 未修補弱點：CVE-2026-89513	high
345168	Linux Distros 未修補弱點：CVE-2026-89634	critical
345167	Linux Distros 未修補弱點：CVE-2026-89614	critical
345166	Linux Distros 未修補弱點：CVE-2026-89506	medium
345165	Linux Distros 未修補弱點：CVE-2026-89555	critical
345164	Linux Distros 未修補弱點：CVE-2026-89569	high
345163	Linux Distros 未修補弱點：CVE-2026-81009	high
345162	Linux Distros 未修補弱點：CVE-2026-89621	medium
345161	Linux Distros 未修補弱點：CVE-2026-89641	high
345160	Linux Distros 未修補弱點：CVE-2026-89656	critical
345159	Linux Distros 未修補弱點：CVE-2026-89695	high
345158	Linux Distros 未修補弱點：CVE-2026-89441	high
345157	Linux Distros 未修補弱點：CVE-2026-89619	high
345156	Linux Distros 未修補弱點：CVE-2026-89518	high
345155	Linux Distros 未修補弱點：CVE-2026-89457	high
345154	Linux Distros 未修補弱點：CVE-2026-89591	medium
345153	Linux Distros 未修補弱點：CVE-2026-80974	medium
345152	Linux Distros 未修補弱點：CVE-2026-19201	high
345151	Linux Distros 未修補弱點：CVE-2026-80949	medium
345150	Linux Distros 未修補弱點：CVE-2026-80934	medium
345149	Linux Distros 未修補弱點：CVE-2026-80958	high
345148	Linux Distros 未修補弱點：CVE-2026-89677	critical
345147	Linux Distros 未修補弱點：CVE-2026-89537	critical
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

偵測

Nessus 的 Misc. 系列

medium

high

high

high

medium

medium

high

high

critical

critical

medium

critical

high

high

medium

high

critical

high

high

high

high

high

medium

medium

high

medium

medium

high

critical

critical

high

high

high

high

critical

high

high

high

medium

high

medium

critical

high

high

critical

high

high

high

high

high