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 的判定取決於廠商所報告的套件是否存在。

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

  - arm64： ptrace：在 syscall 項目提交 e057b9477232 時，保持 'orig_x0' 與 x0 同步 （arm64： syscall：
    確保已儲存的 x0 與追蹤器更新保持同步） 嘗試解決 syscall 項目追蹤的長期問題，其中追蹤器能夠操作第一個 syscall 引數，而無需進行 seccomp 或稽核檢查。不幸的是，該修復並不完整 [1]，因為它無法在 seccomp ptrace 退出 （SECCOMP_RET_TRACE） 期間更新 x0 的追蹤器和重新評估的 seccomp 過濾器之間更新「orig_x0」。不要向核心 seccomp 代碼添加鉤子，而是將同步代碼移動到 ptrace GPR 和 syscall 設置代碼中，以便每當我們在 syscall 入口路徑上停止時，“orig_x0”都會與 x0 保持同步。（CVE-2026-90347）

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

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

  - RDMA/nldev：驗證動態計數器屬性長度 RDMA_NLDEV_ATTR_STAT_HWCOUNTERS 是巢狀屬性，其子系直接使用 nla_get_u32（） 耗用。最上層原則只會驗證容器，因此不會建立每個子項的固定資源配置。要求每個兒童有效載荷在讀取之前恰好是一個 u32。（CVE-2026-92523）

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

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

  - net： mana：將 MSI-X 向量限制為裝置 MSI-X 表格大小 mana_gd_query_max_resources（） 大小 gc->num_msix_usable，來自 resp.max_msix 和 CPU 計數，但絕不來自裝置 MSI-X 表格。在產生 1793 的 1792 vCPU M 系列 VM 上，而表格有 1024 個項目，然後 mana_gd_setup_remaining_irqs（） 遍歷索引 1..1792，從 msix_map_region（） 對應的區域末尾執行： 錯誤：無法處理位址的頁面錯誤：ff8e347f8b99800c RIP：0010：msix_prepare_msi_desc+0x7a/0x90 RAX：
    0000000000004000 RBX：ff4330cb164ea780 RCX：ff8e347f8b998000 呼叫追蹤： <TASK>
    __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 </TASK> RAX 的索引為 1024 * PCI_MSIX_ENTRY_SIZE，比表格多一個條目。
    msi_insert_desc（） 會檢查索引的範圍，但僅針對 MSI 網域 hwsize，該 hwsize 僅符合 MSI 父網域上裝置的資料表。使用全域 PCI/MSI 網域時，hwsize 會MSI_XA_DOMAIN_SIZE，因此沒有任何內容會限制要求。以 pci_msix_vec_count（） 封裝num_msix_usable。（CVE-2026-90082）

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

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

  - NFC： NCI：修正在CORE_INIT_RSP剖析 nci_core_init_rsp_packet_v1（） 和 nci_core_init_rsp_packet_v2（） 剖析 CORE_INIT_RSP 封包時使用未初始化記憶體，而無需驗證 SKB 是否包含足夠的資料。格式錯誤的回應 （例如，透過 virtual_ncidev 插入） 可能會宣告大型num_supported_rf_interfaces，同時提供的資料不足，進而導致讀取未初始化的 slab 記憶體。
    稍後會在 nci_init_complete_req（） 中使用此功能，觸發 KMSAN uninit-value 警告。在存取封包欄位之前新增 skb 長度檢查： - 驗證 skb 的狀態欄位至少有 1 個位元組。- 在剖析之前，驗證 skb 可以保留固定大小的標頭。- 在 v2 中，邊界檢查剖析迴圈內的每個可變長度rf_interface項目及其延伸參數。- 在 v1 中，驗證 skb 是否足夠大，以容納可變長度rf_interfaces陣列和尾端 rsp_2 結構。（CVE-2026-90221）

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

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

  - cxl/features：拒絕小於標頭的 Set Features 輸出緩衝區 cxlctl_set_feature（） 會調整使用者 fwctl_rpc.out_len 的輸出緩衝區大小，但從不檢查它是否足夠大，甚至可以容納 fwctl_rpc_cxl_out 標頭。當 out_len == 0 時，kvzalloc（） 傳回 ZERO_SIZE_PTR，它通過 ！rpc_out 檢查，後續的 rpc_out->size = 0 然後透過毒指標寫入。在配置之前，拒絕其輸出緩衝區無法保留回應標頭的要求。「設定功能」回覆不會攜帶任何承載，因此只需要標頭即可。（CVE-2026-93078）

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

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

  - HID： roccat：繫結的裝置提供的設定檔索引 kone_keep_values_up_to_date（） 和 kone_profile_activated（） 使用 8 位元裝置提供的設定檔值作為 5 元素 kone->profiles[] 陣列的索引，而不進行範圍檢查。宣告 Roccat Kone ID 的惡意 USB 裝置可以傳送具有超出範圍值的切換設定檔事件 （或探測時的startup_profile讀取），並使驅動程式讀取越界;結果會透過 actual_dpi sysfs 屬性公開。拒絕兩個路徑中的超出範圍的索引。這是透過靜態分析發現的，並透過下列修補程式 （KASAN：slab-out-of-bounds） 中新增的 KUnit 測試確認。（CVE-2026-93188）

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

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

  - sched/fair： 修正 update_tg_cfs_runnable（） 中的溢位 執行 hackbench 時觀察到除以零的崩潰： [14697.488452] CPU： 112 UID： 0 PID： 124791 通訊： hackbench 未受污染 7.1.0-rc2+ [14697.492627] RIP： 0010：propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] <TASK>
    __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 除以零發生在這裡： if （scale_load_down（gcfs_rq->load.weight）） { load_sum = div_u64（gcfs_rq->avg.load_sum， scale_load_down（gcfs_rq->load.weight））; } gcfs_rq->load.weight 是一個瘋狂的大值，被div_u64截斷為較低的 32 位， 恰好是 0。使用AI進行調查，原因是update_tg_cfs_runnable（）中的u32溢位，使用tg_tasks（）時扁平拾音成為受害者：u32 new_sum，分隔器;...new_sum = se->avg.runnable_avg * 分隔器;<-- boom 以下序列顯示了這如何觸發當機： propagate_entity_load_avg（） update_tg_cfs_runnable（） # u32 溢位損毀 runnable_sum __update_load_avg_cfs_rq（） ___update_load_avg（） # 計算出瘋狂的 runnable_avg update_tg_load_avg（） # 傳播到 tg->runnable_avg update_cfs_group（） calc_concur_shares（） tg_tasks（） # long-to-int 截斷，負 nr reweight_entity（） # 損毀的 se->load.weight update_load_add（） # 損毀的 cfs_rq->load.weightpropagate_entity_load_avg（） update_tg_cfs_load（） div_u64（） # 除以零 透過將new_sum從 u32 擴大到 u64 來修正（在此修正後很長一段時間內無需強制 tg_tasks（） 返回無符號） （CVE-2026-93182）

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

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

  - bpf：修正 bpf_find_vma（） 中 mm_struct 的釋放後使用 bpf_find_vma（） 讀取 task->mm 並呼叫 mmap_read_trylock（mm），而不保留 mm 上的參照。在外部任務上，並行 exit_mm（） 可以釋放無鎖定讀取和 trylock 之間的mm_struct，從而導致釋放後使用。mm_struct並不SLAB_TYPESAFE_BY_RCU。對於目前的工作，task->mm 是穩定的。對於外部任務，將 mm 固定在 task->alloc_lock 下，然後使用 mmput_async（） 釋放它，鏡像提交 d8e27d2d22b6 （bpf：修正開放編碼task_vma迭代器中的 mm 生命週期）。使用 spin_trylock（） 而不是 get_task_mm（），這樣 BPF 上下文就不會在 alloc_lock 上阻塞。拒絕外部任務路徑上的 irqs-disabled 上下文和 ！CONFIG_MMU，因為在那裡刪除 mm 引用並不安全。爭用： CPU0 （BPF 程式） CPU1 （結束任務） ============================ ========================== bpf_find_vma（foreign_task）： mm = task->mm exit_mm（）： task->mm = NULL mmput（mm） -> 釋放 mm_struct mmap_read_trylock（mm） // mm 上的 UAF （CVE-2026-93137）

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

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

  - dax/fsdev：對 direct_access 中的 kaddr 使用 __va（phys） 對 __fsdev_dax_direct_access（） 中的 kaddr 傳回使用 __va（phys） 而不是 virt_addr + linear_offset。前面的程式碼向 virt_addr 添加了一個裝置線性位元組偏移量（這是範圍的__va[0]），但對於範圍之間有實體間隙的多範圍設備，這種線性算術會越過間隙並產生錯誤的核心虛擬位址。使用 phys 來自 dax_pgoff_to_phys（） 的 __va（phys） 對於任何範圍配置都是正確的，因為直接映射會獨立地轉譯每個實體位址。這會留下 dev_dax->virt_addr 只寫入，因此請移除欄位 （由 Dave Jiang 建議）。（CVE-2026-93074）

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

ID	名稱	嚴重性
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
347799	Linux Distros 未修補弱點：CVE-2026-90347	high
347798	Linux Distros 未修補弱點：CVE-2026-92523	medium
347797	Linux Distros 未修補弱點：CVE-2026-90082	high
347796	Linux Distros 未修補弱點：CVE-2026-90221	medium
347795	Linux Distros 未修補弱點：CVE-2026-93078	medium
347794	Linux Distros 未修補弱點：CVE-2026-93188	high
347793	Linux Distros 未修補弱點：CVE-2026-93182	medium
347792	Linux Distros 未修補弱點：CVE-2026-93137	high
347791	Linux Distros 未修補弱點：CVE-2026-93074	high

偵測

Nessus 的 Misc. 系列

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

high

medium

high

medium

medium

high

medium

high

high