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

  - scsi：qla2xxx：避免在非同步 IOCB 逾時中重複完成 qla2x00_async_iocb_timeout（） 嘗試中止逾時的非同步 IOCB。當 qla24xx_async_abort_cmd（） 失敗時，SRB_LOGIN_CMD路徑和SRB_CTRL_VP/預設路徑都會掃描 outstanding_cmds[] SRB，然後無條件地呼叫 sp->done（sp， QLA_FUNCTION_TIMEOUT），而不檢查是否實際找到並移除了 SRB。如果回應 ISR 先完成相同的控制碼，則會移除 qp_lock_ptr 下的 SRB 並執行 sp->done（）
    -> complete（sp->comp）。提交者 qla24xx_control_vp（） 從 wait_for_completion（） 喚醒，清除 sp->comp，刪除其參照並返回，回收堆疊上完成。計時器參照會讓 SRB 在逾時處理常式中保持活動狀態，但不會在提交者的堆疊中保持作用。逾時接著會發出第二個 sp->done（） -> qla_ctrlvp_sp_done（），以評估 （sp->comp） complete（sp->comp）;在提交者的 NULL 儲存區之前載入指標時，complete（） 會寫入釋放的堆疊框架，這是釋放後使用。
    追蹤此路徑是否已從 outstanding_cmds 中移除 SRB，並僅在刪除時呼叫 sp->done（），因此命令會由擁有它的路徑完成一次。這反映了 qla24xx_abort_iocb_timeout（） 中已使用的sp_found保護。（CVE-2026-89847）

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

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

  - mm/huge_memory：將 PMD 髒位傳輸到 Zap 上的對開本 zap_huge_pmd_folio（） 會將 PMD 年輕位元傳播到檔案盒的對開本，但不會傳播髒位。pte 路徑確實在 zap_present_folio_ptes（） 中傳播它，在 __split_huge_pmd_locked（） 中 pmd 拆分路徑也是如此。對於大多數檔案對應來說，遺漏是無害的，因為寫入共用檔案對應會經過 page_mkwrite（），這會弄髒對開本。tmpfs 則不同：它沒有 page_mkwrite（），而 vma_wants_writenotify（） 對它來說是 false，因此MAP_SHARED tmpfs 映射上的 *讀取* 錯誤會透過 do_read_fault（） 安裝可寫入的 PMD。
    do_read_fault（） 不會呼叫 fault_dirty_shared_page（），因此透過該映射的後續儲存區只會在 pmd 中設定硬體髒位，並且永遠不會呼叫 folio_mark_dirty（）。錯誤分配的 shmem 作品集被標記為 uptodate，但不是髒的（請參閱 shmem_get_folio_gfp（）） 中的 clear： 區塊），因此根本不會設定PG_dirty。當進程終止時，取消映射這樣的對開本 - munmap（） 或 exit_mmap（） - 然後丟失它寫入的唯一記錄，因為 zap_huge_pmd（） 會刪除 pmd 而不傳輸髒位。
    之後回收會看到一個乾淨的 shmem 對開本：shrink_folio_list（） 中的整個換出區塊都在 if （folio_test_dirty（folio）） 內，因此跳過 pageout（） 並且對開本落入 __remove_mapping（） 中。在那裡，folio_is_file_lru（） 對於交換式作品集來說是 false，因此不會建立影子項目，並且
    __filemap_remove_folio（對開本，NULL） 只會清空i_pages槽。資料會釋放，而從未寫入交換，而該索引上的下一個錯誤會傳回新歸零的對開本。對於在取消映射中將狀態保持在MAP_SHARED tmpfs 區段中的任何進程來說，這是無訊息資料遺失 - 例如，透過 /dev/shm 從一個處理程序世代傳遞到下一個處理程序世代的快取。它要求對開本進行 PMD 映射，因此它僅在啟用 shmem THP 後才會顯示（這就是我們在 Meta 車隊中所做的並開始注意到崩潰）;當 THP 關閉時，PTE 路徑會正確傳輸髒位元。它也僅在啟用交換時才可見，因為在沒有交換裝置的情況下，shmem 作品集（位於匿名 LRU 上）根本不會被回收掃描，因此乾淨的作品集永遠不會被丟棄。在具有 tmpfs 掛載 huge=within_size的 x86_64 上重現：讀取錯誤 2MB 支援的區域，透過產生的映射寫入已知模式，munmap，強制回收 cgroup，然後重新映射並回讀。如果沒有此修補程式，區域會以零讀取，而 vmstat 會顯示 zswpout 0 - 資料已捨棄，而非交換。使用此修補程式後，區域可以正確讀取，並且頁面會如預期般交換。使用 huge=never，或當第一次接觸是寫入時，測試會以任一方式通過。（CVE-2026-89987）

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

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

  - drm/amdgpu：修正 amdgpu_vram_mgr_init（） 中的 init 排序 drmm_cgroup_register_region（） 在 INIT_LIST_HEAD（） 之前呼叫，在 amdgpu_vram_mgr_init（） 中呼叫 gpu_buddy_init（）。如果失敗，函式會提前傳回並略過這些初始化。由於在呼叫 amdgpu_vram_mgr_init（） 之前將 adev->mman.initialized 設定為 true，因此失敗會觸發 amdgpu_ttm_fini（），而 （） 會呼叫 amdgpu_vram_mgr_fini（），然後：- 在 reservations_pending 和 reserved_pages 上呼叫 list_for_each_entry_safe（），其 list_head：：next 指標為零初始化 （NULL）。迴圈不會將它們識別為空，並取消參照 NULL。- 呼叫 gpu_buddy_fini（），透過 for_each_free_tree（） 無條件迭代 free_trees[] 。由於 mm->free_trees 為 NULL （從未配置），因此會解除參照 NULL。兩者都會導致模組載入錯誤路徑上的核心錯誤。透過將 drmm_cgroup_register_region（） 移動到清單和 buddy 分配器完全初始化之後進行修復，以便拆卸路徑可以安全運行。
    (CVE-2026-89828)

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

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

  - accel/ethosu：檢查探測中的 MMIO 對應錯誤 當無法對應暫存器資源時，devm_platform_ioremap_resource（） 會傳回錯誤指標。ethosu_probe（） 會儲存它並繼續進行，直到初始化透過 MMIO 存取子解除參照為止。在初始化裝置之前傳回對應錯誤。
    (CVE-2026-89977)

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

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

  - scsi：bsg：修正io_uring傳遞命令設定中的 TOCTOU scsi_bsg_uring_cmd（） 從共用的 mmap'd SQE 讀取bsg_uring_cmd。使用者空間可以在我們檢查欄位後和使用欄位之前變更欄位。request_len是尖銳的情況：在綁定檢查和 copy_from_user（） 中的溢位 scmd->cmnd 之後，它可以增長超過 sizeof（scmd->cmnd）。READ_ONCE（） 我們在使用前檢查或使用的 SQE 欄位。（CVE-2026-90009）

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

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

  - clk： meson：將父項數量與實際計數對齊gxbb_32k_clk_sel Christian 在 GXBB WeTek Hub 上觀察到以下越界讀取：
    ================================================================== 錯誤：KASAN：在
    __clk_register+0x1b70/0x2418 由 task swapper/0/1 在 addr ffffd66320cf88e0 讀取大小 8 CPU：0 UID：0 PID：1 Comm：swapper/0 未受污染 7.0.0-rc5 #1 PREEMPT 硬體名稱：WeTek Hub （DT） 呼叫追蹤：
    show_stack+0x14/0x20 （C） dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8
    __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188
    __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 有錯誤的位址屬於變數： gxbb_32k_clk_parents+0x60/0x400 有錯誤的位址屬於 vmalloc 虛擬映射 有錯誤的位址屬於實體頁面： 有錯誤位址周圍的記憶體狀態：ffffd66320cf8780： 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800： 00 04 f9 f9 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900： 00 01 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8980： 00 00 02 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 f9 ================================================================== 提交 7915d7d5407c （clk： amlogic： gxbb： 刪除不存在的 32k 時鐘父項） 從 gxbb_32k_clk_sel 多路復用器中刪除了不存在的時鐘父項，但沒有調整硬式編碼num_parents欄位。改用 ARRAY_SIZE 來修正該多用器的實際父項數量（避免將來出現類似問題）。
    (CVE-2026-89947)

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

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

  - KVM： nVM：確保在正確的實體 CPU 上模擬 INVVPID 模擬 INVVPID 時，KVM 在對運算元進行一些驗證後，使用 vpid02 （而不是 L1 指派的 VPID） 在實體 CPU 上執行 INVVPID。但是，KVM 執行 INVVPID 的實體 CPU 可能與執行 L2 的 CPU 不同。例如，在下列案例中： - L2 在 CPU #1 上執行並結束至 L1 （vmx->nested.vmcs02.cpu=1） - L1 移轉至 CPU #2 並執行 INVVPID - KVM 在 CPU #2 上執行 INVVPID - L1 移轉回 CPU #1 並執行 L2 （vmx->nested.vmcs02.cpu=1） CPU #1 上的 TLB 項目永遠不會失效，因為 INVVPID 是在 CPU #2上執行，而 vmcs02 從未在不同的 pCPU 上執行 （即
    vmx_vcpu_load_vmcs（） 將*不*請求 KVM_REQ_TLB_FLUSH）。請確定 INVVPID 是在上次執行 L2 的相同 pCPU 上執行，如果沒有，請回復為清除 last_vpid=0，以在下一個巢狀 VM-Enter 上觸發完整 VPID 排清 （因為 KVM 會針對 L2 使用不同的 VPID 偵測 L1）。如果 L2 最終在不同的 pCPU 上運行，KVM 無論如何都會透過 vmx_vcpu_load_vmcs（） 排清 TLB。（CVE-2026-89929）

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

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

  - f2fs：修正 find_in_level find_in_level（） 中的 dentry 對開本洩漏，在呼叫 find_in_block（） 之前，先取得帶有 f2fs_find_data_folio（） 的 dentry 對開本。如果 find_in_block（） 傳回錯誤，則函式會將錯誤儲存在 res_folio 中，並在不刪除 dentry 對開本的情況下中斷迴圈。這會洩漏 find_in_block（） 錯誤路徑上的對開本參照。在將錯誤傳回給呼叫者之前，先刪除 dentry 對開本。（CVE-2026-89837）

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

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

  - HID： wacom：驗證 wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq（） 中的報告長度會接收 'len' 中的有線報告長度，但在剖析之前從不查閱它。在 report-id 閘門之後，它無條件地調用 wacom_intuos_pro2_bt_pen（），然後由 features.type 選擇，一個固定的子解析器鏈，這些子解析器都不會接收 'len'：wacom_intuos_pro2_bt_pen（wacom）;if （type == INTUOSP2_BT || type == INTUOSP2S_BT） { wacom_intuos_pro2_bt_touch（wacom）; wacom_intuos_pro2_bt_pad（wacom）;
    wacom_intuos_pro2_bt_battery（wacom）;} else { wacom_intuos_gen3_bt_pad（wacom）;
    wacom_intuos_gen3_bt_battery（wacom）;} 每個子剖析器在固定位移處解除參照 wacom->data。每個分支上觸及的最遠位元組為：INTUOSP2_BT / INTUOSP2S_BT：wacom_intuos_pro2_bt_pad（） 讀取 data[285] （touchring 位元組），因此報告必須至少為 286 位元組;INTUOSHT3_BT （gen3）：
    wacom_intuos_gen3_bt_battery（） 讀取資料[45]，因此報告必須至少為 46 位元組。features.type 是從 VID/PID id_table項目中選擇的，並且 wacom_setup_device_quirks（） 強制註冊該類型的筆/鍵盤/觸控輸入，與報告描述元無關，因此惡意或故障配對/欺騙的藍牙外圍設備可以通告該 VID/PID 並發送仍然滿足 data[0] == 0x80/0x81 門的過小報告。然後，驅動程式會讀取收到的報告，並透過 evdev （筆和墊輸入節點上的 MSC_SERIAL / ABS_MISC / ABS_WHEEL）、具有具體使用者空間回讀通道的越界讀取，以及在傳輸上進行真正的越界讀取，其支援緩衝區大小調整為 （小） 報告描述元，而不是固定大小的暫存緩衝區。這與同級 wacom_intuos_bt_irq（） 中已強化的錯誤提交 2f1763f62909 （HID：wacom：修正 wacom_intuos_bt_irq 中的越界讀取） 相同類別，可在剖析前保護每個報告 ID 免受其最小長度的影響。以相同的方式保護 wacom_intuos_pro2_bt_irq（）：在剖析之前，拒絕短於所選分支實際解除參照、警告和救助的最遠偏移量的報告。因為整個手寫筆/觸控/鍵盤/電池鏈會無條件地每個分支執行，所以針對最大位移 （INTUOSP2_BT/INTUOSP2S_BT 為 286 位元組，gen3 分支為 46 位元組） 的單一前期檢查會限制每個子剖析器。在簡短報告中返回 0 也會跳過對相同格式錯誤報告的呼籲，這是安全、保守的行為。（CVE-2026-89999）

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

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

  - media： rc： sunxi-cir： 探查失敗時取消註冊 rc 裝置 rc_register_device（） 成功之後，稍後的探查失敗必須復原使用 rc_unregister_device（） 的登錄。目前的錯誤路徑會跳到分配清理標籤，並且只調用 rc_free_device（），留下 rc 裝置註冊和 rc_register_device（） 建立的資源。為 IRQ 查閱、IRQ 要求和硬體初始化失敗路徑新增已註冊的裝置解除標籤。在 rc_register_device（） 成功之前，保留 rc_free_device（） 以備失敗。（CVE-2026-89883）

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

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

  - scsi：qla2xxx：修正韌體轉儲期間的 FCE 追蹤釋放後使用 qla2x00_free_fce_trace（） 釋放和清除 ha->fce，同時僅保留 fce_mutex。韌體轉儲消費者 qla27xx_fwdt_entry_t264（） 和 qla25xx_copy_fce（） 在 hardware_lock 下讀取 ha->fce （NULL 檢查，後面接著緩衝區的複本），並且永遠不會fce_mutex。因此，debugfs FCE 停用可能會釋放轉儲的 NULL 檢查與其複本之間的 DMA 緩衝區，進而造成釋放後使用。在 hardware_lock 下取消發佈 ha->fce，然後釋放鎖定並釋放 DMA 緩衝區 （dma_free_coherent（） 可能會休眠）。並行傾印會完成其檢查和複製，且緩衝區仍然有效，或觀察到 ha->fce == NULL 並略過它。（CVE-2026-89853）

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

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

  - usb-storage： ene_ub6250：修正掃描工作與探測 ene_ub6250_probe（） 呼叫 usb_stor_probe2（） 之間的爭用，後者會啟動 usb-storage 基礎架構並排程延遲的掃描工作。驅動程式接著會呼叫 ene_get_card_type（），其會透過 ene_send_scsi_cmd（） 和 usb-storage 大量傳輸協助程式傳送 ENE 命令。透過 usb_stor_Bulk_max_lun（） 和 ene_get_card_type（） 的延遲掃描都使用 us->current_urb。掃描工作會以 us->dev_mutex 序列化此存取，但 ENE 卡型探測不會。如果掃描工作在 ene_get_card_type（） 仍在使用 us->current_urb 時執行，usb_submit_urb（） 會警告 URB 已處於作用中狀態。使用 us->dev_mutex 序列化 ene_get_card_type（），以符合掃描路徑使用的鎖定。（CVE-2026-90031）

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

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

  - 暫存：rtl8723bs：修正 rtw_get_wps_attr（） 中的 OOB 讀取/堆疊溢位 rtw_get_wps_attr（） 在從無線管理框架取得的 WPS IE 內遍歷 WPS 屬性。針對每個候選屬性，它只會檢查固定的 4 位元組屬性標頭 （2 位元組標識碼 + 2 位元組長度） 是否適合 IE 內：if （attr_ptr + 4 > wps_ie + wps_ielen） 中斷;u16 attr_id = get_unaligned_be16（attr_ptr）;u16 attr_data_len = get_unaligned_be16（attr_ptr + 2）;u16 attr_len = attr_data_len + 4;attr_data_len （因此 attr_len） 是直接從連線讀取，在用作以下大小之前，永遠不會針對 IE 中的剩餘位元組進行檢查： memcpy（buf_attr， attr_ptr， attr_len）;由於 attr_len 完全由攻擊者控制 （0 到 65535+4），這既是 wps_ie 的堆積 OOB 讀取，更嚴重的是，在多個呼叫站點上發生堆疊緩衝區溢位，其中 buf_attr 是單位元組堆疊變數，例如 rtw_get_wps_attr_content（） 的呼叫者將WPS_ATTR_SELECTED_REGISTRAR傳遞到堆疊 u8 sr/u8 selected_registrar （drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c， drivers/staging/rtl8723bs/core/rtw_mlme_ext.c）。因此，在掃描期間處理的信標或探查響應中精心製作的 WPS IE 可能會粉碎剖析執行緒的堆疊。rtw_get_wps_attr_content（） 本身沒有獨立的長度檢查，只是信任它從 rtw_get_wps_attr（） 返回的attr_len，因此在這裡修復邊界也可以修復該調用者。上面的 attr_ptr + 4 > wps_ie + wps_ielen 標頭檢查是由提交 1463ca3ec6601 新增的 （暫存：
    rtl8723bs：修正 rtw_get_sec_ie（）、rtw_get_wapi_ie（） 和 rtw_get_wps_attr（）） 中的 OOB 讀取，這些讀取會限制固定標頭，但從未將檢查擴展為涵蓋其後面的可變長度屬性資料。
    在 attr_len 被用作 memcpy（） 長度或接受為匹配項之前添加該遺漏的檢查。
    (CVE-2026-90018)

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

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

  - ASoC：hdac_hda：修正元件登錄失敗時的 hlink 參照計數洩漏 hdac_hda_dev_probe（） 在登錄 ASoC 元件之前，取得具有 snd_hdac_ext_bus_link_get（） 的 HDA 鏈結。如果元件註冊失敗，函式會傳回，而不會捨棄連結參照。一律在註冊嘗試之後呼叫 snd_hdac_ext_bus_link_put（），以便在成功和失敗時平衡探測期間取得的參照。（CVE-2026-89944）

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

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

  - parisc：eisa：修正剖析無效 IRQ 值時的無限迴圈 當透過 eisa_irq_edge= 核心命令列參數（例如 eisa_irq_edge=16,5）傳遞無效值時，eisa_irq_setup（） 會列印錯誤訊息並繼續，而不前進目前位置。結果，相同的無效值會一次又一次地被剖析，從而在核心啟動時造成無限迴圈。前進到下一個逗號分隔項目，或在沒有下一個項目時停止剖析，然後再繼續，以便正常處理其餘項目。（CVE-2026-89964）

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

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

  - accel/amdxdna：從零長度排清SYNC_BO提前返回不會限制其大小，因此零位元組的要求會到達 drm_clflush_virt_range（），以無條件的 clflushopt（end - 1） 結尾。對於空白範圍，即映射之前的位元組，並且 abo->mem.kva 來自 vmap（），因此存取位於 vmalloc 區域下方的保護頁面中，並且會出現錯誤： 錯誤：無法處理位址的頁面錯誤：
    ffffd16fbbc70fff #PF：核心模式下的主管讀取存取權 哎呀：哎呀：0000 [#1] SMP NOPTI CPU：7 UID：
    1000 通訊：sync_bo_probe RIP：0010：drm_clflush_virt_range+0x3c/0x70 呼叫追蹤：
    amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 任何可以開啟渲染節點的處理程序都可以執行此操作。在 Strix Point NPU （1022：17f0） 上重現了 3 次中的 3 次，方法是在AMDXDNA_BO_SHARE物體上調用大小為 0 的SYNC_BO。匯入臂接受相同的要求，但會排清整個散佈清單，因此它仍然存在。空白範圍不需要排清，所以在選擇路徑之前先回答。（CVE-2026-89978）

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

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

  - KVM：arm64：移除虛擬機器範圍的 VNCR 對應計數器 全域 VNCR 對應計數器可用來決定在處理 TLB 無效時，L1 提供的 VNCR 頁面是否對應在任何 CPU 上的 L0 中。在 fixmap 中進行映射時，它會增加，並在取消映射時遞減。事實證明，這種追蹤有幾個缺陷：- 我們試圖使 TLB 失效，而映射只是 TLB 的機會主義結果。檢查此計數器以決定是否需要使 TLB 失效，可能會導致遺漏失效。- L1 vpu 使自己的 TLB 失效 （很有可能的情況） 將無法成功使 VNCR 虛擬 TLB 失效，因為該頁面在此階段未對應在 L0 中。由於此追蹤無法提供所需的最低保證，而且只是效能最佳化，因此請將其完全移除。（CVE-2026-89915）

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

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

  - media：s2255：將擷取的 JPEG/MJPEG 影格的 s2255_fillbuff（） memcpy（） 的 vc->jpg_size 位元組複製到 vb2 平面之前，先綁定 JPEG 影格大小。vc->jpg_size 是從設備發送的 S2255_MARKER_FRAME 標頭（save_frame（） 中的 pdword[4]）逐字獲取的，並且與其上方的幀有效負載長度不同，它永遠不會受到限制：有效負載 = le32_to_cpu（pdword[3]）;if （payload > vc->req_image_size） /* 檢查有效負載 ... */ return -EINVAL;vc->pkt_size = 負載;vc->jpg_size = le32_to_cpu（pdword[4]）;/* ...jpg_size不是 */ 因此，惡意或故障裝置可以報告比目標 vb2 平面更大的jpg_size，並且 memcpy（） 會寫入它。jpg_size 是一個帶正負號的 int，因此設定頂位的值也會變成一個巨大的長度。在複製之前，請拒絕jpg_size為負數或超過平面大小的框架。（CVE-2026-89879）

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

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

  - KVM：s390：透過不重新插入 CK 機器檢查來修正記憶體損毀 通道子系統損壞機器檢查適用於主機通道子系統。客體通道子系統會在使用者空間 VMM 中模擬。
    將此類機器檢查轉發給訪客是沒有意義的。這也簡化了機器檢查重新注入，並避免了 sashiko 報告的堆疊變數的 kfree。可能仍然有機器檢查將 ck 位設置為另一個位（例如指令損壞），屏蔽 s390_backup_mcck_info（） 中的 CK 位，就像 CP 和 ED 位已經存在一樣。（CVE-2026-89920）

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

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

  - cpuidle： dt_idle_genpd：kfree（） 原始名稱分配 dt_idle_pd_alloc（） kasprintf（） 完整節點路徑，然後將 pd->name 指向該字串的 kbasename（）。dt_idle_pd_free（） kfree（） 的 pd->name，這不再是分配的開始。請改為複製基底名稱。（CVE-2026-89992）

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

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

  - ima：檢查 validate_hash_algo（） 中 dentry_path（） 的ERR_PTR當路徑超出緩衝區時，dentry_path（） 會傳回 ERR_PTR（-ENAMETOOLONG）。validate_hash_algo（） 將結果直接傳遞給 integrity_audit_msg（），而不進行檢查。ERR_PTR 不是 NULL，因此 integrity_audit_message（） 看到一個有效的指標並在其上呼叫 strlen（），這會出錯： 錯誤：無法處理位址的頁面錯誤：
    ffffffffffdc RIP：0010：strlen+0x30/0xa0 呼叫追蹤：audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 檢查 IS_ERR（） 並改用 NULL，這會使稽核訊息跳過 name= 欄位，而不是當機。（CVE-2026-89989）

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

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

  - ASoC：cs35l33：在執行階段暫停之前排空執行緒 IRQ cs35l33_runtime_suspend（） 目前會將編解碼器切換為 regcache_cache_only（true） 並關閉它的電源，而不先靜止 devm_request_threaded_irq（） 所登錄的執行緒 IRQ。這留下了一個窗口，在暫停關閉即時暫存器存取後，cs35l33_irq_thread（） 仍然可以運行。執行中的系統可以在運行時間 PM 期間達到此目的，而驅動程式仍未遮罩嚴重故障 IRQ。如果執行緒處理常式在該視窗中執行，則會在啟用 cache_only 之後讀取易失性 INT_STATUS_1/2，忽略 regmap_read（） 失敗，並且仍然可以驅動 AMP_SHORT_RLS、CAL_ERR_RLS、OTE_RLS 和 OTW_RLS 版本路徑。在進入 cache_only/power-off 之前請使用 disable_irq（），這樣任何正在進行的執行緒處理常式都會被清空，並且在暫停狀態下無法執行新的 IRQ 執行緒。只有在 runtime_resume（） 使用 regcache_sync（） 還原即時暫存器存取之後，才重新啟用 IRQ。由於探測僅在 devm_request_threaded_irq（） 失敗時發出警告，因此在停用或重新啟用 IRQ 之前，請追蹤 IRQ 是否實際安裝。（CVE-2026-89946）

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

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

  - USB： gadget： f_mass_storage：修正 fsg_common_set_num_buffers（） 中的 NULL 指標解除參照 之前，fsg_num_buffers_validate（） 已被移除，因為 Kconfig 將 n 的限制設定為 2 到 256，預設值為 2，因此沒有必要。不過，以 kstrtou8（） 將 n 值反映為 0 或 1 的方式設定頁面內容，會繞過這些限制，如果 n 為 0，則會導致 NULL 指標解除參照。透過新增對 n < 2 的檢查，如果 n 為 0 或 1 與 Kconfig 邏輯一致，則傳回 -EINVAL，以解決此問題。（CVE-2026-90023）

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

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

  - f2fs：修正放入大型對開本後的 folio_nr_pages（） 爭用無效 我們基於 v6.18 的 Android 系統持續遭受即時鎖定和錯誤頁面統計，如 [1] 所示，這與損壞的 xarray 插槽狀態有關。
    通過調查 f2fs 中的大型對開操作，我們發現了以下爭用，並通過在刪除引用計數和folio_lock之前獲取nr_pages來修復它。f2fs_get_read_data_folio（） 在使頁面快取中的大型對開本失效時，會在 folio_nr_pages（） 之前呼叫 f2fs_folio_put（）。這會解除鎖定對開本並刪除呼叫端參照，留下一個視窗，在其中並行截斷或對開分割可以縮小複合對開本，或在計算無效範圍之前釋放它。然後，過小的範圍會在 mapping->i_pages 中留下分割的子對開本，稍後可能會與截斷和回收發生不良互動 （當對開本>映射不再與被截斷的映射相符時，過時的 xarray 項目和錯誤的頁面狀態）。[1] PID：2594 任務：
    ffffff8169b81580 CPU：7 COMMAND：Thread-3 #0 [ffffffc08ef2b8a0] xas_load於 fffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries於 fffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range於 fffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final於 ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode於 fffffffe52c4c8400 #5 [ffffffc08ef2bcc0] 在 ffffffe52c2de9f4 #6 驅逐 [ffffffc08ef2bd00] iput 在 ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode於 fffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill於 fffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput 於 fffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput於 fffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput於 fffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run於 fffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop於 fffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc於 fffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler於 fffffffe52d1f8d10 （CVE-2026-89836）

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

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

  - drm/amdgpu：避免強制完成未初始化的 UVD 環 uvd_v7_0_sw_init（） 不會初始化 SR-IOV VF 的 UVD 解碼環。然而，amdgpu_uvd_resume（） 在還原解碼環時，會無條件地強制完成解碼環。未初始化柵欄驅動程式時，略過柵欄完成。
    (CVE-2026-89827)

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

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

  - PCI：允許每個功能的 PCI 插槽來修正 s390 上的插槽重設 在使用機器層級虛擬化管理程式的 s390 系統上，PCI 裝置一律會透過 PCI 傳遞形式來存取，該傳遞基本上是在每個 PCI 功能粒度上運作。這也反映在 s390 PCI 熱插拔驅動程式中，該驅動程式為個別 PCI 功能建立熱插拔插槽。因此，它的 reset_slot（） 函數是 zpci_hot_reset_device（） 的包裝器，也會重置單個函數。目前，pci_create_slot（） 會將相同的pci_slot物件指派給多功能裝置。這種方法在僅將虛擬功能作為單獨的 PCI 域公開給操作系統的 s390 系統上運行良好。自提交 44510d6fa0c0 （s390/pci：處理多功能） 以來，s390 支援將多功能 PCI 裝置分組在共用 PCI 網域中，以公開其拓撲。這會在透過熱插拔驅動程式的 slot_reset（） 介面重設功能時產生問題。嘗試透過熱插拔驅動程式重設功能時，共用插槽指派會導致重設錯誤的功能，而不是預期的功能。當我們為函數建立 pci_slot 物件時，它也會洩漏記憶體，但沒有在 pci_slot_release（） 中正確釋放它。為結構pci_slot新增旗標，以允許透過虛擬化管理程式管理的功能使用每個函式的 PCI 插槽，這會在保留拓撲的同時公開個別 PCI 功能。由於我們可以將所有 8 位元用於插槽「編號」（對於 ARI 設備），因此更改插槽「編號」u16 以考慮特殊值 PCI_SLOT_PLACEHOLDER 和 PCI_SLOT_ALL_DEVICES。（CVE-2026-89795）

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

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

  - F2FS：驗證MOVE_RANGE目的地大小，F2FS_IOC_MOVE_RANGE在更新i_size之前檢查來源範圍，但不檢查目的地端。來源漏洞可能會暴露這一點：__clone_blkaddrs（） 跳過NULL_ADDR條目並傳回成功，因此調用方仍然可以使用未選中的 pos_out + len 來擴展目標 inode。拒絕目的地溢位，並在擴充目的地 inode 之前使用 inode_newsize_ok（）。
    (CVE-2026-89840)

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

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

  - USB： gadget： f_fs：修正 AIO 錯誤路徑中的釋放後使用 在 ffs_epfile_write_iter（） 和 ffs_epfile_read_iter（） 中，當 ffs_epfile_io（） 因 -EIOCBQUEUED 以外的錯誤而失敗時，io_data 結構 （'p'） 會被釋放。然而，對於 AIO 操作，kiocb 取消功能已經布防，kiocb->private 設定為「p」。如果並行取消作業 （例如 sys_io_cancel（）） 在 ffs_epfile_io（） 失敗之後但在函式釋放 'p' 之前執行，則當取消處理常式存取釋放的指標時，可能會發生釋放後使用。若要安全地修正此爭用情形，我們必須正確解除取消。叫用「kiocb->ki_complete（）」正是透過取得「ctx->ctx_lock」並安全地從活動序列中移除 kiocb 來做到這一點。這樣做可以確保並行io_cancel無法再發現 kiocb，從而有效地關閉爭用窗口。然後，我們傳回 -EIOCBQUEUED 以通知 VFS 層 kiocb 已被消耗，它應該避免再次嘗試完成請求或觸發後續完成處理常式。（CVE-2026-90044）

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

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

  - scsi：qla2xxx：qla2x00_update_fru_versions（） qla2x00_update_fru_versions（） 中的綁定影像計數會將使用者提供的 BSG 要求複製到固定的 256 位元組堆疊緩衝區 （bsg[DMA_POOL_SIZE]） 中，然後在內嵌於該緩衝區中的 qla_image_version 陣列上反覆運算清單>計數時間，每次反覆運算都會推進影像指標。count 直接取自使用者輸入，沒有上限，而只有 （DMA_POOL_SIZE - sizeof（list->count）） / sizeof（struct qla_image_version） = 6 個項目實際適合。較大的計數會將圖像指標從堆疊緩衝區的末端走出，讀取相鄰的核心堆疊記憶體並透過 qla2x00_write_sfp（） 將其傳送到裝置。拒絕宣告計數不適合緩衝區的要求。
    (CVE-2026-89858)

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

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

  - drm/amd/display：修正 GPU 重設錯誤路徑上的dc_lock洩漏 在 GPU 重設時，dm_suspend（） 會dc_lock並留待 dm_resume（） 刪除。如果 amdgpu_dm_commit_zero_streams（） 或 dm_dmub_hw_init（） 失敗，則函式會傳回仍持有的鎖定。然後會略過相符的履歷路徑，因此每個稍後的dc_lock都會停擺。釋放快取的 DC 狀態並解除鎖定，再傳回錯誤。（CVE-2026-89820）

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

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

  - media：chips-media：wave5：stop_streaming時新增逾時呼叫stop_streaming時，在某些情況下可能會發生無限迴圈。新增佇列狀態的有界輪詢：迴圈直到佇列耗盡，在輪詢之間短暫休眠，並在VPU_DEC_STOP_TIMEOUT過後退出。（CVE-2026-89868）

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

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

  - KVM：x86：hyper-v：限制計時器期限以避免即時鎖定 修正使用者空間或客體可以透過整數溢位將 Hyper-V 合成計時器編程為過去有期限的問題，從而阻止 CPU 取得進展並觸發 RCU 停止。Hyper-V 的 SynIC 會向客體公開 4 個每個 vCPU 的合成計時器，這些計時器由 KVM 模擬。每個都透過 HV_X64_MSR_STIMERi_CONFIG 和 HV_X64_MSR_STIMERi_COUNT MSR 進行程式設計。根據 CONFIG，COUNT 代表絕對到期時間或定期計時器的週期，兩者都以 100ns 刻度表示。這些計時器可由客體 （WRMSR） 和主機 （KVM_SET_MSRS） 設定。啟用計時器後，stimer_start（） 將 COUNT 轉換為絕對單調的截止日期並布防 hrtimer。如果 COUNT 設為接近 U64_MAX 的值，則期限計算可能會溢位。ktime_add_ns（ktime_now， 100 * （stimer->exp_time - time_now）） 這可能會導致 CPU 活鎖。stimer_start（） 透過 hrtimer_start（） 為計時器提供過去的截止日期，這會導致它立即觸發。然後，stimer 回呼會引發KVM_RQ_HV_STIMER，目的是讓 KVM 在下一個 vCPU 客體輸入時傳遞合成中斷。然後，一旦使用者空間發出KVM_RUN，vcpu_enter_guest（） 就會使用請求，並呼叫 kvm_hv_process_stimers（）。一旦截止日期過去，這通常會透過 stimer_expiration（） 停用計時器。然而，截止日期比較是在 KVM 參照計數器和 stime->exp_time 之間進行的，這是一個接近 U64_MAX 的大值，因此幾千年內從未發生過這種情況。然後kvm_hv_process_timers（） 透過 stimer_start（） 重新武裝計時器，因為它沒有被停用，它再次立即觸發。在進入客體之前，kvm_vcpu_exit_request（） 會檢查 kvm_request_pending（），由於新引發的KVM_REQ_HV_STIMER，因此傳回 true。然後 vcpu_enter_guest（） 中止客體條目，提前返回 vcpu_run（），然後再次循環回 vcpu_enter_guest（），重新啟動循環。由於此迴圈中沒有手動產量，因此具有 SCHED_FIFO 的任務可能會使 RCU 寬限期 kthread 不足，這會暴露 syzcaller 發現的停頓： rcu： INFO： rcu_preempt偵測到 CPU 上的停頓/任務： rcu： （由 1， t=10502 jiffies， g=14269， q=1142 ncpus=2 偵測到） rcu： 看到的所有 QS，最後rcu_preempt kthread 活動 10500 （4294965239-4294954739）， jiffies_till_next_fqs=1， root ->qsmask 0x0 rcu：rcu_preempt kthread 餓了 10500 次！g14269 f0x2 RCU_GP_WAIT_FQS（5） ->state=0x0 ->cpu=0 rcu： 除非 rcu_preempt kthread 獲得足夠的 CPU 時間，否則 OOM 現在是預期行為。( ... )呼叫追蹤： <IRQ> __run_hrtimer kernel/time/hrtimer.c：1773 [內嵌] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c：1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c：1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c：1045 [內嵌] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c：1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c：1056 [內嵌] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c：1056 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h：697 RIP：
    0010：__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h：152 [內嵌] RIP：
    0010：_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c：194 代碼：74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 <e8> 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36RSP：0018：ffffc900040a7320 EFLAGS：00000206 RAX：5de15cb931505900 RBX：0000000000000a06 RCX：5de15cb931505900 RDX：0000000000000007 RSI：
    ffffffff8daa9dc3 RDI：0000000000000001 RBP：ffffc900040a73b0 R08：ffffffff8fc3d0 ---truncated--- （CVE-2026-89927）

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

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

  - dmaengine： dw-edma：在請求 IRQ 之前初始化 IRQ 資料 dw_edma_irq_request（） 在 dw_edma_channel_setup（） 填入反向指標之前將結構dw_edma_irq傳遞給 request_irq（）。因此，共用中斷可以在 dw_irq->dw 仍為 NULL 的情況下進入處理常式，導致 NULL 指標解除參照。在安裝每個處理常式之前，先設定返回指標。（CVE-2026-89993）

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

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

  - drm/amd/display：修正 get_estimated_bw（） 中的除以零 get_estimated_bw（） 除以 link->dpia_bw_alloc_config.bw_granularity，該除法由 reset_bw_alloc_struct（） 歸零，並且僅在處理完DP_TUNNELING_BW_ALLOC_CAP_CHANGED後填充。DPCD 中斷處理常式 link_dp_dpia_handle_bw_alloc_status（） 會在設定DP_TUNNELING_ESTIMATED_BW_CHANGED時呼叫 get_estimated_bw（），與DP_TUNNELING_BW_ALLOC_CAP_CHANGED是否曾經針對該連結觸發無關。連線的 USB4/DPIA 通道裝置在報告功能變更之前報告估計頻寬變更，會驅動此 IRQ 路徑中的除以零。link_dpia_send_bw_alloc_request（） 已經保護了同一個bw_granularity部門;在此處新增相同的防護裝置，而不是引入新模式。（從提交 f2a961457c33dc34223aad5c9e8971de34a4eed3 中挑選）（CVE-2026-90035）

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

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

  - dma-buf： dma-heap：在 copy_to_user（） DMA_HEAP_IOCTL_ALLOC成功配置 dma-buf 並透過 dma_buf_fd（） -> fd_install（） 將 fd 安裝到調用方的 fd 表之前，不要發布 dma_heap_ioctl（） 將結果複製回使用者空間。如果尾端 copy_to_user（） 失敗，使用者空間永遠不會學習 fd 編號，但 fd（和基礎 dma-buf 參照）已經對同一進程中的其他執行緒可見，並且在進程的生命週期內會洩漏。在失敗路徑修正中明顯關閉它是不安全的：一旦 fd_install（） 運行，另一個執行緒已經可以 dup（） fd，透過 SCM_RIGHTS 發送它，或 close（） 它並讓其編號被重複使用，因此來自 ioctl 路徑的後續 close_fd（） 可以對不相關的檔案進行操作。Christian Knig 在 v1 [1] 中指出了這一點。重組配置路徑，使 fd_install（） 成為成功 ioctl 的最後一個、不可失敗的步驟： 1. heap->ops->allocate（） 建立dma_buf。2. get_unused_fd_flags（） 在調用方的 fd 表中保留一個 fd 號碼而不發布，因此其他執行緒無法觀察到它。3. copy_to_user（） 將 fd 編號傳遞到使用者空間;失敗時，會傳回 fd 並帶有 put_unused_fd（），並將dma_buf參照與 dma_buf_put（） 一起刪除，從而不留下任何使用者可見的狀態。4. dma_buf_fd_install（） 發布 FD 並發出 trace_dma_buf_fd 追蹤點
    -- 從這裡開始，ioctl 不能失敗。dma-buf.c 中引入了一個新的 dma_buf_fd_install（） 協助程式，用於將 fd_install（） 與 DMA_BUF_TRACE（） 呼叫包裝在一起，從而保留 dma_buf_fd（） 提供的匯出追蹤。dma_heap_ioctl_allocate（） 會重構為直接傳回結構 dma_buf * （失敗時傳回 ERR_PTR），因此呼叫端會在步驟 3 和 4 中保留 dmabuf 參照。步驟 3 的故障很容易從使用者空間到達：傳遞一個位於頁面中的結構dma_heap_allocation_data，該頁面的保護被翻轉為在 copy_from_user（） 和 copy_to_user（） 之間PROT_READ（例如，透過 mprotect（））。
    在此變更之前，每個此類 ioctl 都會洩漏一個 dmabuf fd;之後，fd 表在失敗時保持不變，只有 /dev/dma_heap/<name> 保持開啟狀態。沒有 UAPI 或堆積驅動程式介面變更。[1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ （CVE-2026-89996）

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

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

  - scsi：megaraid_sas：將 NVMe 要求大小限制為 PRP 鏈框架 megasas_make_prp_nvme（） 會在 cmd->sg_frame 中建立命令的 PRP 清單，這是實例>max_chain_frame_sz位元組的 DMA 集區緩衝區，傳輸的每個 NVMe 頁面花費一個項目，鏈指標的緩衝區每頁花費一個項目。迴圈會一直執行，直到描述傳輸為止，並且永遠不會檢查緩衝區繫結。max_hw_sectors直接來自驅動器固件報告的 MDTS。在具有大型 MDTS 的驅動器上，唯一將列表保留在緩衝區內的是塊層默認值 1280 KiB，它需要 320 個項目，這些項目適合 4 KiB 框架，因為它可容納 512 個。但由於提交 9b8b84879d4a （block： 增加 BLK_DEF_MAX_SECTORS_CAP），因此預設值為 4 MiB，而此類傳輸需要 1025 個項目，因此清單會在框架結尾後運行一整頁： sd 1：0：1：0： [sdb] tag#630 頁面邊界 ptr_sgl： 0x00000000ba62d13f 錯誤：無法處理位址的頁面錯誤：ff663bcb81e7c000 #PF：核心模式下的主管寫入存取權限 #PF： error_code（0x0002） - 不存在頁面 RIP：0010：megasas_build_and_issue_cmd_fusion+0xeaa/0x1870 [megaraid_sas] 如果框架之後的頁面恰好被映射，則溢位不會出錯，而是會無訊息地損毀相鄰的集區項目，這是另一個正在進行的命令的 PRP 清單。上限max_hw_sectors鏈框架可以描述的內容，減去一頁，用於不從頁面邊界開始的傳輸，因此需要多一個條目。
    這是提交 04631f55afc5 的megaraid_sas對應部分 （scsi：mpt3sas：將 NVMe 請求大小限制為 2 MiB），但從 max_chain_frame_sz 派生限制，而不是硬式編碼。（CVE-2026-90008）

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

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

  - media：usbtv：當 ALSA 卡存在時，讓裝置保持活動狀態 ALSA PCM 回呼會將驅動程式狀態儲存在 pcm->private_data 中。開啟的 PCM 檔案可能比 USB 中斷連線還要長，因為 usbtv_audio_free（） 使用 snd_card_free_when_closed（）。然後，中斷連接路徑可以在 ALSA 釋放子資料流之前刪除 V4L2 裝置參照並釋放結構 usbtv，因此稍後的關閉取消參照會在 snd_usbtv_pcm_close（） 中釋放記憶體。獲取 ALSA 卡的 V4L2 裝置參照，並將其從卡private_free回呼中刪除。這會使結構 usbtv 保持有效，直到 ALSA 關閉剩餘檔案並釋放卡片為止。（CVE-2026-90032）

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

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

  - i2c：mux：修正配接器新增失敗上的通道節點洩漏 i2c_mux_add_adapter（） 在註冊新的配接器之前，會參照裝置樹狀結構通道節點。如果配接器登錄失敗，錯誤路徑會釋放專用資料，而不會捨棄該參照。釋放專用資料之前，請釋放通道節點。（CVE-2026-89982）

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

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

  - media：airspy：斷開連接時使用 vb2_video_unregister_device（） 修正 NULL deref airspy_disconnect（） 在 v4l2_lock 下清除 s->udev，但之後 airspy_stop_streaming（） 無條件調用 airspy_ctrl_msg（） 和 airspy_free_stream_bufs（）。如果串流使用者在中斷連線後關閉裝置，則 stop_streaming（） 會執行並取消參照 NULL s->udev： airspy_stop_streaming（） airspy_ctrl_msg（s， CMD_RECEIVER_MODE， 0， 0， NULL， 0） usb_sndctrlpipe（s->udev， 0） /* NULL 解除參照 */ airspy_free_stream_bufs（s） usb_free_coherent（s->udev， ...） /* NULL 解除參照 */ airspy 驅動程式在其file_operations中使用 vb2_fop_release（）， 因此，將 video_unregister_device（&s->vdev） 替換為 vb2_video_unregister_device（&s->vdev） 並在清除 S->udev 之前移動它。vb2_video_unregister_device（） 會釋放 vb2 佇列，如果串流處於作用中狀態，則 vb2 佇列會同步執行 airspy_stop_streaming（），因此 URB、一致的 DMA 資料流緩衝區和硬體停止控制訊息都會在 s->udev 仍然有效時執行。
    vb2_video_unregister_device（） 在內部鎖定 vdev->queue->lock （vb_queue_lock），而 stop_streaming（） 鎖定v4l2_lock，因此取消註冊序列周圍的先前外部 mutex_lock（&s->vb_queue_lock） / mutex_lock（&s->v4l2_lock） 對將自行鎖死並已被刪除。s->udev = NULL 周圍的簡短v4l2_lock關鍵區段會保留，因此任何仍保留檔案描述元的 ioctl 路徑都會看到一致的狀態。在 （CVE-2026-89901） 處https://sashiko.dev/自動審查 INV-003 系列所發現的問題

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

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

  - media：chips-media：wave5：在設定 EOS 旗標之前恢復裝置 設定 EOS 旗標會透過 send_firmware_command（） 與韌體交談，韌體會存取 VPU 暫存器。STREAMOFF 路徑 （wave5_vpu_dec_job_abort（）） 和 V4L2_DEC_CMD_STOP 路徑 （wave5_vpu_dec_stop（）） 都可以在設備運行時暫停時運行，因此這些暫存器訪問會擊中斷電的硬件，並且 SoC 會引發非同步 SError，從而使內核恐慌：CPU3 上的 SError 中斷，代碼 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] 在 EOS 韌體命令周圍使用 pm_runtime_resume_and_get（） 恢復裝置，然後使用 pm_runtime_put_autosuspend（） 將其釋放，以符合 wave5_vpu_dec_device_run（） 中已經完成的運行時 PM 處理。
    (CVE-2026-89866)

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

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

  - s390/vfio-ap：在佇列探測期間修正 status_show（） 中的 NULL 解除參照 當 vfio_ap_mdev_probe_queue（） 建立 sysfs 屬性群組時，佇列的驅動程式資料尚未設定。因此，並行讀取 'status' 屬性可以呼叫 dev_get_drvdata（） 並獲得 NULL，然後將其直接傳遞給 vfio_ap_mdev_for_queue（），其中 q->apqn 被無條件取消參照，從而導致 NULL 指標解除參照。在呼叫 sysfs_create_group（） 之前取得更新鎖定來修正此問題。status_show（） 函式會在讀取驅動程式資料之前取得guests_lock，因此任何並行讀取都會阻塞，直到呼叫 dev_set_drvdata（） 並釋放更新鎖定為止。作為獎勵，分配後不再需要從佇列結構中讀取 APQN，它可以在分配前直接從 apdev 讀取並儲存在局部變數中，然後在分配成功後將其分配給 q->apqn。
    (CVE-2026-89955)

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

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

  - scsi：qla2xxx：釋放要求佇列前靜止回應 IRQ qla2xxx_delete_qpair（） 會在回應佇列之前刪除要求佇列。qla25xx_delete_req_que（） 釋放請求佇列記憶體 （qla25xx_free_req_que（） 中的 kfree（req）），但回應佇列 MSI-X 只會稍後在 qla25xx_free_rsp_que（） 中釋放。在該視窗中，回應中斷仍可觸發，qla2xxx_msix_rsp_q（） 佇列 qpair->q_work，而 qla_do_work（） -> qla24xx_process_response_queue（） 解除參照現已釋放的 rsp->req （LOGINOUT/CT/ELS 項目和狀態路徑），這是釋放後使用。為 qpair 拆卸新增的 cancel_work_sync（） 位於回應自由路徑中，該路徑會在請求佇列已釋放後執行，因此它不會保護 rsp->req。在刪除要求佇列之前，釋放 response-queue 中斷並排清 qpair->q_work，以便任何延遲完成都無法到達釋放的要求佇列。清除have_irq會使後續qla25xx_free_rsp_que（）跳過其free_irq（），並保留韌體佇列刪除順序（請求然後回應）;要求刪除信箱會在預設向量上完成，而且不會因為提前捨棄 QPerine 回應中斷而影響。（CVE-2026-89848）

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

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

  - scsi：bsg：上限io_uring感應複製到max_response_len完成將 scmd->sense_len 複製到使用者回應緩衝區，而不接受max_response_len。在有效意義之後，中間層將sense_len設定為實際長度（最多 SCSI_SENSE_BUFFERSIZE），因此較小的使用者緩衝區被溢出。（CVE-2026-90010）

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

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

  - i2c： core：修正轉接器移除時的 debugfs UAF i2c_del_adapter（） 會在取消註冊轉接器裝置之前釋放轉接器的 debugfs 目錄，但 new_device sysfs 屬性在 device_del（） 之前保持可寫入狀態。刪除的寫入爭用仍會到達 i2c_device_probe（），這會將釋放的 adap->debugfs 傳遞給 debugfs_create_dir（） 作為新用戶端的父項： 錯誤：KASAN：lookup_noperm_common+0x407/0x430 中的 slab-use-after-free 透過任務 syz.0.61/6090 在 addr ffff88803ef87810 讀取大小 4 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 在技術上可以建立執行 i2c_deregister_clients 之後的用戶端。該客戶端永遠不會被取消註冊並使wait_for_completion掛起。移除 i2c_del_adapter（） 開頭的 new_device 屬性來關閉視窗。
    device_remove_file（） 將耗盡所有剩餘的用戶端。（CVE-2026-89983）

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

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

  - LoongArch：修正 acpi_package_ids[] 陣列溢位 使用 LoongArch virt 機器，典型設定是每個通訊端一個核心，一個 VM 上最多有 256 個通訊端（套件）。使用 PPTT acpi 表時，陣列 acpi_package_ids[] 將溢位。此處更改數組大小 acpi_package_ids[] ，最大值為 MAX_PACKAGES 和 KVM_MAX_VCPUS。（CVE-2026-89904）

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

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

  - LoongArch：避免沒有探測的搶佔計數反向溢位 LoongArch 使用 break 11 作為 Kprobes 越界執行指令之後放置的中斷點。由於使用者空間可以發出相同的中斷指令，因此當沒有目前探測時，do_bp（） 可以到達 kprobe_singlestep_handler（）。在此情況下，處理常式實際上傳回 false，但它首先呼叫 preempt_enable_no_resched（）。對應的 preempt_disable（） 是由 kprobe_breakpoint_handler（） 在實際 Kprobe 命中時完成的，因此它沒有在此處運行。因此，普通使用者空間中斷點 （代碼 11） 會使目前任務的搶佔計數反向溢位。這也會使 in_interrupt（） 在任務排程之前傳回 true。一個明顯的後果是通訊端 cgroup 歸因：cgroup_sk_alloc（） 將分配視為中斷上下文，並將通訊端分配給根 cgroup。然後，從 SIGTRAP 處理常式開啟的通訊端可以避免附加到任務自己的 cgroup 的 BPF_CGROUP_INET_SOCK_CREATE 原則。一旦 kprobe_running（） 報告沒有作用中的探查，請立即返回。同樣的檢查出現在原始 LoongArch Kprobes 系列的 [PATCH v10 2/4] 中，但在該功能到達主線之前被刪除。（CVE-2026-89902）

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

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

  - USB： gadget：修正 gadget_dev_ioctl（） 中的 NULL 指標解除參照 gadget_dev_ioctl（） 在取得 dev->lock 之前讀取 dev->gadget，但在取得鎖定後檢查 dev->state。因此，並行繫結可能會變更這些作業之間的裝置狀態，這可能會讓 ioctl 留下過時的 NULL 小工具指標，並在 gadget->ops->ioctl 造成 NULL 指標解除參照。在按住 dev->lock 的同時讀取 dev->gadget，以便一致地取樣小工具指標和裝置狀態。（CVE-2026-90020）

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

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

  - ALSA： usb-audio：修正 snd_usbmidi_us122l_output（） 中的 OOB 寫入 snd_usbmidi_us122l_output（） 對任何比高速慢的東西選擇 2 的計數，並且從不將其與 ep->max_transfer 相關聯。URB 緩衝區恰好保留 max_transfer 個位元組，因此宣告一個位元組大量端點的裝置會從 snd_rawmidi_transmit（） 中獲取兩個位元組，而填充其餘部分的 memset 會在 int 中計算 1 - 2 並包裝為 SIZE_MAX。
    只有 0x800e 和 0x800f 釘選到 9 個位元組。0x0644：0x8021 的 US-122MKII 降至默認值並採用 usb_maxpacket（），USB 內核僅向下夾緊。此檔案中的 akai 和 novation 輸出操作最近被賦予了相同的保護。在這裡做同樣的事情。（CVE-2026-90033）

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

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

  - LoongArch： KVM：如果 kvm_init（） 失敗，則釋放初始化資源 kvm_loongarch_init（） 呼叫 kvm_loongarch_env_init（） 以配置每個 CPU kvm_context （vmcs） 和 kvm_loongarch_ops 並註冊 perf 回呼，然後呼叫 kvm_init（）。如果 kvm_init（） 失敗，則直接傳回其結果，但由於 module_init（） 不會在失敗時執行 module_exit（） 內容，因此永遠不會呼叫 kvm_loongarch_env_exit（），並且這些資源會洩漏。因此，當 kvm_init（） 失敗時呼叫 kvm_loongarch_env_exit（），與 riscv_kvm_init（） 使用的失敗時拆卸模式相符。（CVE-2026-89909）

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

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

  - KVM： nVMX：確保在 VM-Exit 上清除 KVM_REQ_GET_NESTED_STATE_PAGES 模擬巢狀 VM-Exit 時，請務必檢查並清除KVM_REQ_GET_NESTED_STATE_PAGES以確保要求遭到清除，即使 KVM 是使用 CONFIG_KVM_HYPERV=n 建置的，因為 KVM 巧妙地依賴檢查來清除旗標，從而避免重複對應 vmcs12 頁面， 例如，如果 KVM 設法在不處理請求的情況下從 VM-Enter 保釋，然後模擬 VMLAUNCH 或 VMRESUME。（CVE-2026-89931）

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

ID	名稱	嚴重性
346731	Linux Distros 未修補弱點：CVE-2026-89847	critical
346730	Linux Distros 未修補弱點：CVE-2026-89987	medium
346729	Linux Distros 未修補弱點：CVE-2026-89828	medium
346728	Linux Distros 未修補弱點：CVE-2026-89977	medium
346727	Linux Distros 未修補弱點：CVE-2026-90009	high
346726	Linux Distros 未修補弱點：CVE-2026-89947	high
346725	Linux Distros 未修補弱點：CVE-2026-89929	high
346724	Linux Distros 未修補弱點：CVE-2026-89837	medium
346723	Linux Distros 未修補弱點：CVE-2026-89999	high
346722	Linux Distros 未修補弱點：CVE-2026-89883	high
346721	Linux Distros 未修補弱點：CVE-2026-89853	high
346720	Linux Distros 未修補弱點：CVE-2026-90031	high
346719	Linux Distros 未修補弱點：CVE-2026-90018	high
346718	Linux Distros 未修補弱點：CVE-2026-89944	medium
346717	Linux Distros 未修補弱點：CVE-2026-89964	medium
346716	Linux Distros 未修補弱點：CVE-2026-89978	medium
346715	Linux Distros 未修補弱點：CVE-2026-89915	critical
346714	Linux Distros 未修補弱點：CVE-2026-89879	medium
346713	Linux Distros 未修補弱點：CVE-2026-89920	high
346712	Linux Distros 未修補弱點：CVE-2026-89992	high
346711	Linux Distros 未修補弱點：CVE-2026-89989	medium
346710	Linux Distros 未修補弱點：CVE-2026-89946	medium
346709	Linux Distros 未修補弱點：CVE-2026-90023	medium
346708	Linux Distros 未修補弱點：CVE-2026-89836	high
346707	Linux Distros 未修補弱點：CVE-2026-89827	medium
346706	Linux Distros 未修補弱點：CVE-2026-89795	high
346705	Linux Distros 未修補弱點：CVE-2026-89840	high
346704	Linux Distros 未修補弱點：CVE-2026-90044	high
346703	Linux Distros 未修補弱點：CVE-2026-89858	high
346702	Linux Distros 未修補弱點：CVE-2026-89820	medium
346701	Linux Distros 未修補弱點：CVE-2026-89868	medium
346700	Linux Distros 未修補弱點：CVE-2026-89927	high
346699	Linux Distros 未修補弱點：CVE-2026-89993	medium
346698	Linux Distros 未修補弱點：CVE-2026-90035	medium
346697	Linux Distros 未修補弱點：CVE-2026-89996	high
346696	Linux Distros 未修補弱點：CVE-2026-90008	high
346695	Linux Distros 未修補弱點：CVE-2026-90032	high
346694	Linux Distros 未修補弱點：CVE-2026-89982	high
346693	Linux Distros 未修補弱點：CVE-2026-89901	medium
346692	Linux Distros 未修補弱點：CVE-2026-89866	medium
346691	Linux Distros 未修補弱點：CVE-2026-89955	medium
346690	Linux Distros 未修補弱點：CVE-2026-89848	high
346689	Linux Distros 未修補弱點：CVE-2026-90010	high
346688	Linux Distros 未修補弱點：CVE-2026-89983	high
346687	Linux Distros 未修補弱點：CVE-2026-89904	high
346686	Linux Distros 未修補弱點：CVE-2026-89902	high
346685	Linux Distros 未修補弱點：CVE-2026-90020	medium
346684	Linux Distros 未修補弱點：CVE-2026-90033	high
346683	Linux Distros 未修補弱點：CVE-2026-89909	medium
346682	Linux Distros 未修補弱點：CVE-2026-89931	medium

偵測

Nessus 的 Misc. 系列

critical

medium

medium

medium

high

high

high

medium

high

high

high

high

high

medium

medium

medium

critical

medium

high

high

medium

medium

medium

high

medium

high

high

high

high

medium

medium

high

medium

medium

high

high

high

high

medium

medium

medium

high

high

high

high

high

medium

high

medium

medium