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

  - RDMA/erdma：修正移除時的 CEQ tasklet 釋放後使用 每個 CEQ 中斷處理常式僅排程 eqc->tasklet。tasklet 呼叫 erdma_ceq_completion_handler（），它透過 get_next_valid_eqe（） 讀取 DMA 相干的 EQ 環，並透過 notify_eq（） 更新 eq->dbrec。erdma_ceqs_uninit（） 釋放每個 CEQ IRQ，然後銷毀其 EQ。 free_irq（） 會阻止另一個硬 IRQ 並等待正在進行的處理常式，但它不會清空處理常式已排程的 tasklet。因此，在 erdma_eq_destroy（） 釋放 eq->qbuf 或 eq->dbrec 之後，tasklet 可以存取它們。清除 ceq_cb->ready 不會與在 erdma_ceq_completion_handler（） 開始時已通過檢查的 tasklet 同步。在 free_irq（） 之後，當沒有處理常式可以再次排程它時，以及 erdma_ceq_uninit_one（） 釋放 EQ 緩衝區之前，終止 tasklet。（CVE-2026-92514）

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

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

  - RDMA/bnxt_re：在 DBR/切換頁面 mmap bnxt_re_mmap（） 上清除VM_MAYWRITE拒絕 DBR_PAGE 和 TOGGLE_PAGE mmap 旗標的VM_WRITE，但唯讀映射仍可保留VM_MAYWRITE。稍後會使用 mprotect（PROT_WRITE） 進行升級。這可以繞過僅在 mmap 時執行的寫入檢查。在共用 DBR/toggle-page 分支的 vm_insert_page（） 之前清除 VM_MAYWRITE，以符合現有原則，即這些頁面不需要使用者空間寫入。（CVE-2026-92495）

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

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

  - 信箱：riscv-sbi-mpxy：驗證 RPMI 通知長度 SBI 傳回值控制從共用記憶體複製到 RPMI 通知緩衝區的位元組數。在該副本之前，不會針對協商的共用記憶體大小進行驗證。事件遍歷器也會使用反向迴圈條件，並可以檢查簡短的事件記錄。在複製通知之前先驗證完整的通知長度，僅在完整的事件標頭保留時反覆運算，並在宣告的事件承載超出複製的通知資料時停止。（CVE-2026-90191）

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

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

  - ALSA： core：修正 snd_card_do_free（） 中的釋放後使用當 devres 管理的音效卡未綁定，而使用者空間應用程式仍保留開啟的檔案描述元時，在 snd_card_do_free（） 中偵測到釋放後使用。對於託管卡，記憶體是使用 devres_alloc（） 配置的，其釋放函數設定為 __snd_card_release（），它會呼叫 snd_card_free（）。當裝置解除綁定時，解除綁定執行緒會呼叫 snd_card_free（），這會刪除對卡片裝置的參照。如果使用者執行緒仍有開啟的檔案描述元，則參照計數不會達到零，且解除綁定執行緒會在 wait_for_completion（&released） 上封鎖。當使用者執行緒關閉檔案描述元時，它會刪除最終參照，並叫用裝置釋放回呼 release_card_device（），呼叫 snd_card_do_free（） 。
    snd_card_do_free（） 執行清理並呼叫 complete（card->release_completion）。這會喚醒從 snd_card_free（） 和 __snd_card_release（） 傳回的解除綁定執行緒。然後，devres 核心會立即釋放包含 snd_card 結構的記憶體區塊。同時，使用者執行緒繼續在 snd_card_do_free（） 中執行，並評估「if （！card->managed）」。它從剛由解除綁定執行緒釋放的snd_card結構中讀取「託管」布林值，從而觸發 KASAN 釋放後使用。在呼叫 complete（） 之前，透過在本機變數中快取 card->managed 的值來修正此問題。如此可確保在喚醒解除繫結執行緒之後，不會取消參照卡片指標，並可能釋放卡片。
    錯誤： KASAN：snd_card_do_free sound/core/init.c：604 中的釋放後使用 [內聯] 錯誤： KASAN：release_card_device+0x1ab/0x1b0 sound/core/init.c：153 中的釋放後使用 由任務 syz-executor130/5857 在 addr ffff8881912ec909 讀取大小 1 呼叫追蹤： <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c：120 print_address_description+0x55/0x1e0 mm/kasan/report.c：378 print_report+0x58/0x70 mm/kasan/report.c：482 kasan_report+0x117/0x150 mm/kasan/report.c：595 snd_card_do_free sound/core/init.c：604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c：153 device_release+0xc4/0x1f0 drivers/base/core.c：-1 kobject_cleanup lib/kobject.c：689 [inline] kobject_release lib/kobject.c：720 [inline] kref_put include/linux/kref.h：65 [inline] kobject_put+0x222/0x550 lib/kobject.c：737 snd_card_file_remove+0x331/0x390 sound/core/init.c：1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c：2986 __fput+0x418/0xa50 fs/file_table.c：512 fput_close_sync+0x11f/0x240 fs/file_table.c：617 __do_sys_close fs/open.c：1511 [內嵌] __se_sys_close fs/open.c：1496 [內嵌]
    __x64_sys_close+0x7e/0x110 fs/open.c：1496 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> （CVE-2026-90198）

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

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

  - iommu/vt-d：修正 RID 網域取代時的iopf_refcount洩露 intel_iommu_attach_device（） 會為新網域啟用 IOPF，但絕不會為舊網域停用 IOPF。在函式開頭呼叫的 device_block_translation（） 會拆除轉換，但不會觸及任何 IOPF 狀態;正是出於這個原因，blocking_domain_attach_dev（） 必須在叫用它之前明確調用它 iopf_for_domain_remove（）。
    identity_domain_attach_dev（） 也有同樣的問題。其註解聲稱不需要 PRI 處理，因為裝置已處於封鎖狀態，但封鎖狀態和 IOPF 參考計數彼此獨立。因此，將具有iopf_handler的網域替換為 RID 層級的另一個網域，會在資訊>iopf_refcount中洩漏參照。計數永遠不會降回零，因此永遠不會調用 iopf_queue_remove_device（），並且 iommu_disable_pci_pri（） 會在釋放裝置時觸發其 WARN_ON（info->iopf_refcount）。PASID 路徑已透過 iopf_for_domain_replace（） 正確處理此問題;轉換兩個 RID 路徑以執行相同的動作。使用取代協助程式而不是裸移除會在停用之前保留啟用，因此參照計數不會暫時達到零，並將裝置從 IOPF 佇列中收回。（CVE-2026-90242）

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

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

  - wifi： ath12k：修正 ath12k_wmi_process_csa_switch_count_event（） 中的過度讀取 WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT沒有原則項目，因此剖析基礎架構不會強制執行事件結構的最小長度。此外，num_vdevs欄位直接取自韌體，並用作綁定在 vdev_ids 陣列上的迴圈，而不檢查它是否適合 TLV 有效負載。任一狀況都可能導致越界讀取。新增 WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT 的 TLV 原則項目，以便剖析基礎架構強制執行固定大小事件結構的最小長度。新增協助程式 ath12k_wmi_tlv_data_len（），以從其資料指標之前的標頭復原已剖析 TLV 的承載長度。在 ath12k_wmi_process_csa_switch_count_event（） 中使用它來在循環之前綁定num_vdevs。僅測試編譯檔案。(CVE-2026-90408)

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

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

  - cpufreq： amd-pstate-ut： 當 amd-pstate 驅動程式未啟用時，跳過測試 在 intel 平台上amd_pstate_ut modprobe 時，可能會發生當機問題。amd_pstate_ut：1 amd_pstate_ut_acpi_cpc_valid成功！amd_pstate_ut：2 amd_pstate_ut_check_enabled成功！錯誤：核心 NULL 指標解除參照，位址：
    0000000000000080 #PF：核心模式下的主管讀取存取權 #PF：error_code（0x0000） - 不存在頁面 PGD 0 P4D 0 哎呀：0000 [#1] SMP NOPTI CPU：0 PID：20300 通訊：modprobe Kdump：已載入 污染：G O 6.6.0-0010.rc1.ctl4.x86_64 #1 硬體名稱：烽火 R2200 通信 V5/Xeon 主板，BIOS 3.1a 2020 年 2 月 24 日 RIP：
    0010：amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] 呼叫追蹤： <TASK> amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ？ __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ？ kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> 新增狀態偵測至 AMD pstate 驅動程式以防止amd_pstate_ut 驅動程式，無需在非 AMD 平台上進行測試。（ML：調整標題）（CVE-2026-92493）

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

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

  - cxl/mbox：將信箱輸出分配限制為承載大小CXL_MEM_SEND_COMMAND將使用者的 in.size 限制為信箱承載大小，但保留 out.size 不受限制，然後 cxl_mbox_cmd_ctor（） 呼叫 kvzalloc（out.size）。一個大的 out.size 驅動了巨大的分配，高於INT_MAX它會警告和污染，並且當 panic_on_warn=1 時，它會感到恐慌。傳輸 __cxl_pci_mbox_send_cmd（） 已經將回應副本限制為 min（out.size， payload_size， device len），因此輸出緩衝區永遠不會寫入超過 payload_size。將分配也限制為payload_size，以匹配 RAW 路徑。（CVE-2026-93186）

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

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

  - ext4：清除在回寫期間跳過的對開本上過時的 XARRAY 標籤 在 data=journal 模式下，當超級區塊在重新開機期間以唯讀方式重新掛載時，回寫執行緒可能會命中 ext4_journal_check_start（） 中的 WARN_ON_ONCE（sb_rdonly（sb））： 工作佇列：回寫wb_workfn （flush-253：0） RIP：
    0010：ext4_journal_check_start+0x8b/0xd0呼叫追蹤：__ext4_journal_start_sb+0x3c/0x1e0 mpage_prepare_extent_to_map+0x4af/0x580 ext4_do_writepages+0x3c0/0x1080 ext4_writepages+0xc8/0x1a0 do_writepages+0xc4/0x180 __writeback_single_inode+0x45/0x2f0 writeback_sb_inodes+0x26b/0x5d0
    __writeback_inodes_wb+0x54/0x100 wb_writeback+0x1ac/0x320 wb_workfn+0x394/0x470 然後是警告： EXT4-fs 警告 （device vda1）： ext4_evict_inode：195： inode #6263： comm （sd-umount）： 資料將遺失 這個問題並非每次都重現，而是經常重現。重現步驟是建立一個具有 8 個 CPU、16G 記憶體和設定 data=journal的 VM：sudo tune2fs -o journal_data /dev/vda1 執行 fio：rm -f fiotest fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio --iodepth=256 --numjobs=8
    --filename=fiotest --filesize=30G --group_reporting 重新開機 VM，然後檢查主控台輸出：
    virsh console testvm 但沒有髒 inode，folio_clear_dirty_for_io 清除PG_dirty但留下標籤PAGECACHE_TAG_DIRTY，並PAGECACHE_TAG_TOWRITE設定，這些標籤僅由 __folio_start_writeback 清除。在 data=journal 模式下，jbd2 會將日誌記錄的資料檢查點到其最終位置，並清除自己的已變更旗標，而不會觸及對開本PG_dirty或 xarray 已變更旗標。提交 f4a2b42e7891 （ext4：回寫後修正過時的 xarray 標籤） 會修正仍設定 PG_dirty 但沒有已變更頁面的情況。另一種情況是PG_dirty已清除，但PAGECACHE_TAG_DIRTY和PAGECACHE_TAG_TOWRITE仍處於設定狀態。在此情況下，回寫執行緒會檢查乾淨的對開本，並在mpage_prepare_extent_to_map中略過它：if （！folio_test_dirty（Folio） || ...folio_unlcok（對開頁）;繼續並且永遠不會到達提交 f4a2b42e7891 清除過時 xarray 標籤的ext4_bio_write_folio。重新掛載檔案系統後列印除錯日誌 唯讀：writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0 所有作品集實際上都是乾淨的：對開本 idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1 ... 我們需要通過在跳過路徑中循環回寫來清除此類乾淨作品集的 xarray 過時標籤，就像 f4a2b42e7891 在 ext4_bio_write_folio 中所做的那樣。（CVE-2026-92502）

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

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

  - net： kcm：在執行 BPF 剖析器 kcm_parse_func_strparser（） 呼叫 bpf_prog_run_pin_on_cpu（） 時保持 RCU 讀取鎖定，這會防止 CPU 移轉，但不會建立 RCU 讀取端關鍵區段。因此，BPF 映射操作在從 KCM strparser 程式呼叫時可以觸發 WARN_ON_ONCE（！bpf_rcu_lock_held（））。執行程式時保持 RCU 讀取鎖定。（CVE-2026-90143）

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

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

  - drm/panthor： 修正已驅逐 BO 部分取消對應的 NPD 問題 此認可修正了由於已驅逐 BO 的部分取消對應，在分割 GPU 對應時會發生的 NULL 指標解除參照問題。當 GPU 對應分割時，有一個邏輯可以處理大頁面的部分取消對應。針對已驅逐 BO 的 VMA 未完全略過此邏輯，這會導致「bo->backing.pages」指標的 NPD 可能性，當驅逐時釋放 BO 的頁面時，指標會設定為 NULL。
    當對被驅逐的 BO 進行部分取消映射時，出現了以下垃圾場。無法處理虛擬位址上的核心分頁要求 0000000000002000 記憶體中止資訊：ESR = 0x0000000096000004 EC = 0x25：
    DABT（當前 EL），IL = 32 位 SET = 0，FnV = 0 EA = 0，S1PTW = 0 FSC = 0x04：0 級轉換錯誤 資料中止資訊：ISV = 0，ISS = 0x00000004，ISS2 = 0x00000000 CM = 0，WnR = 0，TnD = 0，TagAccess = 0 GCS = 0，Overlay = 0，DirtyBit = 0，Xs = 0 使用者頁：4k 頁，48 位元 VA， pgdp=00000008842e8000 [0000000000002000] pgd=0000000000000000，p4d=0000000000000000 內部錯誤：哎呀： 0000000096000004 [#1] SMP <snip> pstate： 20000005 （nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--） pc：
    iova_mapped_as_huge_page+0x20/0x68 [panthor] lr ： panthor_gpuva_sm_step_remap+0x39c/0x498 [panthor] sp ：
    ffff800086193920 x29： ffff800086193920 x28： ffff800086193a18 x27： ffff800086193b80 x26： 0000000000400000 x25： 0000000000810000 x24： 0000000000400000 x23： ffff000808af1800 x22： 0000000000a00000 x21：
    ffff800086193a00 x20： ffff000806fd3f00 x19： 0000000000410000 x18： 00000000ffffffff x17： 00000000000000000 x16： 000000000000000000 x15： ffff800083ce2d83 x14： 00000000000000000 x13： 3120646574636976 x12：
    6520303030303138 x11： 2d30303030313420 x10： ffff8000836e6c80 x9 ： ffff80007bfc889c x8 ： 3ffffffffffffff x7 ： ffff8000836e6c80 x6 ： 000000000000000 x5 ： ffff000097ef19088 x4 ： 00000000000000000 x3 ：
    0000000000000000 x2 ： 0000000000010000 x1 ： 0000000000000400 x0 ： 000000000000000000 呼叫追蹤：
    iova_mapped_as_huge_page+0x20/0x68 [panthor] （P） op_remap_cb.isra.0+0x70/0xb0
    __drm_gpuvm_sm_unmap+0xf8/0x1c0 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa0/0x168 [panthor] panthor_vm_bind_exec_sync_op+0x8c/0xb8 [panthor] panthor_ioctl_vm_bind+0xbc/0x170 [panthor] drm_ioctl_kernel+0xc0/0x140 drm_ioctl+0x20c/0x500 __arm64_sys_ioctl+0xb4/0x118 invoke_syscall+0x5c/0x120 el0_svc_common.constprop.0+0x48/0xf8 do_el0_svc+0x28/0x40 el0_svc+0x38/0x128 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 代碼：8b030021 cb020021 f940b800 d34cfc21 （f8617801） ---[ end trace 00000000000000000000 ]--- v2： 修正縮排 （CVE-2026-93180）

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

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

  - media：stm32：dcmi：修正 probe（） 中的一些錯誤處理錯誤 這裡有幾個問題： 1） 我們分配後：chan = dma_request_chan（&pdev->dev， tx）;然後錯誤路徑需要清理後再返回。
    第一個錯誤路徑會直接傳回。2） 錯誤路徑檢查 dcmi->mdma_chan，但要到稍後才分配，因此會導致記憶體洩漏。請改用測試mdma_chan。3） 在指派 dcmi->dma_chan 之前，錯誤處理會呼叫 dma_release_channel（dcmi->dma_chan），這會導致 NULL 指標解除參照。請改用 chan 變數。我還在調用 dma_release_channel（） 之後移動了對 dma_release_channel（） 的調用，以便它更好地鏡像分配代碼。（CVE-2026-90405）

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

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

  - octeontx2-vf：修正探測/移除中的工作佇列和 netdev 爭用 在 register_netdev（） 之前初始化 VF 工作佇列ndo_set_rx_mode這樣就不會將 NULL 工作佇列上的工作排入佇列。在銷毀工作佇列之前取消註冊 netdev，並新增適當的探查錯誤清除。（CVE-2026-90084）

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

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

  - iommu/dma：還原圍繞msi_page_list的鎖定 與群組的預設網域不同，群組的預設網域一律是新配置且私有的 （iommu_group_alloc_default_domain（）），而 VFIO 類型 1 的舊版容器會在群組的iommu_ops和快取一致性強制執行相符時，將其合併到現有網域中。iommu_dma_get_msi_page（） 僅斷言持有調用方自己的群組互斥 （iommu_group_mutex_assert（））。在發佈 IOMMU_RESV_SW_MSI 的 IOMMU 上，例如 ARM SMMU，具有兩個透過舊版容器指派的這類裝置的 VM 可以讓其客體驅動程式平行探測和配置 MSI;每個主機端VFIO_DEVICE_SET_IRQS都位於不同的裝置 FD 和群組互斥上，但兩個裝置的網域是相同的合併網域，因此兩者都可以同時進入 iommu_dma_get_msi_page（） 並損毀msi_page_list。提交 288683c92b1a （iommu：將 iommu_dma_prepare_msi（） 設為通用作業） 刪除了先前的msi_prepare_lock，理由是每個iommu_domain對群組都是唯一的，這適用於預設網域，但不適用於此 VFIO 類型 1 情況。恢復靜態鎖，因為它只是保護一個角落案例，可能永遠不會被爭奪。iommufd 透過讓自己的呼叫端 （iommufd_sw_map_msi（）） 在到達共用清單之前進行 CTX 範圍的sw_msi_lock來避免對等問題。VFIO 類型 1 無法鏡像這一點，因為它會分派到 VFIO 管轄範圍之外的 iommu_dma_sw_msi（）。（CVE-2026-90244）

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

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

  - platform/chrome： cros_ec_typec：拒絕越界 PD 上限計數 cros_typec_register_partner_pdos（） 會將合作夥伴 PDO 從 EC TYPEC_STATUS 回應複製到固定的 caps_desc.pdo[PDO_MAX_OBJECTS] 陣列中。memcpy（caps_desc.pdo， resp->source_cap_pdos， sizeof（u32） * resp->source_cap_count）;...
    memcpy（caps_desc.pdo， resp->sink_cap_pdos， sizeof（u32） * resp->sink_cap_count）;PDO_MAX_OBJECTS是 7 歲。
    source_cap_count 和 sink_cap_count 是來自 EC 的 u8 欄位。唯一的檢查是它們並非都是零。如果其中任何一個大於 7，則 memcpy 會寫入堆疊上陣列的末尾。計數 255 會使其溢位約 1 KB。EC 來源陣列只有七個項目寬度。更大的計數也從他們身邊讀過。ChromeOS EC 韌體目前限制了這些計數，因此合規的設定不會達到此目標。核心仍應驗證這些值，而不是信任它們。驗證 memcpy 旁邊的 cros_typec_register_partner_pdos（） 中的計數。如果任一計數高於 PDO_MAX_OBJECTS，則跳過 PDO 註冊。cros_typec_handle_status（） 的其餘部分仍會執行，因此會處理和清除事件。
    (CVE-2026-93190)

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

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

  - wifi： mt76： mt7915：在探測 IRQ 失敗時釋放 hif2 參照 mt7915_pci_init_hif2（） 取得的 hif2 參照只會在關閉 dev->hif2 的錯誤路徑上釋放，直到 IRQ 設定之後才會指派。如果 pci_alloc_irq_vectors（） 或主要 devm_request_irq（） 失敗，則參照會洩漏。透過 mt7915_put_hif2（） 將其明確放在這些路徑上。（CVE-2026-90352）

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

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

  - remoteproc：防止損毀處理與 rproc_del（） 爭用 rproc_crash_handler_work（） 和 rproc_del（） 之間沒有同步處理，因此，在排程損毀處理常式工作甚至執行時，驅動程式可能會被移除，從而導致釋放後使用問題。為避免這種情況，在移除繼續之前，需要取消排程的工作並同步處理。為了確保這不會與報告爭用，進而排程新工作，會引進刪除旗標。這類似於為確保 start 不會與 rproc_del（） 爭用而引入的 RPROC_DELETE 狀態，但無法使用現有機制，因為它可以在原子上下文中調用 rproc_report_crash（） - 並且狀態受到互斥的保護。如果取消工作，則 pm_stay_awake（） 會保持不平衡，需要展開。在實際的 rproc_shutdown（） 呼叫之前封鎖和取消當機處理常式工作確實具有明確的副作用，即關閉進程導致的當機不會進入當機處理路徑，因此不會產生 devcoredumps 等。由於這些程式碼路徑之間存在相互排除，因此功能沒有具體減少，但需要進一步的工作來處理這種情況。
    (CVE-2026-90431)

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

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

  - drm/amd/display：修正平面重設函式 amdgpu_dm_plane_drm_plane_reset（） 中的懸空指標，可在配置新狀態之前釋放舊狀態。如果 kzalloc（） 失敗，則函式會傳回而不更新狀態指標，留下一個懸空指標指向已釋放的記憶體。先配置新狀態來修正此問題。
    配置失敗時，舊狀態保持不變，函式會安全地傳回。由 Linux 驗證中心 （linuxtesting.org） 使用 SVACE 找到。[調整圍繞當前 amd-staging-drm-next 的移動]（CVE-2026-93176）

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

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

  - ocfs2： o2hb：靜止協商處理常式及逾時工作 活動訊號區域會立即將結構o2hb_region發佈為 NEGO_TIMEOUT 的私有資料，並在 make_item（） 建立 configfs 區域後立即NEGO_APPROVE o2net 處理常式。核准處理常式可以呼叫 o2hb_arm_timeout（），因此對等可以在 dev_store（） 完成建置活動訊號執行階段之前，或在拆卸開始關閉該執行階段之後，接觸區域逾時工作。最終的 configfs put 也必須讓 reg 保持活動狀態，直到最後一個進行中的 o2net 回呼刪除其處理常式參照。o2net_unregister_handler_list（） 會封鎖未來的處理常式查詢，但不會等待已通過 o2net_handler_get（） 的sc_rx_work。該清空也需要涵蓋本機接聽程式拆解，其中 o2net 排序的工作佇列可能已經在 destroy_workqueue（） 內。
    在兩個方向上修正存留期規則。在透過 o2net 處理常式表格發佈 reg 之前，初始化區域延遲的工作，讓新區域或停止區域無法使用 hr_stopping 進行武裝，並靜止失敗啟動和拆卸路徑上的延遲工作，即使沒有活動訊號執行緒可以呼叫 o2hb_disarm_timeout（） 也是如此。然後在拆除處理常式可見區域狀態之前取消註冊處理常式，並使清空等待作用中或正在破壞的 o2net 有序工作佇列，然後再釋放 reg。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序： 區域生命週期：延遲協商回呼：1. make_item（） 註冊 1.o2net_process_message（） 在 reg. dev_store（） 的活動訊號處理常式建立 2 之前取得區域處理常式。回呼會在查詢可執行的活動訊號內容之後執行。鎖定被刪除並取消參照規則 2。啟動失敗或 rmdir 3。approve 或逾時路徑會嘗試停止活動訊號執行緒、佇列 reg 的延遲工作，或釋放靜默現有工作，並在處理常式捨棄最終 configfs ref 取消註冊後爭用回呼本文。3.
    region_release（） 必須排空 4.回呼或延遲的工作可以處理常式可見的 o2net rx 工作比 reg 有效，除非在釋放 reg 之前的生命週期程式碼。會讓區域保持不可布防，並耗盡作用中或銷毀的 o2net 工作佇列。驗證重現了此核心報告：KASAN slab-use-after-free in
    __run_timers+0x22c/0x5b0 大小 8 的寫入 呼叫追蹤：dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630
    __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 按任務堆疊分配：
    kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600 （CVE-2026-90301）

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

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

  - btrfs：始終等待有序範圍以避免 OE 爭用 [BUG] Syzbot 報告了一個錯誤，指出同一範圍可能存在衝突的 OE： BTRFS 嚴重 （device loop4）：insert_ordered_extent：264 中的錯誤：
    重疊有序範圍，現有 OE file_offset 16384 num_bytes 430080 旗標0x1089，新 OE file_offset 16384 num_bytes 430080 旗標0x80 （errno=-17 物件 alrea[ 179.162726][ T6897] BTRFS 嚴重 （device loop4）：insert_ordered_extent：264 中的錯誤：重疊有序範圍，現有 OE file_offset 16384 num_bytes 430080 旗標0x1089，新 OE file_offset 16384 num_bytes 430080 旗標0x80 （errno=-17 物件已存在） ------------[ 切到此處 ]------------ fs/btrfs/ordered-data 的核心錯誤。c：264！硬體名稱：Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP：
    0010：btrfs_alloc_ordered_extent+0x943/0xad0呼叫追蹤： <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 0000000000000000000 ]--- [CAUSE] 自從提交 ff66fe666233 （btrfs：修正附加直接寫入的錯誤緩衝 IO 後援） 以來，如果直接 IO 短時間結束，我們會將 isize 還原回原來的 isize，以便在緩衝後援期間可以遵守附加寫入。通常，我們在緩衝回寫期間依賴 lock_and_cleanup_extent_if_need（） 函式來等候任何現有的有序範圍。但只有在start_pos位於 isize 內時，才會發生有序範圍等待。由於我們已在失敗的直接 IO 期間還原 isize，因此我們不會等候任何有序範圍。這表示我們可以進行直接 IO OE 仍在樹狀結構中、完成但尚未移除的爭用，然後我們插入緩衝寫入的 OE，導致上述損毀。[修復]讓 OE 等待無條件，以處理還原的 isize 情況。由於 lock_and_cleanup_extent_if_need（） 現在要麼鎖定範圍，要麼傳回 -EAGAIN，因此也要移除處理無範圍鎖定案例的分支，並重新命名它以移除 _if_need 字尾。以下微基準測試顯示了 btrfs_buffered_write（） 的運行時間差異，執行“xfs_io -f -c pwrite 0 1m”工作負載，所有值都是以納秒為單位的平均運行時間。函式執行階段 |之前 |之後
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need（） | 58.2183.0 |btrfs_buffered_write（） | 2115.62973.3 |btrfs_buffered_write（） 的整體運行時間仍然很小（仍然不到 3 微秒），我想說額外的成本仍然是可以接受的。解決此問題的替代方法是在 iomap_end（） 期間等待有序範圍，其中 isize 還原已完成。但該解決方案將破壞 nowait 要求，就像 nowait 直接 IO 短時間結束一樣，我們必須無條件地等待 OE，否則下一個附加緩衝 IO 仍然會遇到相同的問題。所以這裡我們必須將等待成本移至緩衝寫入，但至少程式碼稍微精簡一些。（CVE-2026-90264）

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

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

  - vdpa/mlx5：修正錯誤路徑中反覆運算add_direct_chain錯誤清單 在 add_direct_chain（） 中，新配置的直接 MR 項目會新增至本機清單「tmp」，只有在成功時才會拼接到 mr->head 中。在錯誤路徑上，清理迴圈錯誤地反覆運算 mr->head 而不是 tmp。透過反覆運算err_alloc清理路徑中的「tmp」來修正。（CVE-2026-90128）

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

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

  - NFSv4：修正在 nfs4_add_lease（） 中傳遞給 nfs4_delete_lease（） 的錯誤引數 當 nfs4_add_lease（） 與委派傳回爭用時，它會呼叫 nfs4_delete_lease（） 進行清理。之前，它傳遞了 priv，這可以合法地為 NULL。傳遞 NULL priv 最終會導致 generic_setlease（） 中的 NULL 指標解除參照。（CVE-2026-90148）

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

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

  - ksmbd：在釋放之前分離封鎖的鎖定要求 ksmbd 保留用於位元組範圍鎖定簿記的file_lock仍然可以是 VFS 封鎖要求圖形的一部分。特別是，VFS 可以透過 flc_blocked_requests 鏈結在已封鎖的請求下方的新服務員。ksmbd_file參考計數未涵蓋該圖表。__ksmbd_close_fd（） 和交叉要求解除鎖定路徑都會直接釋放這些保留的file_lock物件。如果仍然附加依賴服務員，則 locks_release_private（） 會命中 BUG_ON（！list_empty（&flc->flc_blocked_requests））。相同的存留期不相符可能會使釋放的ksmbd_lock可透過其 request-local llist 存取。先將file_lock從封鎖的要求圖表中分離出來，然後再在關閉、交叉要求解除鎖定和復原路徑中釋放它。locks_delete_block（） 也會喚醒鏈結在物件下方的請求。發佈已完成的鎖定時移除 llist，讓全域可見的ksmbd_lock不再指向提交工作程式的堆疊。（CVE-2026-90155）

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

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

  - wifi：mt76：mt7996：在完全重設時清除 wcid 項目後釋放 vif 連結 mt7996_mac_reset_vif_iter（） 會將非預設 VIF 連結排入佇列以進行kfree_rcu，而 dev->wcid[] 仍會保留內嵌在每個釋放連結中的 WCID 指標;然後，mt76_reset_device（） 會取消參照這些項目並對其執行 mt76_wcid_cleanup（）。
    如果中間經過寬限期，則清理會在釋放的記憶體上運作。請先執行 mt76_reset_device（），以便在連結仍然有效時清除並清除 wcid 項目。（CVE-2026-90356）

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

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

  - erofs：修正隔行掃描的 ztailpacking pclusters 隔行掃描 pcluster 的磁碟大小應該以區塊對齊，而 ztailpacking 隔行掃描的 pcluster 應該完全無效。目前，mkfs.erofs 不會產生任何啟用 ztailpacking 的隔行掃描 pcluster，因此這不會影響任何現有的有效檔案系統。但是，特製的影像可能包含無效的隔行掃描 ztailpacking pcluster，導致從 kmap 的頁面越界讀取，並將不相關的核心記憶體複製到使用者空間可見的頁面快取中。（CVE-2026-90161）

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

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

  - ASoC：fsl_audmix：探測中的重做執行階段 PM 處理 在 pm_runtime_enable（） 之後，AUDMIX 區塊會關閉電源並保持暫停狀態，直到第一次執行階段回復為止。在 probe（） 和第一次還原之間發出的暫存器寫入 （例如，從 DAPM 或 ALSA 控制路徑） 以未通電的硬體為目標，並導致系統當機。
    透過在 pm_runtime_enable（） 之後立即呼叫 pm_runtime_resume_and_get（） 來啟動硬體並啟用其時鐘來解決此問題。之後使用 pm_runtime_put（） 釋放參照，以允許執行階段 PM 架構暫停裝置，並在閒置時將 regmap 切換為僅快取模式。停用CONFIG_PM或未啟用執行階段 PM 時，pm_runtime_* 呼叫是不會開啟硬體電源的 Stub。透過直接調用 fsl_audmix_runtime_resume（） 來明確處理這種情況，以便始終初始化硬體並啟用其時鐘，確保無論 PM 配置如何，暫存器存取都能成功。（CVE-2026-93184）

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

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

  - nfc： llcp：將 SNL TLV 剖析綁定到 skb 並新增長度檢查 nfc_llcp_recv_snl（） 使用派生自 skb->len 的 u16 偏移/長度對遍歷 SNL TLV 清單，而沒有對實際 skb 資料進行邊界讀取。
    接下來出現了三個問題： - 對於短幀 （skb->len < LLCP_HEADER_SIZE），tlv_len下溢。- 讀取 per-TLV 標頭 （類型、長度），而未檢查是否還剩兩個位元組。- 宣告的 TLV 長度可能會超過緩衝區的結尾，而長度 == 0 的 SDREQ 會service_name_len = 長度 - 1 反向溢位 （size_t），從而在下列 strncmp（） / nfc_llcp_sock_from_sn（） 中驅動越界讀取。
    SDRES 案例同樣讀取 tlv[2]/tlv[3]，而不進行長度檢查。附近的 NFC 裝置無需身份驗證即可到達此目的;LLCP 連結啟動會在 NFC-DEP 之後自動發生。按指標遍歷 TLV 列表，在線性 skb 數據上以 skb_tail_pointer（） 為界，並在使用前驗證每個 TLV 聲明的長度。新增 SDREQ （>= 1） 和 SDRES （正好 2） 的明確長度檢查。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。（CVE-2026-90223）

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

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

  - swiotlb：保留動態集區的配置虛擬位址，當需要從不可部分完成內容解密集區時，swiotlb_alloc_tlb（） 可以從 DMA 不可部分完成集區配置。使用 CONFIG_DMA_DIRECT_REMAP，不可部分完成集區由重新對應的虛擬位址支援，這些位址與 phys_to_virt（） 傳回的直接對應位址不同。swiotlb_init_io_tlb_pool（） 目前會從實體起始位址重建集區虛擬位址。對於不可部分完成集區支援的分配，這會在 pool->vaddr 中儲存錯誤的位址。稍後，swiotlb_free_tlb（）將該位址傳遞給dma_free_from_pool（），後者將無法識別區塊分配路徑傳回的虛擬位址傳遞到swiotlb_init_io_tlb_pool（）中，並將該位址儲存在pool->vaddr中。這會使集區自由路徑使用與配置器相同的虛擬位址。（CVE-2026-90387）

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

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

  - bpf：修正 bpf_tracing_link_release 中的警告 彈跳床可能會因驗證程式中盲目地顯示「tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX」而損毀。1. 附加到tail_call_reachable程序的 fexit 'tr->flags' 變成了 'BPF_TRAMP_F_CALL_ORIG |BPF_TRAMP_F_TAIL_CALL_CTX'。而且，蹦床會使用 jmp insn 而不是調用 insn 戳目標前奏的 nop insn。2. 另一個載入相同 tail_call_reachable prog 目標的 fexit。'tr->flags' 變成了'BPF_TRAMP_F_TAIL_CALL_CTX'。3. 關閉第一個 fexit 連結。由於 'tr->flags' 中沒有BPF_TRAMP_F_CALL_ORIG，彈跳床將無法使用調用 insn 還原前奏的 nop insn。[ 3.410719] 警告：kernel/bpf/syscall.c：3551，bpf_tracing_link_release+0x53/0x60， CPU#1：test_progs/98 ...[ 3.428793] bpf_link_free+0x58/0x130 [3.429293] bpf_link_release+0x23/0x30 透過將 'tr->flags' 更新為 '|=' 並鎖定來修正警告。
    (CVE-2026-92485)

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

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

  - xsk：遵循零複製路徑中的XDP_TX_METADATA 每當 UMEM 具有中繼資料空間時，零複製路徑都會讀取 TX 中繼資料，即使描述元未設定 XDP_TX_METADATA。透過中繼資料協助程式傳遞描述元選項，並忽略中繼資料，除非已設定選項。這不會修正 mlx5 MPWQE 的現有 per-WQE 中繼資料處理。只有啟動工作階段的描述元會通過 xsk_tx_metadata_request（） 並設定批次共用的卸載狀態。因此，加入開啟工作階段的描述元上的中繼資料不會經過驗證，也不會設定其要求的卸載。此外，即使未設定XDP_TXMD_FLAGS_TIMESTAMP，這類描述元的非空中繼資料指標也會被視為時間戳記完成要求，因此其中繼資料聯集可能會以未要求的時間戳記覆寫。修正一個 MPWQE 內的混合中繼資料狀態需要個別變更。
    (CVE-2026-90086)

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

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

  - bpf：__bpf_get_task_stack 中出錯時清除 buf 使用 __bpf_get_task_stack 的 bpf_get_task_stack 和 bpf_get_task_stack_sleepable 協助程式都已將 buf 定義為ARG_PTR_TO_UNINIT_MEM參數，我們應該在每個傳回路徑上初始化 buf。為__bpf_get_task_stack失敗路徑新增缺少的 buf memset。
    這會提供確定性的緩衝區內容，當緩衝區直接用作對應索引鍵時，這很有用。（CVE-2026-90300）

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

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

  - drm/amd/display：將 MST HDCP 每個連接器陣列的大小調整為 32 AMDGPU_DM_MAX_DISPLAY_INDEX為 31。它建議最多 32 個連接器。但它的使用方式就像MAX_DISPLAY_COUNT一樣。因此，我們偏離了 DRM 核心，它最多支援 32 個連接器。將AMDGPU_DM_MAX_DISPLAY_INDEX重新命名為 AMDGPU_DM_MAX_DISPLAY_COUNT 以符合其實際用途，並將大小增加到 32 以符合原始預期的大小。（CVE-2026-90289）

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

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

  - dm-pcache：驗證來自持久性記憶體 cache_pos_decode（）、cache_key_decode（） 和 cache_replay（） 的最後一個 kset 分支的seg_id欄位，回寫工作程式和 GC 背景工作程式會從快取裝置中繼資料中取得快取區段 ID，並使用它為 cache->segments[] 建立索引，而不針對快取>n_segs進行檢查。
    該中繼資料僅受固定公用種子的 CRC 保護，因此在表格載入 （CAP_SYS_ADMIN） 上提供快取裝置的人控制 ID;超出範圍的值會形成一個百搭的pcache_cache_segment指標，該指標會透過該指標進行取消參照和寫入，這是由磁碟上資料驅動的越界讀取和寫入。新增 cache_seg_id_valid（） 並在每個解碼站點拒絕超出範圍的 ID，使用 -EIO 使操作失敗，而不是通過陣列編製索引。將 ID 與初始化區段計數 （cache_info.n_segs） 繫結，而不是實體裝置總計。seg_num下方偽造的 cache_info.n_segs 否則會留下 segments[cache_info.n_segs..seg_num） 作為資料指標為 NULL 的零結構，因此該視窗中的偽造識別碼仍會被取消參照。稍後的修補程式保證 cache_info.n_segs <= seg_num，而驅動程式建立的快取會將兩者設定相等，因此有效映像不會受到影響。（CVE-2026-93201）

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

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

  - ntfs：修正 ntfs_decompress（） 中差一的頁面溢位 ntfs_decompress（） 中的每個權杖範圍檢查使用 if （cb >= cb_sb_end || dp_addr > dp_sb_end） break;因此，dp_addr == dp_sb_end 會落入符號副本 '*dp_addr++ = *cb++'，寫入目標頁面之後一個位元組。由於 NTFS_SB_SIZE == PAGE_SIZE目的地是單個頁面，因此位元組落在相鄰頁面中，並且 *dest_ofs 在子區塊末尾留下一個（後面的 '*dest_ofs &= ~PAGE_MASK' 會產生 1，而不是 0，因此頁面永遠不會最終確定，後面的子區塊會繼續寫入它）。因此，損毀的壓縮 $DATA 屬性會在讀取檔案時產生越界寫入的有限執行。一旦dp_addr達到dp_sb_end就休息;完整的子區塊仍然完成，因為其最終副本會dp_addr精確地推進到dp_sb_end。
    (CVE-2026-90118)

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

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

  - wifi： mac80211_hwsim：避免停止佇列清空中的 NULL skb mac80211_hwsim_stop（） 會丟棄資料>擱置中剩餘的任何影格。迴圈目前會檢查 skb_queue_empty（），然後分別出列。該分割與 TX 狀態處理非常激烈，可以刪除佇列鎖定下的擱置框架。如果在空檢查後刪除最後一個項目，則 skb_dequeue（） 傳回 NULL，停止路徑將該 NULL skb 傳遞給 ieee80211_free_txskb（）。請改用 skb_dequeue（） 作為迴圈條件。出列結果是停止擁有及釋放的物件，清空佇列的並行狀態完成只會讓迴圈終止。（CVE-2026-93149）

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

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

  - bpf， riscv：修正 arena load_acquire emit_atomic_ld_st（） 傳回 1 的可擴展處理，讓 build_body（） 在子字load_acquire之後跳過 zext。調用方確實執行 ret = ret ？： add_exception_handler（...），這會跳過任何非零 ret 上的 add_exception_handler（），因此缺少可擴展項目，並且錯誤PROBE_ATOMIC load_acquire oops。REG_DONT_CLEAR_MARKER 會因錯誤而使 rd 過時，並且驗證者仍然認為負載覆蓋了它，因此程式可以透過映射洩露它。在調用 add_exception_handler（） 之前檢查 ret >= 0，並傳遞 rd 進行LOAD_ACQ，以便故障像PROBE_MEM負載一樣將 rd 歸零。針對 zext 跳過，傳回 ret 不變。（CVE-2026-92517）

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

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

  - arm_mpam：停用驅動程式解除綁定以避免 UAF 當使用者解除綁定 MSC 並且該 MSC 是元件唯一剩下的 MSC 時，將釋放對應的mpam_component。如果用戶隨後繼續讀取 resctrl 文件系統中的 schemata 文件，則將從 resctrl_arch_get_config（） 訪問該mpam_component，從而導致釋放後使用。由於 MPAM 驅動程式不是模組，因此解除綁定 sysfs 介面是觸發移除的唯一方法。與其處理允許某些未使用的 MSC 解除綁定的複雜性，只需移除 unbind sysfs 介面即可。（CVE-2026-90270）

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

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

  - phy： qcom： qmp-usb-legacy： 修正早期執行階段暫停時可能的 NULL 解除參照 有一個小視窗，執行階段暫停回呼可能會在 pm_runtime_enable（） 之後和 pm_runtime_forbid（） 之前執行。在此情況下，會發生當機，因為執行階段暫停/繼續取消參照尚未初始化的 qmp->phy 指標：'if （！qmp->phy->init_count） {' 如果使用者在初始化 qmp phy 之前透過 sysfs 屬性重新啟用 runtime-pm，也會發生這種情況。與其他 qcom phy 驅動程式類似，引入一個 qmp->phy_initialized 變數，可用於避免依賴可能未初始化的 phy 指標。
    (CVE-2026-90282)

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

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

  - ksmbd：不要跳過單位元組範圍的鎖定檢查 check_lock_range（） 使用包含範圍。其呼叫端將結束位移傳遞為 start + length - 1，因此 start == end 代表有效的單位元組範圍，而不是空白範圍。因此，start == end 捷徑會略過對單位元組讀取、寫入、copychunk 作業和單位元組截斷範圍的強制位元組範圍鎖定檢查。不會檢查涵蓋該位元組的衝突鎖定，並允許作業繼續進行。移除捷徑。截斷大小 == inode->i_size 的情況已經透過僅在新大小與目前檔案大小不同時呼叫 check_lock_range（） 來處理。（CVE-2026-90176）

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

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

  - drm/amd/display：修正 CRTC 重設函式中的懸空指標 amdgpu_dm_crtc_reset_state（） 會在配置新狀態之前釋放舊狀態。如果 kzalloc（） 失敗，則函式會傳回而不更新狀態指標，留下一個懸空指標指向已釋放的記憶體。先配置新狀態來修正此問題。
    配置失敗時，舊狀態保持不變，函式會安全地傳回。由 Linux 驗證中心 （linuxtesting.org） 使用 SVACE 找到。[調整圍繞當前 amd-staging-drm-next 的移動]（CVE-2026-93175）

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

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

  - ext4：使用 fsdata 追蹤內嵌資料寫入狀態並修正爭用 不要在write_end處理常式中檢查即時 inode 狀態 （ext4_has_inline_data（inode） 和 ext4_test_inode_state（inode， EXT4_STATE_MAY_INLINE_DATA）），而是使用位址空間作業的 fsdata 參數來明確傳遞write_begin準備寫入的狀態。並行執行緒 （例如 ext4_page_mkwrite（）） 可以將內嵌資料轉換為 write_begin 和 write_end 之間的範圍。如果發生這種情況，write_end處理常式先前會遺漏內嵌write_end路徑，並流失為以範圍為基礎的write_end邏輯。
    不過，由於區塊緩衝區從未在write_begin中配置，因此會導致 NULL 指標解除參照或資料遺失，因為 folio_buffers（對開本） 為 NULL。將 EXT4_WRITE_DATA_INLINE （4） 定義為位旗標 （位元 2），將 fsdata 視為位元旗標，而不是互斥列舉，以保持寫入路徑的狀態獨立。透過 fsdata 傳達此狀態：1） ext4_write_begin（） 和 ext4_da_write_begin（） 在成功準備內嵌寫入時，透過位元 OR 在 *fsdata 中設定EXT4_WRITE_DATA_INLINE位。2） 進入時，ext4_write_begin（） 會清除 EXT4_WRITE_DATA_INLINE 位元以安全地處理 VFS 重試 （其中 generic_perform_write（） 會在重試跳轉時繞過 fsdata 初始化）。
    3） write_end處理常式會執行位元 AND 來檢查是否已設定 EXT4_WRITE_DATA_INLINE 位元，並據此叫用內嵌write_end協助程式。此外，在緩衝寫入期間，ext4_write_inline_data_end（） 會在準備寫入後取得 xattr 鎖定。如果並行頁面錯誤 （ext4_page_mkwrite（）） 在 write_end 處理常式檢查狀態之後，但在 ext4_write_inline_data_end（） 取得 xattr 寫入鎖定之前，將內嵌資料轉換為某個範圍，則後續檢查將透過 BUG_ON（！ext4_has_inline_data（inode）） 觸發核心錯誤。為了保持 git 歷史記錄正常運作和可分割性乾淨，請將 ext4_write_inline_data_end（） 中的BUG_ON檢查替換為同一提交中的正常錯誤處理重試路徑。如果在鎖定 xattr 後清除內嵌資料，我們會安全地釋放所有資源 （釋放 iloc.bh、解除鎖定/放置對開本、停止作用中的日誌交易句柄） 並傳回 0 （VFS 重試），讓通用寫入路徑安全地重試作業。（CVE-2026-92500）

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

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

  - libceph：驗證橫幅負載長度 剖析 Ceph Messenger v2 通訊協定橫幅時，「payload_len」欄位會從橫幅前置詞解碼。如果用戶端傳送「payload_len」為 0 的橫幅，核心會設定 0 長度的通訊端讀取。這違反了狀態機器中的不變量，在 'populate_in_iter（）' 中觸發警告： ------------[ cut here ]------------ !iov_iter_count（&con->v2.in_iter） 警告： net/ceph/messenger_v2.c：3129 at populate_in_iter net/ceph/messenger_v2.c：3129 [inline]， CPU#1：
    kworker/1:3/5070 警告：net/ceph/messenger_v2.c：3129，ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c：3159， CPU#1：kworker/1:3/5070 ... 呼叫追蹤： <TASK> ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c：1575 process_one_work kernel/workqueue.c：3322 [內嵌] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c：3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c：3486 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> 根據 msgr2 通訊協定規格，橫幅負載應包含至少兩個 64 位元整數 （「server_feat」和「server_req_feat」）。因此，'payload_len' 必須至少為 16 個位元組。透過在 'process_banner_prefix（）' 中新增檢查以拒絕小於 16 位元組的 'payload_len' 來修正此問題。這可防止 0 長度讀取，並因通訊協定錯誤正確中止連線。（CVE-2026-90067）

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

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

  - drm/sun4i： tcon： 刪除 TCON TOP 裝置參照 of_find_device_by_node（） 採用設備參照。多用器組態成功後將其刪除。（CVE-2026-90298）

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

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

  - iommu/tegra241-cmdqv：修正 init-failure 路徑上的 VINTF0 洩漏 tegra241_cmdqv_init_structures（） 使用 kzalloc_obj（） 配置 VINTF0、初始化它，並預先配置其邏輯 VCMDQ。其中兩個錯誤路徑洩露。
    當 tegra241_cmdqv_init_vintf（） 失敗時，它會在 VINTF0 到達 cmdqv->vintfs[] 陣列之前返回，因此探查失敗時的 devres 展開無法到達它;直接在那裡釋放它。稍後的 VCMDQ 預先配置失敗反而會讓 VINTF0 發佈，因此這次展開確實會達到 tegra241_cmdqv_remove_vintf（），然後將其從 vintf->hyp_own 中釋放出來。但是 tegra241_vintf_hw_init（） 僅在之後從硬體回讀中設定該標誌，因此仍然未初始化的 VINTF0 讀取為客體擁有並洩露，mutex_destroy（） 和 ida_destroy（） 在它從未設定的欄位上運行。從 vintf->idx 決定擁有權，而是在配置其 ID 時分配的索引：idx 0 是核心擁有的 VINTF0，而 idx >= 1 標記客體 VINTF。因此，tegra241_cmdqv_remove_vintf（） 和 tegra241_vintf_free_lvcmdq（） 中的核心內自由決策現在也以 idx 為鍵，並且hyp_own保持純硬體回讀狀態。
    (CVE-2026-90424)

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

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

  - scsi：sd：修正 scsi_alloc_sgtables（） 失敗時special_vec記憶體儲存區洩漏 sd_set_special_bvec（） 會為 UNMAP 和 WRITE SAME 命令配置特殊的承載頁面。如果之後在 sd_setup_unmap_cmnd（） 或 sd_setup_write_same{10,16}_cmnd（） 中 scsi_alloc_sgtables（） 失敗，則 SCSI 中間層不會呼叫 uninit_command（），因為尚未設定RQF_DONTPREP，從而洩露頁面。錯誤時調用 sd_uninit_command（），釋放頁面後清除RQF_SPECIAL_PAYLOAD。（CVE-2026-90267）

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

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

  - nilfs2：防止超級根區塊中的越界讀取 在 nilfs_read_inode_common（） 之前，剖析超級根 inode 中繼資料大小是受信任的。拒絕其計算的磁碟佔用空間超過檔案系統區塊大小的超級根 inode 大小。這可防止格式錯誤的檔案系統映像檔使 nilfs_read_inode_common（） 讀取超過超級根區塊的結尾。[Ryusuke：澄清提交標題]（CVE-2026-90419）

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

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

  - btrfs： zoned：在 btree_writepages（） 開始時排清作用中中繼資料區塊群組 btree_writepages（） 會以遞增邏輯位址順序寫入 btree inode 的已變更中繼資料。在分區檔案系統上，一次只有一個中繼資料和一個系統區塊群組可供寫入，而 check_bg_is_active（） （透過 btrfs_check_meta_write_pointer（）） 會在回寫從一個區塊群組移動到下一個區塊群組時樞紐作用中的區塊群組。如果作用中區塊群組位於比另一個也保存骯髒中繼資料的區塊群組更高的邏輯位址，則升序遍歷會先到達較低的區塊群組，並且要寫入它，必須完成作用中的區塊群組並啟動較低的區塊群組。它無法完成仍有未傳送 IO 的區塊群組，並且在WB_SYNC_ALL & ！for_sync （提交） 回寫期間，它會故意拒絕等待 fs_info->zoned_meta_io_lock 下的該 IO，因為這可能會鎖死。因此，樞紐樞紐本身也無法發出提交，因此它放棄了：btrfs_check_meta_write_pointer（） 傳回 -EAGAIN，btrfs_write_and_wait_transaction（） 將其視為致命並中止事務，從而強制檔案系統唯讀。在大量中繼資料的重新定位（例如 fstests btrfs/187）下，這種情況會間歇性發生。在 btree_writepages（） 開頭排清作用中的中繼資料和系統區塊群組，在它已經保留的 fs_info >zoned_meta_io_lock下，這樣它們就沒有未傳送的 IO，而後續的樞紐可以完成它們並取得進展。（CVE-2026-90261）

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

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

  - samples/ftrace：修正 ftrace-direct-multi-modify 中 ERR_PTR 上的 kthread_stop（） ftrace_direct_multi_init（） 將 kthread_run（） 的傳回值指派給 simple_tsk，而不進行 IS_ERR（） 檢查。當 kthread_run（） 失敗時，它會傳回 ERR_PTR（-ENOMEM），但 init 仍然傳回 0，因此模組載入時simple_tsk保留錯誤指標。卸載時，ftrace_direct_multi_exit（） 然後將該ERR_PTR傳遞給 kthread_stop（），從而導致 null 指標解除參照。用 IS_ERR（） 檢查 kthread_run（） 的傳回值;失敗時，取消註冊 ftrace 直接呼叫並傳播錯誤代碼。（CVE-2026-90066）

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

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

  - USB： gadget： r8a66597：避免探查錯誤路徑中的雙重釋放 ep0_req 如果 usb_add_gadget_udc（） 失敗，r8a66597_probe（） 會跳至 err_add_udc 並釋放ep0_req，然後失敗到clean_up2，當它為非 NULL 時，ep0_req會再次釋放。從err_add_udc中移除多餘的釋放項，並將清理保持在clean_up2，以便請求只釋放一次。使用原型靜態分析工具發現問題，並經程式碼檢閱確認。（CVE-2026-93141）

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

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

  - misc：bcm-vk：對 msgq_inited bcm_vk_sync_msgq（） 使用 acquire/release 會填入訊息佇列資訊，然後設定msgq_inited。讀取器在存取訊息佇列及其快取佇列資訊之前呼叫 bcm_vk_drv_access_ok（）。atomic_set（）/atomic_read（） 不會對這些存取進行排序。讀者可以看到msgq_inited集，同時仍會看到過時的佇列資訊。發佈初始化佇列時使用 release，檢查閘道時使用 acquire。將 bcm_vk_blk_drv_access（） 中的清除保留為 atomic_set（）。它會關閉閘道，且不會將佇列狀態發佈給讀者。（CVE-2026-93052）

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

ID	名稱	嚴重性
347850	Linux Distros 未修補弱點：CVE-2026-92514	high
347849	Linux Distros 未修補弱點：CVE-2026-92495	high
347848	Linux Distros 未修補弱點：CVE-2026-90191	high
347847	Linux Distros 未修補弱點：CVE-2026-90198	high
347846	Linux Distros 未修補弱點：CVE-2026-90242	medium
347845	Linux Distros 未修補弱點：CVE-2026-90408	high
347844	Linux Distros 未修補弱點：CVE-2026-92493	medium
347843	Linux Distros 未修補弱點：CVE-2026-93186	medium
347842	Linux Distros 未修補弱點：CVE-2026-92502	medium
347841	Linux Distros 未修補弱點：CVE-2026-90143	high
347840	Linux Distros 未修補弱點：CVE-2026-93180	medium
347839	Linux Distros 未修補弱點：CVE-2026-90405	medium
347838	Linux Distros 未修補弱點：CVE-2026-90084	medium
347837	Linux Distros 未修補弱點：CVE-2026-90244	high
347836	Linux Distros 未修補弱點：CVE-2026-93190	high
347835	Linux Distros 未修補弱點：CVE-2026-90352	medium
347834	Linux Distros 未修補弱點：CVE-2026-90431	medium
347833	Linux Distros 未修補弱點：CVE-2026-93176	high
347832	Linux Distros 未修補弱點：CVE-2026-90301	high
347831	Linux Distros 未修補弱點：CVE-2026-90264	medium
347830	Linux Distros 未修補弱點：CVE-2026-90128	medium
347829	Linux Distros 未修補弱點：CVE-2026-90148	medium
347828	Linux Distros 未修補弱點：CVE-2026-90155	medium
347827	Linux Distros 未修補弱點：CVE-2026-90356	high
347826	Linux Distros 未修補弱點：CVE-2026-90161	high
347825	Linux Distros 未修補弱點：CVE-2026-93184	medium
347824	Linux Distros 未修補弱點：CVE-2026-90223	high
347823	Linux Distros 未修補弱點：CVE-2026-90387	high
347822	Linux Distros 未修補弱點：CVE-2026-92485	high
347821	Linux Distros 未修補弱點：CVE-2026-90086	medium
347820	Linux Distros 未修補弱點：CVE-2026-90300	high
347819	Linux Distros 未修補弱點：CVE-2026-90289	high
347818	Linux Distros 未修補弱點：CVE-2026-93201	high
347817	Linux Distros 未修補弱點：CVE-2026-90118	high
347816	Linux Distros 未修補弱點：CVE-2026-93149	medium
347815	Linux Distros 未修補弱點：CVE-2026-92517	medium
347814	Linux Distros 未修補弱點：CVE-2026-90270	medium
347813	Linux Distros 未修補弱點：CVE-2026-90282	medium
347812	Linux Distros 未修補弱點：CVE-2026-90176	high
347811	Linux Distros 未修補弱點：CVE-2026-93175	high
347810	Linux Distros 未修補弱點：CVE-2026-92500	high
347809	Linux Distros 未修補弱點：CVE-2026-90067	high
347808	Linux Distros 未修補弱點：CVE-2026-90298	medium
347807	Linux Distros 未修補弱點：CVE-2026-90424	high
347806	Linux Distros 未修補弱點：CVE-2026-90267	medium
347804	Linux Distros 未修補弱點：CVE-2026-90419	high
347803	Linux Distros 未修補弱點：CVE-2026-90261	medium
347802	Linux Distros 未修補弱點：CVE-2026-90066	medium
347801	Linux Distros 未修補弱點：CVE-2026-93141	high
347800	Linux Distros 未修補弱點：CVE-2026-93052	medium

偵測

Nessus 的 Misc. 系列

high

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

high

high

medium

medium

medium

medium

high

high

medium

high

high

high

medium

high

high

high

high

medium

medium

medium

medium

high

high

high

high

medium

high

medium

high

medium

medium

high

medium