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

  - 已解決 Linux 核心中的下列弱點：drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump The ring content dump in amdgpu_coredump() uses two separate loops over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffers. Both loops use the same condition to skip rings:
    atomic_read(&ring->fence_drv.last_seq) == ring->fence_drv.sync_seq Because last_seq is an atomic that is updated concurrently by the fence signalling path, additional rings may appear unsignalled in the second loop that were signalled during the first. When this happens, idx exceeds the allocated ring_count and the store to coredump->rings[idx] writes past the end of the kcalloc-ed buffer. This was found during IGT stressful test amd_queue_reset which triggers random GPU resets. The OVERSIZE subtest (CMD_STREAM_EXEC_INVALID_PACKET_LENGTH_OVERSIZE on GFX ring) provokes a ring timeout and subsequent coredump, which hits the race between the counting and copying loops. The failure is non-deterministic and depends on fence signalling timing during the reset. KASAN log: BUG: KASAN: slab-out-of-bounds in amdgpu_coredump+0x1274/0x12f0 [amdgpu] Write of size 4 at addr ffff888106154258 by task kworker/u128:5/23625 CPU: 16 UID: 0 PID: 23625 Comm: kworker/u128:5 Not tainted 6.19.0+ #35 Workqueue:
    amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] Call Trace: <TASK> dump_stack_lvl+0xa5/0x110 print_report+0xd1/0x660 kasan_report+0xf3/0x130 __asan_report_store4_noabort+0x17/0x30 amdgpu_coredump+0x1274/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] drm_sched_job_timedout+0x194/0x5c0 [gpu_sched] process_one_work+0x84b/0x1990 worker_thread+0x6b8/0x11b0 </TASK> Allocated by task 23625: kasan_save_stack+0x39/0x70 __kasan_kmalloc+0xc3/0xd0
    __kmalloc_noprof+0x2ec/0x910 amdgpu_coredump+0x5c5/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] The buggy address belongs to the object at ffff888106154200 which belongs to the cache kmalloc-rnd-09-96 of size 96 The buggy address is located 16 bytes to the right of allocated 72-byte region [ffff888106154200, ffff888106154248) 72 bytes = 3 * sizeof(struct amdgpu_coredump_ring), so ring_count was 3 but idx reached 3+, writing ring_index (at struct offset 16) 16 bytes past the allocation. Fix by adding an idx < ring_count guard to the copy loop so it cannot exceed the allocated count even when the fence state changes between the two passes. (CVE-2026-74357)

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

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

  - ipv6: mcast：修復 MLD 延遲工作中的潛在 UAF。裝置拆除與傳入的 MLD 查詢處理之間存在爭用情形，導致 MLD 延遲工作中出現釋放後使用問題。在裝置銷毀期間，inet6_dev 的主要參照被釋放，這可能使其參照計數降至 0。inet6_dev 記憶體的實際釋放透過 RCU 延遲。同時，封包接收路徑會在 RCU 讀取鎖下執行並取得 inet6_dev 指標。由於記憶體受 RCU 保護，即使參照計數已達到 0，CPU-0 也可以安全地解除參照 inet6_dev。然而，如果 CPU-0 呼叫 igmp6_event_query() 並安排延遲工作，則其會嘗試使用 in6_dev_hold() 取得參照。這會將參照計數從 0 增加至 1，觸發 refcount_t: addition on 0 警告。由於 inet6_dev 記憶體仍計劃在 RCU 寬限期後釋放，因此在工作仍處於計劃狀態時裝置已被釋放。當工作執行時，會存取已釋放的記憶體，進而導致核心錯誤。修復方法是使用 refcount_inc_not_zero() (透過新的協助程式 in6_dev_hold_safe()) 來防止在裝置已被銷毀時取得參照。如果參照計數為 0，則不會排程工作。(CVE-2026-72322)

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

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

  - uprobes/x86：在 __in_uprobe_trampoline 中使用適當的mm_struct 在我們使用的取消註冊路徑中
    __in_uprobe_trampoline使用 current->mm 檢查 VMA 查詢，這是錯誤的，因為我們處於追蹤器上下文中，而不是追蹤進程中。將mm_struct指標引數新增至__in_uprobe_trampoline，並變更相關的呼叫端以傳遞正確的mm_struct指標。（CVE-2026-72357）

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

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

  - drm/xe/pf：請勿嘗試處理 FAST_REQ 或 EVENT 轉送 目前定義的 VF/PF 轉送動作只會使用一般 REQUEST 訊息，而且 PF 不應嘗試處理 FAST_REQUEST 或 EVENT 訊息，因為這會導致中斷 VFPF ABI 通訊協定，而且可能會觸發 PF 端的判斷提示。
    （從提交 1714d360fc5ae2e0886a69e979095d9c7ff3568a 中挑選）（CVE-2026-72360）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults. (CVE-2026-72278)

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

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

  - iommu/dma-iommu：修正 P2PDMA 路徑中錯誤的散佈清單長度指派 在 iommu_dma_map_sg（） 中，處理 PCI P2PDMA 案例時，目前散佈清單區段「s」的 DMA 長度是從前頭項目「sg->length」而不是目前項目「s->length」錯誤地指派的。此錯別字會導致散佈清單中的所有 P2PDMA 區段繼承第一個區段的長度，進而導致多區段散佈清單的 DMA 長度損毀。使用「s->length」而不是「sg->length」來修正此問題。（CVE-2026-74277）

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

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

  - apparmor：修正更新 sk_ctx 時的參照計數洩漏 目前 update_sk_ctx（） 傳輸 plabel 參照，不幸的是它也無條件地放入調用方中。理想情況下，我們會讓調用者根據是否傳輸引用有條件地放置引用，但現在只需通過獲取引用來修復錯誤即可。（CVE-2026-72461）

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

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

  - nvme-pci：使用單一調用方 nvme_init_hctx_common（） 從 hctx->numa_node 轉送的numa_node，修正 nvme_setup_descriptor_pools nvme_setup_descriptor_pools（） 索引 dev->descriptor_pools[] 中的越界存取。在非 NUMA 核心上，hctx->numa_node NUMA_NO_NODE （-1）。因為參數宣告為「未簽署」，所以值會變UINT_MAX，索引會離開陣列 （大小調整為 nr_node_ids），在 nvme_alloc_ns（） 期間出錯，並留下命名空間而沒有 /dev 節點。在由 CONFIG_NUMA=n 核心探測的任何 NVMe 控制器上重現： 錯誤：無法處理位址的頁面錯誤：
    ffff889101603d38 RIP：0010：nvme_init_hctx_common+0x5a/0x190 [nvme] 呼叫追蹤：nvme_init_hctx+0x10/0x20 [nvme] nvme_alloc_ns+0x9e/0xa10 [nvme_core] nvme_scan_ns+0x301/0x3b0 [nvme_core] nvme_scan_ns_async+0x23/0x30 [nvme_core] 將參數切換為 int，NUMA_NO_NODE時回退至節點 0;節點 0 始終存在。（CVE-2026-74383）

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

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

  - drm/i915：刪除 refs 後清除 CRTC 顏色斑點指標 intel_crtc_put_color_blobs（） 會刪除 CRTC 顏色斑點參照，但保持對應的指標不變。這在 intel_crtc_prepare_cleared_state（） 中可能很重要，它會在呼叫 intel_dp_tunnel_atomic_clear_stream_bw（） 之前釋放舊的 CRTC 硬體狀態。後者在查詢 DP 通道群組狀態時可能會失敗，例如使用 -EDEADLK。如果發生這種情況，函式會傳回，而不會完成已清除的狀態準備。然後，原子核心將清除失敗的原子狀態，並且可以針對相同的狀態再次調用 intel_crtc_free_hw_state（），再次刪除相同的 blob 引用。卸除參照之後清除 blob 指標，以便重複清除相同的 CRTC 硬體狀態是安全的。（從提交 d5005addb5f68e8a0edce249506757bdc9e3d8c8 中挑選）（CVE-2026-72452）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name() ntfs_lookup_inode_by_name() returns MFT references read from directory index entries on disk. These values are untrusted, but the function can currently return an error-marked MFT reference to its callers without validating it. Callers later decode lookup failures with MREF_ERR().
    A crafted NTFS image can set the MREF error bit while leaving the low bits as an arbitrary value, causing callers to consume a bogus pseudo-errno instead of treating the lookup result as corrupted on-disk metadata. Fix this at the source by normalizing every error-marked MFT reference returned from ntfs_lookup_inode_by_name() to ERR_MREF(-EIO). Apply this to all four directory lookup return paths so every caller gets a validated result without needing additional checks or an API change. This keeps the sanitization in the common lookup helper, which is cleaner than duplicating validation in each caller.
    (CVE-2026-72188)

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

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

  - gpu/buddy：無法遵守對齊時退出try_harder try_harder連續後援可能會傳回起始位移不符合呼叫端min_block_size的範圍。當候選者的起點未對齊時，重新對齊它：釋放未對齊的運行，並在下一個較低的min_block_size邊界處重新分配完全@size。這會讓傳回的大小保持不變，沒有要修剪的盈餘，而且只有在沒有對齊候選項目適合時才會拒絕要求。v2：針對 RHS 和 LHS 路徑，將未對齊的候選者向下對齊到 min_block_size，而不是救助 （Matthew）。（CVE-2026-72244）

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

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

  - mac802154：移除具有 RCU 清單刪除的介面 佇列喚醒、停止和停用路徑在 RCU 下遍歷本機>介面。大量硬體拆卸路徑會移除帶有 list_del（） 的項目，因此非同步傳輸完成可以遵循 ieee802154_wake_queue（） 中的中毒清單節點。如同在單一介面移除路徑中使用 list_del_rcu（）。下列 unregister_netdevice（） 會在釋放網路裝置之前等待正在進行的 RCU 讀取器，因此不需要單獨的寬限期等待。
    (CVE-2026-72024)

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

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

  - bpf：加強 prog 陣列的 cgroup 儲存 cookie 檢查 提交 abad3d0bad72 中的修正 （bpf：修正 cgroup 本機儲存中的 oob 存取） 仍未完成。prog-array 相容性檢查會將沒有 cgroup 儲存的程式視為與任何已儲存的儲存 Cookie 相容。這可讓無儲存體程式在進入程式與使用儲存體的被呼叫者之間橋接尾端呼叫鏈結，即使執行階段的 cgroup 本機儲存體仍遵循呼叫端的內容，即 A -> B（無儲存體） -> C（儲存體） 路徑。
    要求確切的 cookie 相等會破壞無儲存區葉程式從使用儲存體的程式尾部呼叫的合法情況。相反地，只有在程式無法自行執行尾部呼叫時，才接受零儲存體 Cookie。這會讓 A -> B（無儲存裝置） 保持運作，同時拒絕 A -> B（無儲存裝置） -> C（儲存裝置） 橋接器。（CVE-2026-74305）

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

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

  - net：ife：要求 ETH_HLEN 在 ife_decode（） 中可拉取） IFE 解碼在僅將外部 IFE 標頭和中繼資料設為可拉取之後，可能會傳回。然後，呼叫者將解封裝的封包傳遞給 eth_type_trans（），後者期望可以從線性資料區域存取內部乙太網路標頭。對於格式錯誤的 IFE 框架，內部乙太網路標頭可能仍比線性區域中的 ETH_HLEN 短，這可能會導致原始程式碼崩潰。透過擴充 ife_decode（） 中的拉取檢查來修正此問題，以便保證內部乙太網路標頭在返回之前也是可拉取的。（CVE-2026-72296）

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

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

  - 已解決 Linux 核心中的下列弱點：LoongArch: KVM: Validate irqchip index in irqfd routing Sashiko reported that the irqchip index is not validated for LoongArch. Add validation and reject out-of-range irqchip indexes to avoid indexing past the routing table's chip array.
    (CVE-2026-72295)

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

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

  - tipc：修正 tipc_l2_send_msg（） 中的 UAF 當從 tipc_l2_send_msg（） 調用時，Syzbot 報告了 ipvlan_hard_header（） 中的 slab-use-after-free。根本原因是 tipc_disable_l2_media（） 在 b->media_ptr 仍然有效時呼叫 synchronize_net（）。這允許並行 RCU 讀取器在 synchronize_net（） 完成後取得裝置指標。指標稍後會在 bearer_disable（） 中清除，但沒有任何後續同步處理，因此可以在讀取器仍在使用時釋放裝置。透過在呼叫 synchronize_net（） 之前清除 tipc_disable_l2_media（） 中的 b->media_ptr來修正此問題。現在可以安全地執行此操作，因為 bearer_disable（） 中的呼叫順序在 0d051bf93c06 （tipc：使承載封包篩選通用） 中反轉，以在 disable_media（） 之前呼叫 tipc_node_delete_links（） （需要指標）。
    https：//lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u （CVE-2026-74255）

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

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

  - orangefs：在 fill_from_part() 中保持 readdir 項目大小為 64 位元。fill_from_part() 以 size_t 計算目錄項目的大小，但將其存儲在 __u32 中。接近 U32_MAX 的項目長度會使其迴繞為一個小值，進而繞過邊界檢查，隨後被用於索引項目，導致讀取遠超出目錄部分
    -- 這是一種會導致核心崩潰的越界讀取。將大小計算改為 u64 以防止截斷；隨後的邊界檢查將拒絕該項目。預告由使用者空間用戶端提供。(CVE-2026-72033)

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

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

  - net/mlx5e： macsec：修正 RX SC 刪除時的釋放後使用 metadata_dst 當卸載的 MACsec RX SC 被刪除時，macsec_del_rxsc_ctx（） 使用 metadata_dst_free（） 釋放了 per-SC metadata_dst，這會無條件地 kfree（） 物件並忽略 dst 參照計數。mlx5e_macsec_offload_handle_rx_skb（） 中的 RX 資料路徑透過 xa_load（） 查詢 rcu_read_lock（） 下的 SC，使用 dst_hold（） 獲取參考，並使用 skb_dst_set（） 將 dst 附加到 skb。已取得rx_sc指標的讀取器可以與刪除路徑爭用，並在釋放的記憶體上進行操作。透過使用 dst_release（） 刪除參照而不是無條件釋放來修復所有者端，並將 RX 資料路徑轉換為 dst_hold_safe（），以便爭奪 SC 刪除的讀取器無法附加剛剛刪除最後一個參照的 dst;僅在實際進行參考時才附上。在配置和初始化 rx_sc->md_dst 之前，mlx5e_macsec_add_rxsc（） 也透過 xa_alloc（） 發布了sc_xarray_element，因此以 fs_id 查詢 SC 的資料路徑讀取器可以觀察到md_dst仍為 NULL 的rx_sc，或者在弱排序架構上，內容尚不可見的非 NULL md_dst指標。NULL 檢查資料路徑上的 xa_load（） 結果和md_dst，並重新排序 add_rxsc（），以便只有在 md_dst 完全初始化之後才會進行 xa_alloc（） 發佈;然後，xarray RCU 發佈會與資料路徑中的 rcu_read_lock（）/xa_load（） 配對。注意：macsec_del_rxsc_ctx（） 也會在沒有 RCU 寬限期的情況下rx_sc kfree（） 的 ->sc_xarray_element，而相同的資料路徑在 rcu_read_lock（） 下讀取它;這是一個單獨的預先存在的問題，留給後續修補程式。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。（CVE-2026-72072）

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

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

  - scsi： elx： efct：修正 efct_hw_io_abort（） 中的參照計數洩漏 當 efct_hw_reqtag_alloc（） 在 efct_hw_io_abort（） 中失敗時，錯誤路徑會傳回 -ENOSPC，而不會釋放函式中稍早透過 kref_get_unless_zero（） 取得的參照。所有其他錯誤路徑都會正確刪除參照。這會導致io_to_abort物件上永久出現參照洩漏。此外，abort_in_progress 旗標在此路徑上仍會設定為 true，這表示未來相同 I/O 的中止嘗試會立即傳回
    -EINPROGRESS，即使從未提交中止，也有效地阻止了恢復。透過新增缺少的 kref_put（） 呼叫並將abort_in_progress重設為 false 來修正此問題，以符合以下 efct_hw_wq_write（） 失敗路徑中完成的清理作業。（CVE-2026-72082）

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

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

  - 跟蹤/user_events：修正 user_event_mm_dup（） 中的釋放後使用user_event_mm_dup（） 在 fork（） 期間 （從 copy_process（）） 在 rcu_read_lock（） 下無鎖定地遍歷父 mm 的啟用器清單）;它不需要event_mutex：rcu_read_lock（）;list_for_each_entry_rcu（enabler， &old_mm->enablers， mm_enablers_link） enabler->event = user_event_get（orig->event）;user_event_enabler_destroy（） 會使用 list_del_rcu（） 從該清單中移除啟用器，然後不用等待寬限期，使用 user_event_put（） 刪除啟用器的user_event參照，並使用 kfree（） 釋放啟用器。在 list_del_rcu（） 之前載入啟用器的讀取器仍可遍歷它，這會導致兩個釋放後使用：- kfree（enabler） 釋放啟用器，而該讀取器會取消參照 enabler->event。- user_event_put（） 可能會刪除對 user_event 的最後一個參照，然後釋放該參照 （透過工作佇列上的 delayed_destroy_user_event（） ），而同一個讀取器會對其執行 user_event_get （orig->event）。兩者都可以通過可以打開user_events_data的無權限任務來訪問：一個多線程進程註冊一個啟用器，然後同時取消註冊它並調用 fork（） 觸發爭用。在 clone（） 期間，KASAN 會在 user_event_mm_dup（） 中報告 slab-use-after-free，並在釋放 user_event 時顯示 refcount_t： add on 0 警告。首先找到了釋放後使用的推動因素;user_event問題是由 XIAO WU 報告的，而先前的僅啟用程式修正並未解決此問題。將 user_event_put（） 和 kfree（enabler） 都推遲到以 queue_rcu_work（） 排入佇列的工作項目，以便它們只在 RCU 寬限期之後執行，一旦所有遍歷啟用器清單的讀者都完成。放置必須在處理程序內容中執行，因為 user_event_put（） 會在最後一個參照上event_mutex，因此會使用工作佇列而不是 call_rcu（）。現在解鎖的 put 可以刪除 user_event_enabler_destroy（） 的鎖定參數;所有呼叫者都會更新。
    (CVE-2026-72071)

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

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

  - 已解決 Linux 核心中的下列弱點：dma-buf: dma-fence: Fix potential NULL pointer dereference The commit mentioned in the fixes tag below introduced a mechanism through which fence producers can fully decouple from fence consumers. This, desirable, mechanism is based on the fence's signaled-bit as the decoupling point. A sophisticated interaction between RCU and atomic instructions attempts to ensure that fence consumers can still interact with fence producers through the dma_fence_ops (callback pointers into the producer). This is the desired behavior: to check for decoupling, the signaled-bit is first checked. If it's not yet signaled, RCU ensures that the ops pointer cannot yet be NULL. Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit, and then sets the ops pointer to NULL. Readers first load the ops pointer, and then check through the signaled-bit whether the pointer can legally be accessed. These set and load operations could occur out of order on weakly ordered platforms. This problem can be solved very elegantly by using the ops pointer itself as the synchronization point. The pointer is either NULL, or cannot become NULL while it is being used thanks to RCU. Replace the signaled-bit check in dma_fence_timeline_name() and dma_fence_driver_name().
    (CVE-2026-72094)

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

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

  - 已解決 Linux 核心中的下列弱點：io_uring/bpf-ops: reject re-registration of an already-bound ops io_install_bpf() only rejects a second registration on the ctx side (ctx->bpf_ops) and sets the per-map back-pointer ops->priv unconditionally. The struct_ops link path never advances a map past BPF_STRUCT_OPS_STATE_READY, so the same io_uring_bpf_ops map can be registered more than once, and bpf_io_reg() re-resolves the target ring via fget(ops->ring_fd) on every call. A caller can therefore point the same ring_fd at a different io_ring_ctx between two BPF_LINK_CREATE calls. The second registration passes the ctx->bpf_ops check (the new ctx has none) and overwrites ops->priv, orphaning the first ctx. Teardown (io_eject_bpf()/bpf_io_unreg()) only reaches a ctx through ops->priv, so the orphaned ctx is never torn down: its ctx->loop_step keeps pointing into the struct_ops trampoline, which is freed once the map is gone. A later io_uring_enter() on the orphaned ring then calls the dangling ctx->loop_step from io_run_loop() -- a use-after-free of freed executable memory, reachable by a task with CAP_BPF + CAP_PERFMON. Reject registration when ops->priv is already set, as hid_bpf_reg() does for its struct_ops.
    (CVE-2026-72112)

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

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

  - net：sit：需要裝置 netns 中的 CAP_NET_ADMIN 才能讓 changelink ipip6_changelink（） 最多在兩個 netn 上運作，即 dev_net（dev） 和通道連結 netns t->net。一旦裝置在執行要求的 netns 中建立或移動至 netns 以外的 netns，它們就會有所不同。rtnl changelink 路徑僅針對 dev_net（dev） 檢查CAP_NET_ADMIN，因此在 t->net 中具有權限但不在 t-net 中的呼叫者可以重寫位於 t->net 中的隧道。在剖析任何屬性之前，在其頂端的 rtnl_dev_link_net_capable（） 上閘道 ipip6_changelink（）。SIT 是最近系列未涵蓋的一種隧道類型，它將此檢查添加到其他 changelink（） 處理常式中。（CVE-2026-72061）

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

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

  - NFS：按請求大小而非帳單集大小對不穩定的寫入收費 nfs_folio_mark_unstable（） 和 nfs_folio_clear_commit（） 每次按 folio_nr_pages（Folio） 收費和取消收費 NR_WRITEBACK/WB_WRITEBACK 一次
    *request* 已新增至提交清單或從提交清單中移除。只有在對開本具有單一相關聯要求時，才正確執行此操作。當 pg_test 將作品集分割成 N 個子作品集要求時 （例如，使用小於作品集大小的等量單位進行 pNFS flexfiles 等量化，或純 wsize 限制分割），每個 N 個要求都會獨立地對整個作品集的頁數收費，使每個作品集的會計膨脹 N 倍數。
    對於大型對開本和小型條帶單元，這達到了多個數量級：拆分為 512 個 4 KiB 請求的 2 MiB 作品集可以充電其實際大小的 512 倍，從而將全域 dirty+writeback 帳戶推到系統的 dirty 閾值之外，並迫使主機上的每個緩衝寫入器進入硬節流路徑，包括共享盒子的不相關的核心內 NFS 伺服器執行緒。僅對每個請求實際涵蓋的頁面收費。（CVE-2026-72132）

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

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

  - scsi： elx： efct：修正不支援的其他 CDB 上的 I/O 洩漏 efct_dispatch_fcp_cmd（） 會在分派主動請求的 FCP 命令之前配置efct_io。如果命令有不支援的其他 CDB，則函式會在將 IO 傳遞至 SCSI 層之前傳回 -EIO。從此錯誤路徑傳回之前，先釋放配置的 IO。（CVE-2026-72081）

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

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

  - dm era：修正非零起始磁區的越界記憶體存取 dm-era 會追蹤目標相對區塊中的寫入，但 era_map（） 會在套用目標位移之前計算寫入集區塊。因此，具有非零起始磁區的表可以將絕對映射裝置區塊傳遞給 metadata_current_marked（）。如果絕對區塊超出目前的寫入集大小，則 writeset_marked（） 會測試核心內位元集的結尾。KASAN 會將此報告為 vmalloc-out-of-bounds 存取。在計算時代區塊之前套用目標位移，讓寫入集查詢使用目標相對區塊編號。（CVE-2026-72107）

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

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

  - xfrm： xfrm_interface：需要設備 netns 中的 CAP_NET_ADMIN 才能讓 changelink xfrmi_changelink（） 最多在兩個 netn 上運行，即 dev_net（dev） 和介面連結 netns xi->net。一旦裝置在執行要求的 netns 中建立或移動至 netns 以外的 netns，它們就會有所不同。rtnl changelink 路徑僅針對 dev_net（dev） 檢查 CAP_NET_ADMIN，因此在 xi->net 中具有權限但不在 xi-net 中的調用方可以重寫位於 xi->net 中的介面。在剖析任何屬性之前，在其頂端的 rtnl_dev_link_net_capable（） 上閘道 xfrmi_changelink（）。（CVE-2026-72136）

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

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

  - 輸入：ims-pcu - 修正 disconnect 中的釋放後使用和雙重釋放 ims_pcu_disconnect（） 僅用於在主要 （控制） 介面未綁定時執行清理。不過，它目前依賴介面類別來區分控制項和資料介面。惡意裝置可能會提供與控制介面類別相同的資料介面，進而導致過早清除，以及潛在的釋放後使用或雙重釋放。切換到驗證正在中斷連線的介面是否確實是控制介面。（CVE-2026-72079）

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

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

  - dm_early_create：修正 dm_resume 失敗時釋放已使用的資料表 如果dm_resume失敗，核心會嘗試使用 dm_table_destroy 釋放資料表，但該資料表已使用 dm_swap_table 實例化。在此情況下，此提交會略過對 dm_table_destroy 的呼叫。（CVE-2026-72102）

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

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

  - sqlparse 是適用於 Python 的非驗證 SQL 剖析器模組。在 0.6.0之前，sqlparse/keywords.py 中的 SQL_REGEX 和 sqlparse/lexer.py 中的 per-position 迴圈會反覆掃描不相符的美元引號文字和多行註解分隔符，從而透過 sqlparse.parse（）、sqlparse.format（） 和 sqlparse.split（） 造成二次 CPU 消耗。0.6.0 版已修正此問題。
    (CVE-2026-59893)

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

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

  - fs/resctrl： 修正卸載期間的釋放後使用：在卸載或失敗拆卸期間，釋放所有包含監控事件檔案私有資料的mon_data結構，之後會移除 kernfs 節點。不過，絕不會為靜態配置的預設資源群組設定RDT_DELETED旗標。與預設資源群組相關聯之事件檔的並行讀取器可以在捨棄 kernfs 主動保護之後，在卸載繼續釋放檔案私有資料並銷毀 kernfs 節點而不等待讀取器時，在 rdtgroup_mutex 上封鎖。釋放互斥時，讀取器會喚醒，觀察到未為預設群組設定RDT_DELETED，並取消參照已釋放的檔案私有資料。該場景可以描述如下： CPU0 CPU1 /* * 預設資源群組的 * 監控資料可透過 * kernfs 檔案存取，其中 kernfs_node：:p riv * 指向結構mon_data。* 使用者開啟檔案進行讀取。*/ rdtgroup_mondata_show（） /* arch 遇到致命錯誤 */ rdtgroup_kn_lock_live（） resctrl_exit（） atomic_inc（&rdtgroup_default.waitcount） cpus_read_lock（） kernfs_break_active_protection（kn） mutex_lock（&rdtgroup_mutex） cpus_read_lock（） resctrl_fs_teardown（） mutex_lock（&rdtgroup_mutex） rmdir_all_sub（） mon_put_kn_priv（） /* 刪除所有mon_data結構 */ rdtgroup_destroy_root（） kernfs_destroy_root（） rdtgroup_default.kn = NULL mutex_unlock（&rdtgroup_mutex） /* *rdtgroup_default.flags 為空，因此 * rdtgroup_kn_lock_live（） 傳回 * &rdtgroup_default */ md = of->kn->priv;/* md 指向釋放的mon_data */ 無條件地為預設群組設定 RDT_DELETED，因為該標誌不會導致釋放此靜態配置的群組。如果先前掛載的預設群組上有任何等候程式，則不允許新的 resctrl 掛載。新的掛載會重新初始化預設群組，該群組會從先前的掛載中向服務員顯示，就好像預設群組可以存取一樣，導致他們存取先前掛載中已移除的mon_data結構。（CVE-2026-72080）

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

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

  - accel/amdxdna：修正 amdxdna_gem_dmabuf_mmap（） 中的釋放後使用當 vm_insert_pages（） 失敗時，錯誤路徑會呼叫 vma->vm_ops->close（vma），後者會在內部呼叫 drm_gem_vm_close（） drm_gem_object_put（），釋放在函式開始時取得的 GEM 物件參照。但是，close_vma標籤隨後會落入 put_obj，後者會在相同的物件上第二次呼叫 drm_gem_object_put（）。如果第一個放置釋放最後一個參照，則會釋放物件，而第二個放置會存取釋放的記憶體，從而造成釋放後使用。透過直接從 close_vma 返回而不是落入 put_obj 來修正，因為關閉處理常式已執行所有必要的清除，包括物件 put。（CVE-2026-72093）

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

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

  - scsi: target: core：修復 REGISTER AND MOVE 中的 iSCSI ISID 釋放後使用問題。core_scsi3_emulate_pro_register_and_move() 使用 transport_kmap_data_sg() 映射 PERSISTENT RESERVE OUT 參數清單，並使用 target_parse_pr_out_transport_id() 剖析目的地 TransportID。
    對於 iSCSI TransportID (格式代碼 01b)，iscsi_parse_pr_out_transport_id() 將 iport_ptr 中的 ISID 作為指向該映射緩衝區的原始指標傳回。該函數隨後在 strcmp()、__core_scsi3_locate_pr_reg() 和 core_scsi3_alloc_registration() 中解除參照 iport_ptr 之前，先使用 transport_kunmap_data_sg() 取消緩衝區映射。當參數清單跨越超過一個頁面 (PARAMETER LIST LENGTH > 4096) 時，transport_kmap_data_sg() 會使用 vmap()，而 transport_kunmap_data_sg() 執行 vunmap()，因此支援 iport_ptr 的核心虛擬位址被拆除，隨後的每次解除參照都是對已取消映射區域的釋放後使用讀取。保持參數清單映射，直到不再需要 iport_ptr：在傳回之前，刪除早期的 transport_kunmap_data_sg()，並在成功路徑上取消映射一次。錯誤路徑已透過 out: 標籤處現有的 if (buf) transport_kunmap_data_sg(cmd) 進行取消映射，由於 buf 不再被提前清除，該路徑現在會在每次映射後的錯誤退出時執行。在持有自旋鎖期間僅發生映射讀取；映射和取消映射呼叫仍保持在任何鎖之外。同級呼叫端 core_scsi3_decode_spec_i_port() 已在取消映射前使用緩衝區，故保持不變。
    (CVE-2026-72083)

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

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

  - 輸入：ims-pcu - 修正 CDC 聯合描述元剖析中的類型混淆驅動程式目前信任來自 CDC 聯合描述元的 bMasterInterface0，而不驗證它是否符合正在探查的介面。這可能會導致驅動程式覆寫另一個介面的私人數據。驗證在描述元中找到的控制介面是否確實是我們正在探測的介面。（CVE-2026-72074）

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

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

  - 輸入：ims-pcu - 修正 ims_pcu_irq（） 除錯記錄中的越界讀取 ims_pcu_irq（） 中的除錯記錄會無條件地從 pcu->urb_in_buf 列印資料。不過，如果針對 pcu->urb_ctrl 觸發中斷，則實際資料位於 pcu->urb_ctrl_buf 中。如果控制 URB 的 urb->actual_length 超過 pcu->max_in_size，這會導致越界讀取。從與 URB 相關聯的正確緩衝區列印來修正此問題。（CVE-2026-72076）

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

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

  - spi： imx：當無法啟動 DMA 時，針對 PIO 重新設定 spi_imx_can_dma（） 選取 DMA 時，會針對 DMA 設定 ECSPI：spi_imx_setupxfer（） 設定 CTRL。SMC 並清除 dynamic_burst，spi_imx_dma_transfer（） 程式設計動態突發BURST_LENGTH和 SDMA 浮水印。如果無法準備 DMA 描述項 （dmaengine_prep_slave_single（） 傳回 NULL），則傳輸會失敗，並SPI_TRANS_FAIL_NO_START並回復至 PIO。動態突發 DMA 路徑使用自己的反彈緩衝區，而不是 SPI 核心的映射，因此不會設定 xfer->{tx，rx}_sg_mapped，並且跳過核心的 DMA->PIO 重試;驅動程式會在內部回復至 PIO。但不會復原任何 DMA 模式設定，因此 PIO 傳輸會使用 CTRL 執行。SMC 設置，錯誤的突發長度和dynamic_burst清除，傳輸的數據損壞。
    在設備樹中描述 ECSPI DMA 但在 ROM 固件上運行 SDMA （沒有外部sdma-imx7d.bin） 的 i.MX8MP 板上很容易遇到這種情況：每個 ECSPI DMA 準備都失敗。然後，ECSPI1 上的 Infineon SLB9670 TPM 會傳回移位的TPM2_GetCapability資料，並標記為欄位故障模式，永遠不會建立 /dev/tpmrm0。在重新執行 spi_imx_setupxfer（） 之前設定 controller->fallback，以便重新設定 ECSPI 就像一般 PIO 傳輸一樣。設定 controller->fallback 後，spi_imx_setupxfer（） 會看到 spi_imx_can_dma（） 傳回 false，因此會清除 spi_imx->usedma 並重新編程控制器 （清除 CTRL.SMC，還原dynamic_burst和 PIO 突發長度）。不需要明確的 spi_imx->usedma = false：
    setupxfer（） 已經從 can_dma（） 結果更新了它。（CVE-2026-72134）

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

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

  - accel/amdxdna：使用呼叫端用戶端進行偵錯 BO 同步 amdxdna_drm_sync_bo_ioctl（） 會在 ioctl 呼叫端的drm_file中查詢 args->handle。對於SYNC_DIRECT_FROM_DEVICE，它接著會呼叫 amdxdna_hwctx_sync_debug_bo（），但會傳遞 abo->client。amdxdna_hwctx_sync_debug_bo（） 會使用傳遞的用戶端作為 debug_bo_hdl 的控點命名空間，以及作為硬體內容 xarray 的擁有者。這些必須符合提供 args->handle 的檔案。BO 的預存用戶端指標是物件狀態，而不是 ioctl 內容。改為傳遞 filp->driver_priv，以符合原始控點查詢。（CVE-2026-72090）

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

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

  - Glances 是一款開放原始碼系統跨平台監控工具。在 4.5.6之前，glances/config.py 中的 as_dict_secure（） 僅檢查選項名稱，並透過未經驗證的 GET /api/4/config 和 GET /api/4/config/ip 要求公開內嵌在public_api值中的public_username和憑證。此問題已在 4.5.6中修正。（CVE-2026-68520）

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

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

  - tpm：讓 TPM 字元裝置不可搜尋 TPM 字元裝置會公開循序命令/回應介面，但其開啟的處理常式會保留 FMODE_PREAD 並啟用FMODE_PWRITE。在命令保留回應後，pread（fd， buf， 16， 0x1400） 會將 0x1400 作為 *off 傳遞給 tpm_common_read（）。
    傳輸長度以 response_length 為界，但在形成 data_buffer + *off 時未勾選使用偏移。因此，足夠大的偏移會導致透過 copy_to_user（） 讀取越界堆積，如果複製成功，則會透過下列 memset（） 進行越界零寫入。
    位置 I/O 不會為此介面提供一致的語意。任意讀取位移無法表示已循序耗用的回應量。寫入回呼一律會在data_buffer的開頭儲存命令，而 pwrite（） 不會更新檔案>f_pos，並且可能會讓循序讀取游標過時。從兩個開啟的處理常式呼叫 nonseekable_open（）。這會移除FMODE_PREAD和FMODE_PWRITE，導致位置讀取和寫入在到達 TPM 回呼之前以 -ESPIPE 失敗，並明確將檔案標示為不可搜尋。正常的 read（） 和 write（） 會繼續使用現有的循序f_pos游標，而回應狀態機器保持不變。在具有 KASAN 和 swtpm TPM2 裝置的 Linux 6.12 上進行測試： - 循序部分讀取傳回完整回應 - pread（） 和 preadv（） 傳回偏移0x1400 -ESPIPE - 傳回偏移零的 pwrite（） 和 pwritev（） -ESPIPE - 在拒絕的作業後，擱置回應保持不變 - 後續的正常命令/回應週期正常完成 - 未產生 KASAN 報告。（CVE-2026-72135）

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

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

  - cpu：hotplug：當一個執行個體失敗時，保留每個執行個體的回呼錯誤 cpuhp_invoke_callback（） 會解除相同熱插拔狀態的先前回呼。復原路徑目前會重複使用 ret，因此成功的復原可以隱藏原始錯誤，並讓失敗的轉換看起來成功。將復原結果與原始錯誤分開。（CVE-2026-72067）

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

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

  - Open_alpha1 2.7.5 VPN 2.72.4.02.6.21 中的 Windows 互動式服務允許本機驗證使用者繞過受信任的組態目錄限制，並透過繞過白名單檢查的特製選項載入任意設定檔 （）CVE-2026-63649

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

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

  - nvmet：修正 nvmet_sq_create（） 中的參照計數洩漏 在 nvmet_sq_create（） 中，在呼叫 nvmet_check_sqid（） 之前，會透過 kref_get_unless_zero（） 對 ctrl 進行參照。如果 nvmet_check_sqid（） 失敗，函數會直接傳回錯誤而不釋放引用，從而導致洩漏。透過跳到ctrl_put標籤來解決此問題，該標籤已經執行了必要的nvmet_ctrl_put（ctrl）。這可確保在此錯誤路徑上正確釋放參照。（CVE-2026-72128）

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

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

  - accel/amdxdna：拒絕沒有命令 BO 的使用者命令提交 amdxdna_drm_submit_execbuf（） 將使用者提供的命令 BO 控點直接傳遞至 amdxdna_cmd_submit（），且 drv_cmd == NULL。當控制碼AMDXDNA_INVALID_BO_HANDLE （0） 時，會跳過擷取 job->cmd_bo 的區塊，將其保留為 NULL，而且沒有檢查會在使用者路徑上拒絕它 （！job->cmd_bo 防護位於 ！= INVALID 分支內）。接著，作業會武裝並推送至 DRM 排程器。aie2_sched_job_run（） 採用 drv_cmd == NULL 路徑，並呼叫 amdxdna_cmd_set_state（job->cmd_bo） -> amdxdna_gem_vmap（NULL） -> to_gobj（NULL）->dev，這是 drm_sched 工作角色中的 NULL 指標解除參照。在具有探測 AMD NPU 的系統上，能夠存取加速節點的處理程序可能會觸發具有單一AMDXDNA_EXEC_CMD ioctl （cmd_handles = 0） 的核心 oops。只有內部驅動程式命令 （SYNC_DEBUG_BO / ATTACH_DEBUG_BO） 才能合法地傳遞AMDXDNA_INVALID_BO_HANDLE，並且它們總是設定drv_cmd。在提交阻塞點拒絕使用者提交的無效控制碼 （drv_cmd == NULL），以便涵蓋每個使用者路徑。由 0sec 自動化安全研究工具 （）https://0sec.ai 找到。
    (CVE-2026-72091)

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

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

  - Glances 是一款開放原始碼系統跨平台監控工具。在 4.5.6之前，glances/outputs/glances_restful_api.py 中的cors_origins防護使用完全相同的清單，而不是萬用字元成員資格，允許包含萬用字元的多來源清單保留cors_credentials，並將經過驗證的 REST API 資料公開給先前經過驗證的使用者造訪的不受信任網站。此問題已在 4.5.6中修正。
    (CVE-2026-68517)

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

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

  - nvmet-rdma：處理具有非零偏移量的內嵌資料。nvmet_rdma_use_inline_sg() 會將主機控制的內嵌資料偏移量映射到每個命令的內嵌分散清單中。邊界檢查允許任何滿足 off + len <= inline_data_size 的偏移量，但映射仍假設資料從第一個內嵌頁面開始：
    sg->offset = off；sg->length = min_t(int, len, PAGE_SIZE - off)。當連接埠配置為 inline_data_size > PAGE_SIZE (最高可設定為 max(SZ_16K, PAGE_SIZE)) 時，位於 (PAGE_SIZE, inline_data_size] 範圍內的偏移量會導致 PAGE_SIZE - off 下溢，因此 sg->length 被設定為約 4 GiB，導致區塊後端讀取遠超出第一個內嵌頁面。num_pages(len) 也會忽略偏移量，因此，如果 [off, off+len) 跨度跨越頁面邊界，則邊界偏移量會低估分散清單計數。正確映射偏移量：將其拆分為頁面索引和頁面內偏移量，從該頁面開始分散清單，並根據 page_off + len 計算頁面計數。由於請求分散清單現在可能從 inline_sg[page_idx] (而非 inline_sg[0]) 開始，因此將 nvmet_rdma_release_rsp() 中的內嵌 SGL 恆等測試泛化為範圍測試；
    否則持久性內嵌分散清單會被誤認為是已分配的分散清單，導致 nvmet_req_free_sgls() 釋放內嵌頁面 (並在 free_large_kmalloc() 中發出警告)。(CVE-2026-72129)

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

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

  - net：sparx5：init 失敗時取消註冊封鎖通知程式 sparx5_register_notifier_blocks（） 會在配置排序的工作佇列之前註冊 switchdev 封鎖通知程式。如果工作佇列配置失敗，錯誤路徑會取消註冊 switchdev 和 netdevice 通知程式，但會保留封鎖通知程式的註冊狀態。為工作佇列配置失敗路徑新增單獨的錯誤標籤，並在該處取消註冊 switchdev 封鎖通知程式。（CVE-2026-72109）

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

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

  - can： bcm：新增缺少的 rcu 清單註解和操作 sashiko-bot 指出，當 bcm_proc_show（） 遍歷 rcu_read_lock（） 下的 bcm_op 時，缺少在 bcm_[rx|tx]_setup（） 中使用 list_add_rcu（） 以具有正確初始化的 bcm_op 結構。為了涵蓋bcm_op的所有初始設定，list_add_rcu（） 呼叫會移至設定程式碼的結尾。同時，還要修復鏡像刪除端：稱為 bcm_remove_op（） 的 bcm_release（） - 它通過 call_rcu（） 釋放操作 - 在仍在 bo->tx_ops/bo->rx_ops 中鏈接的操作上，沒有先list_del_rcu（）。在將每個操作傳遞給 bcm_remove_op（） 之前，先將其與 list_del_rcu（） 解除鏈接，以匹配 bcm_delete_tx_op（）/bcm_delete_rx_op（） 中的現有模式。
    (CVE-2026-72120)

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

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

  - Glances 是一款開放原始碼系統跨平台監控工具。在 4.5.6之前，glances/actions.py 中的 _sanitize_mustache_dict（） 會清理 chevron.render（） 之前的個別 Mustache 值，允許相鄰的未逸出 Mustache 變數重建殼層運算子，當管理員設定的動作範本呈現攻擊者控制的處理程序或容器欄位時，secure_popen（） 會執行這些運算子。此問題已在 4.5.6中修正。（CVE-2026-68518）

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

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

  - sqlparse 是適用於 Python 的非驗證 SQL 剖析器模組。在 0.6.0之前，sqlparse/filters/output.py 無法逸出 sqlparse.format output_format='python' 和 output_format='php' 以及對應的 sqlformat -l 模式中引號之前的現有反斜線，因此允許特製的 SQL 在下游消費者執行或匯入產生的來源時終止產生的字串並插入 Python 或 PHP 程式碼。0.6.0 版已修正此問題。(CVE-2026-59894)

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

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

  - 已解決 Linux 核心中的下列弱點：net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack. (CVE-2026-72064)

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

ID	名稱	嚴重性
337370	Linux Distros 未修補弱點：CVE-2026-74357	high
337369	Linux Distros 未修補弱點：CVE-2026-72322	critical
337368	Linux Distros 未修補弱點：CVE-2026-72357	high
337367	Linux Distros 未修補弱點：CVE-2026-72360	high
337366	Linux Distros 未修補弱點：CVE-2026-72278	critical
337365	Linux Distros 未修補弱點：CVE-2026-74277	high
337364	Linux Distros 未修補弱點：CVE-2026-72461	high
337363	Linux Distros 未修補弱點：CVE-2026-74383	high
337362	Linux Distros 未修補弱點：CVE-2026-72452	high
337361	Linux Distros 未修補弱點：CVE-2026-72188	critical
337360	Linux Distros 未修補弱點：CVE-2026-72244	high
337359	Linux Distros 未修補弱點：CVE-2026-72024	high
337358	Linux Distros 未修補弱點：CVE-2026-74305	high
337357	Linux Distros 未修補弱點：CVE-2026-72296	critical
337356	Linux Distros 未修補弱點：CVE-2026-72295	high
337355	Linux Distros 未修補弱點：CVE-2026-74255	critical
337354	Linux Distros 未修補弱點：CVE-2026-72033	critical
337198	Linux Distros 未修補弱點：CVE-2026-72072	high
337197	Linux Distros 未修補弱點：CVE-2026-72082	medium
337196	Linux Distros 未修補弱點：CVE-2026-72071	high
337195	Linux Distros 未修補弱點：CVE-2026-72094	medium
337194	Linux Distros 未修補弱點：CVE-2026-72112	high
337193	Linux Distros 未修補弱點：CVE-2026-72061	high
337192	Linux Distros 未修補弱點：CVE-2026-72132	medium
337191	Linux Distros 未修補弱點：CVE-2026-72081	high
337190	Linux Distros 未修補弱點：CVE-2026-72107	high
337189	Linux Distros 未修補弱點：CVE-2026-72136	high
337188	Linux Distros 未修補弱點：CVE-2026-72079	high
337187	Linux Distros 未修補弱點：CVE-2026-72102	high
337186	Linux Distros 未修補弱點：CVE-2026-59893	high
337185	Linux Distros 未修補弱點：CVE-2026-72080	high
337184	Linux Distros 未修補弱點：CVE-2026-72093	high
337183	Linux Distros 未修補弱點：CVE-2026-72083	critical
337182	Linux Distros 未修補弱點：CVE-2026-72074	high
337181	Linux Distros 未修補弱點：CVE-2026-72076	high
337180	Linux Distros 未修補弱點：CVE-2026-72134	high
337179	Linux Distros 未修補弱點：CVE-2026-72090	high
337178	Linux Distros 未修補弱點：CVE-2026-68520	medium
337177	Linux Distros 未修補弱點：CVE-2026-72135	high
337176	Linux Distros 未修補弱點：CVE-2026-72067	high
337175	Linux Distros 未修補弱點：CVE-2026-63649	medium
337174	Linux Distros 未修補弱點：CVE-2026-72128	high
337173	Linux Distros 未修補弱點：CVE-2026-72091	medium
337172	Linux Distros 未修補弱點：CVE-2026-68517	medium
337171	Linux Distros 未修補弱點：CVE-2026-72129	critical
337170	Linux Distros 未修補弱點：CVE-2026-72109	high
337169	Linux Distros 未修補弱點：CVE-2026-72120	high
337168	Linux Distros 未修補弱點：CVE-2026-68518	high
337167	Linux Distros 未修補弱點：CVE-2026-59894	medium
337166	Linux Distros 未修補弱點：CVE-2026-72064	critical

偵測

Nessus 的 Misc. 系列

high

critical

high

high

critical

high

high

high

high

critical

high

high

high

critical

high

critical

critical

high

medium

high

medium

high

high

medium

high

high

high

high

high

high

high

high

critical

high

high

high

high

medium

high

high

medium

high

medium

medium

critical

high

high

high

medium

critical