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

  - mtd： ubi： 忙碌分離時釋放裝置參照 ubi_detach_mtd_dev（） 會透過 ubi_get_device（） 取得裝置參照，然後再檢查 UBI 裝置是否忙碌。忙碌的傳回路徑會捨棄 ubi->ref_count，但會保留裝置參照，因此在稍後分離之後無法釋放裝置物件。在傳回 -EBUSY 之前刪除裝置參照。（CVE-2026-90215）

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

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

  - 韌體：arm_scmi：IDR 失敗時釋放傳輸通道 如果傳輸通道設定成功，但下列 IDR 插入失敗，錯誤路徑會破壞傳輸裝置並釋放通道資訊，而不會叫用傳輸清除回呼。在銷毀裝置之前呼叫 chan_free（），以便以正常的拆卸路徑一致地釋放特定資源，例如 IRQ、信箱通道和映射的共用記憶體。（CVE-2026-93089）

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

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

  - ACPI： 處理器：驗證 MADT IOAPIC 項目界限 IOAPIC 熱插拔會直接剖析 MADT 及 _MAT 記錄。MADT 遍歷以前使用子表的宣告長度來在僅找到通用標頭之後推進游標。_MAT路徑同樣會將泛型標頭傳遞至 IOAPIC 協助程式。
    在讀取其欄位之前，驗證現行記錄是否具有完整的通用標頭、其宣告的長度是否包含在可用的記錄範圍中，以及類型化的 IOAPIC 記錄是否包含完整的固定 IOAPIC 內文。針對 MADT 和_MAT提供者路徑使用相同的關係。（CVE-2026-92522）

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

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

  - netfilter： nft_ct：將自訂期望支援移至 helper 最初，ct 期望支援呼叫 nf_ct_helper_ext_add（） 用於已確認的 conntracks，這是無效的，會觸發 splat。此問題已透過提交 1710eb913bdc （netfilter： nft_ct：跳過已確認 conntrack 的預期） 修正，該提交將它限制為未確認的 conntrack。不過，當 conntrack 未確認時，過早將預期插入預期清單會導致過時項目，因為 ct 延伸模組重新配置，透過 .pprev 指出錯誤的hlist_head。提交 7c9664351980 （netfilter：將 nat hlist_head 移至 nf_conn） 出於以下原因，將 nat hlist_head移至 nf_conn： 1.2. 當擴展區域發生重新分配時，我們需要通過hlist_replace_rcu修復bysource哈希頭。我寧願不增加結構的大小，nf_conn因為此功能的範圍非常有限：給定 expect_clash（） 將使 nf_ct_expect_related（） 報告 EBUSY，一次只能創建一個期望。因此，請放寬 nf_ct_expect_related（） 以在期望建立失敗時不要丟棄封包，因此，期望建立會盡最大努力。若要解決此問題，請新增內部 ct 協助程式，並將其附加至 conntrack 項目，以簡化現有 ct 協助程式的自訂 ct 預期支援。公開新的 nf_conntrack_helper_release（） 函式，以釋放已配置並附加至 conntrack 項目的內部協助程式，以建立自訂預期。nft_ct模組移除一律會等待 rcu 寬限期，然後在此之後觀察到 NULL 協助程式回呼。此修補程式也會將期望的建立限制為不同的協助程式，而不是針對此類預期建立的自訂協助程式。（CVE-2026-90237）

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

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

  - ublk：避免 xArray 分配失敗時的拆卸重試迴圈 __ublk_shmem_remove_ranges（） 會批次移除相符的 Maple Tree 範圍，但會先將每個範圍儲存到暫時的 XArray 中，以便在刪除 Maple Tree 鎖定後可以取消固定頁面。該臨時 xarray 在楓樹鎖下填充為 xa_store（...， GFP_ATOMIC）。如果儲存區在 mas_erase（） 之前失敗，則目前範圍會保留在樹狀結構中，而協助程式會傳回 false。然後，外部 ublk_shmem_remove_ranges（） 迴圈會立即重試相同的範圍。當不可部分完成配置不斷失敗時，拆卸路徑沒有前進進度。在註冊 SHMEM_ZC 緩衝區後radix_tree_node failslab 插入可以重現此問題： # 核心配置： # CONFIG_BLK_DEV_UBLK=y # CONFIG_DEBUG_FS=y # CONFIG_FAULT_INJECTION=y # CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_FAILSLAB=y echo 10 > /proc/sys/vm/nr_hugepages mkdir -p /tmp/htlb mount -t hugetlbfs none /tmp/htlb fallocate -l 4M /tmp/htlb/ublk_buf dev_id=$（kublk add -t null
    --shmem_zc \ --htlb /tmp/htlb/ublk_buf | awk -F '[ ：]' '/dev id/ {print $3}'） echo 1 > /sys/kernel/slab/radix_tree_node/failslab echo Y > /sys/kernel/debug/failslab/cache-filter echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait echo 1 > /sys/kernel/debug/failslab/interval echo -1 > /sys/kernel/debug/failslab/times echo 100 > /sys/kernel/debug/failslab/probability kublk del -n $dev_id 在未修正的核心上，delete 命令在 3 秒後仍在執行。停用 failslab 會使其返回。錯誤插入堆疊顯示： should_failslab kmem_cache_alloc_lru_noprof __xas_nomem
    __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev 從拆卸迴圈中移除分配。保留現有的批次限制，但在固定大小的堆疊陣列中收集 {base_pfn， nr_pages} 對。一旦找到相符的範圍，就會在卸除鎖定之前從楓樹中刪除該範圍，因此每次成功的掃描都會取得進展，而不會依賴任何GFP_ATOMIC配置。在相同的 failslab 設定下，修正核心在大約 45 毫秒內成功完成 kublk del -n $dev_id 。
    (CVE-2026-90181)

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

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

  - virtio_balloon：在裝置關機前靜止氣球工作 提交 8bd2fa086a04 （virtio：在 device_shutdown（）） 上中斷和重設 virtio 裝置） 新增了一個通用的 virtio 匯流排 .shutdown 處理常式，可在 device_shutdown（） 期間（即重新啟動和 kexec 時）中斷和重設每個 virtio 裝置。virtio_balloon 沒有提供自己的 .shutdown，因此當 balloon 的非同步工作仍處於武裝狀態時，通用路徑會執行。一旦裝置損壞，virtballoon_free_page_report（） 中的 virtqueue_add_inbuf（） 會傳回 -EIO 並觸發其 WARN_ON_ONCE（）。在使用 panic_on_warn 啟動的核心上，將普通的重新啟動（例如基於 kexec 的升級）變成 device_shutdown（） 中間的致命錯誤，因此機器永遠不會到達新核心。放寬單一 WARN_ON_ONCE（） 只會隱藏症狀：inflate/deflate 和 OOM 路徑不會發出警告，它們會呼叫 wait_event（vb->acked， ...），而是會在無法再完成的損壞佇列上永久封鎖。設備必須靜止，而不僅僅是保持安靜。新增 .shutdown 處理常式，當裝置仍處於活動狀態時，透過共用 virtballoon_quiesce（） 協助程式靜止氣球，然後才透過 virtio_device_shutdown（） 中斷並重設它。與 virtballoon_remove（） 不同，氣球工作佇列不會被破壞，因為關機不會釋放裝置，而且 cancel_work_sync（） 和stop_update已經防止任何進一步的工作排入佇列。（CVE-2026-90129）

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

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

  - ARM：9484/1：觸發未處理的使用者故障時啟用中斷PREEMPT_RT傳送訊號時需要啟用中斷。當 do_DataAbort（）/do_PrefetchAbort（） 觸發未處理的使用者錯誤時，即 'inf->fn（）' 傳回一個非零值，並且未在鉤子函式中啟用中斷，則會在停用中斷的情況下呼叫 force_sig_fault（）。這可以由執行 bkpt 指令的使用者程式觸發，核心配置為 CONFIG_PERF_EVENTS=n。當觸發未處理的使用者錯誤時，在 do_DataAbort（）/do_PrefetchAbort（） 中啟用中斷以解決問題。
    (CVE-2026-90304)

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

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

  - cxl/region：修正 find_pos_and_ways（） 錯誤路徑中的釋放後使用 錯誤路徑會在記錄包含解碼器名稱的錯誤之前釋放其對切換解碼器的參照。如果釋放的參照是最後一個參照，則可以在錯誤訊息存取其名稱之前釋放解碼器。報告錯誤後刪除參照。（CVE-2026-92484）

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

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

  - arm_mpam： 修正錯誤中斷後解除綁定時的 NULL 指標解除參照 如果使用者在執行 mpam_disable（） 以回應錯誤中斷之後解除綁定 MSC，則當 mpam_disable（） 將 drvdata 設為 NULL 時，會發生 NULL 指標的解除參照。新增早期返回至驅動程式移除回呼以避免此情況。（CVE-2026-90271）

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

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

  - net/sched： sch_htb：限制htb_classify內部類別篩選器躍點 htb_classify（） 透過切換到 cl->filter_list 來遵循每個篩選器選取的內部類別，但絕不會限制躍點數。內部類別上的篩選器可以指向自身或指向另一個指向回來的內部類別，從而在封包分類路徑中建立無限迴圈，其中 qdisc 鎖定被保留，並且 BH 停用了來自單一封包的軟鎖定/錯誤。使用躍點計數器綁定遍歷，並在超過界限時丟棄帶有速率限制警告的資料包。在 TC_ACT_* 交換器耗用分類器判定之後，計數器會在內部過濾器鏈被拾取的點遞增，因此最後一個允許鏈上的終端機 TC_ACT_QUEUED/STOLEN/TRAP 仍將 *qerr 設定為 __NET_XMIT_STOLEN，並且此 qdisc 或其父項不會將封包作為丟棄收費。邊界是TC_HTB_MAXDEPTH的，取自 HTB 自己的參數，而不是來自 qdisc 階層深度限制。類別等級從 0 到 TC_HTB_MAXDEPTH - 1，因此嚴格降低等級的遊歷最多可能需要 TC_HTB_MAXDEPTH 跳。這種下降是理智配置的作用，但這裡假設它而不是強制執行：htb_find（） 針對 qdisc 中的每個類解析 classid，因此過濾器可以平等地選擇一個同級或一個祖先。一般根 -> 內部 -> 葉路徑會採用單一躍點，因此界限不會影響合法分類。無論CONFIG_NET_CLS_ACT如何，htb_classify（） 現在都可以傳回 NULL，而以前每個 NULL 傳回都位於該 ifdef 內。因此，htb_enqueue（） 中的 NULL 處理常式也不能保持條件，因此請刪除它周圍的 ifdef。這符合 hfsc_enqueue（），它總是無條件地處理 NULL 類別。如果沒有它，則在沒有動作的情況下建置的核心會解除參照 NULL 類別，而不是捨棄。重新建立錯誤的條件： - CONFIG_NET_SCHED、CONFIG_NET_SCH_HTB、CONFIG_NET_CLS_U32、CONFIG_LOCKUP_DETECTOR。- 在裝置上建立 HTB qdisc （例如 lo），新增具有葉子項的內部類別1:1，安裝根 u32 篩選器1:1選取 ，並在選取時1:1安裝內部類別 u32 篩選器1:1。1:10 - 傳送一個封包 （ping）。在未固定的核心上，分類迴圈在持有 qdisc 鎖定的情況下旋轉;當 softlockup_panic=1 時，它會恐慌。- 可透過 unshare -Urn （CAP_NET_ADMIN） 從無權限使用者連線。（CVE-2026-90053）

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

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

  - RDMA/cxgb4：修正 write_tpt_entry（） 中的dereg_skb洩漏和雙重釋放 當設備處於致命錯誤狀態時，write_tpt_entry（） 在將調用方預先分配的 skb 交給傳輸路徑之前返回 -EIO;
    其分配失敗傳回也執行相同的操作。c4iw_dereg_mr（） 會忽略錯誤並釋放 MHP，從而洩漏 MHP->dereg_skb。相反，c4iw_get_dma_mr（） 會在 dereg_mem（） 已經消耗 skb 後第二次釋放 skb，這是雙重釋放。將 write_tpt_entry（） 設為非 NULL skb 的唯一擁有者，並在移交至 c4iw_ofld_send（） 之前的每次傳回時釋放它：致命錯誤、tpt 和 stag 分配失敗。c4iw_ofld_send（） 會在成功和錯誤時消耗 skb，因此在 dereg_mem（） 之後刪除 c4iw_get_dma_mr（） 中的冗餘 kfree_skb（）。（CVE-2026-90417）

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

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

  - net/sched： fq：將溢位邊界新增至量子和初始量子 fq_init（） 計算量子 = 2 * psched_mtu（） 和 initial_quantum = 10 * psched_mtu（），沒有溢位檢查。具有巨大 MTU 的裝置 （例如，接受 MTU 2147483634 的 max_mtu == 0 的虛擬裝置） 會使 psched_mtu（） 傳回 0x80000000;2 * 和 10 * 乘法在 32 位算術中換行為 0，因此 q->量子 == 0。然後在 fq_dequeue（） 中，credit-refill 循環將 0 添加到 f->credit（保持 <= 0），並在 qdisc 鎖定下永遠開始循環，從而創建軟鎖定。在乘法之前將 psched_mtu（） 限制為 [1， 1 << 20]，這樣乘積就無法換行，然後將結果限制為 1 << 20，以符合 fq_change（） 中已經在 TCA_FQ_QUANTUM 上強制執行的界限。
    重新建立錯誤的條件：MTU （加上 hard_header_len） 足夠大以換行 2 * psched_mtu（） 的裝置 （例如，max_mtu == 0 的虛擬裝置接受 MTU 2147483634）。需要在使用者命名空間中CAP_NET_ADMIN。（CVE-2026-90076）

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

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

  - smb： smbdirect：接受失敗時，在記憶體集區之前銷毀 QP 在 smbdirect_accept_connect_request（） 的rdma_accept_failed錯誤路徑上，剛好在上面張貼的接收 io 歸 QP 所有 （recv_io 在成功張貼後設定為 NULL）。錯誤路徑在 smbdirect_connection_destroy_qp（） 之前失敗為 smbdirect_connection_destroy_mem_pools（），因此當該 recv_io 在 QP 上仍未完成時，記憶體集區和 recv_io slab 快取會遭到破壞。smbdirect_connection_destroy_qp（） （ib_drain_qp（）） 中的 drain 是執行 recv 完成的項目，將 recv_io 返回到可用清單，因此首先銷毀集區會讓物件在 kmem_cache_destroy（） 時保持未完成狀態 （Slab 快取仍有物件），然後將其釋放到已銷毀的記憶體集區 （mempool_free_bulk NULL 指標解除參照）。給rdma_accept_failed自己的拆解，先耗盡 QP，然後銷毀記憶體集區，然後返回。其餘標籤 （post_recv_io_failed 起） 會在張貼recv_io之前執行，因此它們會保留 mem-pools-then-qp 順序。kmem_cache_destroy（） 時未完成的recv_io： [3487.344647] ============================================================================= [ 3487.349942] 錯誤 smbdirect_recv_io_cache_ffff88811ba99000 （未受污染）： __kmem_cache_shutdown（） [3487.356078] 上剩餘的物件 ----------------------------------------------------------------------------- [ 3487.356078] 3487.356738[ ] 物件 0xffff8881511c3440 @offset=13376 [ 3487.358464] 分配於 mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254 [ 3487.361197] mempool_alloc_noprof+0x18c/0x290 [ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780 [ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80 [ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.362779] cma_cm_event_handler+0x9c/0x230 [3487.363096 ] cma_ib_req_handler+0x2682/0x45d0 [ 3487.363414] cm_process_work+0x56/0x3d0 [ 3487.363676] cm_work_handler+0x8a0e/0xd000 [ 3487.367496] process_scheduled_works+0xa07/0x13a0 [ 3487.367859] worker_thread+0x7c9/0xc80 [ 3487.368148] kthread+0x341/0x430 [ 3487.368407] ret_from_fork+0x3a8/0x7a0 [3487.368704] ret_from_fork_asm+0x1a/0x30 [ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240（workingset|head|node=0|zone=2） [ 3487.372840] ------------[剪到這裡 ]------------ [ 3487.373195] 警告：mm/slub.c：1244 at __slab_err+0x1a/0x30， CPU#6：
    kworker/6:84/22254 [ 3487.373759] 連結的模組： [ 3487.373993] CPU： 6 UID： 0 PID： 22254 通訊：
    kworker/6:84 污染：G B 7。 1.0-next-20260623+ #88 搶佔（延遲） [ 3487.374778] 污染： [B]=BAD_PAGE [3487.377830] 硬體名稱：QEMU 標準電腦 （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3487.378515] 工作佇列：ib_cm cm_work_handler [ 3487.378820] RIP： 0010：__slab_err+0x1a/0x30 [3487.379129] 代碼：90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 00 be 01 00 00 00 e8 f775 45 00 90 <0f> 0b 90 c3 cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3487.383255] RSP： 0018：ffff888220fc7050 EFLAGS： 00010093 [ 3487.383643] RAX： ffffffff8168e60a RBX：
    ffff88810955e640 RCX：ffff88821c381d80 [ 3487.384158] RDX：000000000000000000 RSI：0000000000000008 RDI：
    ffffffff870fa080 [ 3487.384662] RBP： ffff888220fc7068 R08： ffffffff870fa087 R09： 1ffffffff0e1f410 [3487.385192] R10： dffffc00000000000 R11： ffffffbfff0e1f411 R12： ffffea0005447210 [ 3487.385674] R13：
    ffffea0005447000 R14： ffff888220fc7068 R15： ffff88812a8ab300 [ 3487.388932] FS： 000000000000000000（0000） GS：ffff888427e76000（0000） knlGS：000000000000000000 [ 3487.389529] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [ 3487.389934] CR2： 00007ffcf2d84fd8 CR3： 0000000111d64006 CR4： 0000000000f72ef0 [3487.390440] PKRU： 55555554 [ 3487.390641] 呼叫追蹤： [ 3487.390826] [ <TASK> 3 ---truncated--- （CVE-2026-90172）

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

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

  - RDMA/core：修正 ib_query_qp（） 中的釋放後使用 當透過網路連結流程查詢 QP 時，所述 QP 的唯一同步機制是 rdma_restrack_get（），同時在 QP 銷毀路徑期間 rdma_restrack_del（） 會在 ib_destroy_qp_user（） 函式的末尾呼叫，為時已晚，因為屆時所述 QP 的供應商特定資源已經被銷毀， 並且在稱為 rdma_restrack_del（） 之前，仍然可以訪問此 QP，這可能會導致下面的釋放後使用。
    透過將 rdma_restrack_begin_del（） 移至 ib_destroy_qp_user（） 的開頭來修正此問題，而 （） 又會等待 QP 的所有使用完成，然後將其從資料庫中移除，以防止在銷毀時存取它。RIP： 0010：ib_query_qp+0x15/0x50 [ib_core] 代碼： 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP： 0018：ff11000108a8f2f0 EFLAGS： 00010202 RAX：
    0000000000000000000 RBX：ff11000108a8f370 RCX：ff11000108a8f370 RDX：000000000000000000000000 RSI：ff11000108a8f3d8 RDI：00000000000000000 RBP：ff1100010de5a000 R08：00000000000000e80 R09：0000000000000004 R10：
    ff110001057a604c R11： 000000000000000000 R12： ff11000108a8f370 R13： ff110001090e8000 R14： 000000000000000000 R15： ff110001057a602c FS： 00007f2ffd8db6c0（0000） GS：ff110008dc90b000（0000） knlGS：0000000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：00000000000000000000 CR3：0000000010b9a7004 CR4：0000000000373eb0 呼叫追蹤： <TASK> mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ？__wake_up+0x40/0x50 ？netlink_broadcast_filtered+0x15a/0x550 ？kobject_uevent_env+0x562/0x710 ？ep_poll_callback+0x242/0x270 ？
    __nla_put+0xc/0x20 ？nla_put+0x28/0x40 ？nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ？fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450
    __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ？nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ？__alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ？copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ？__futex_wait+0x95/0xf0？
    __futex_wake_mark+0x40/0x40 ？futex_wait+0x67/0x100 ？futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53 （CVE-2026-92512）

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

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

  - nvme/ioctl：使用 nvme_cmd_allowed（） 檢查SUBMIT_IO 與 IO_CMD/IO64_CMD 不同，NVME_IOCTL_SUBMIT_IO從不呼叫 nvme_cmd_allowed（）。因此，無特權的呼叫端可以在分割區裝置上發出 I/O，或透過唯讀檔案描述元寫入。傳遞旗標和open_for_write通過和拒絕不允許的命令
    -EACCES。（CVE-2026-90227）

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

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

  - net/sched： fq_codel：限制預設量子，MTU fq_codel_init（） 設定 q->quantum = psched_mtu（qdisc_dev（sch）），而不進行限制。具有巨大 MTU 的裝置 （例如，接受 MTU 2147483634 的 max_mtu == 0 的虛擬裝置） 會使 psched_mtu（） 傳回 0x80000000，這會將帶正負號的 flow->deficit 溢位到 fq_codel_dequeue（） 中的 INT_MIN，從而造成無限迴圈和軟鎖定。模擬 fq_codel_change（） 並限制為 [256， FQ_CODEL_QUANTUM_MAX]。同樣的未箝制 psched_mtu（） 被分配給下面的 q->cparams.mtu，並且 fq_codel_change（） 永遠不會更新它。codel_should_drop（） 測試 *backlog <= params->mtu;
    使用 mtu == 0x80000000 （~2 GiB） 和預設的 32 MiB memory_limit，則測試一律為 true，因此 CoDel 會以無訊息且完全停用 （沒有丟棄，沒有 ECN）。宣告單一限制的 mtu，並從中指派 q->quantum 和 q->cparams.mtu，這也會移除雙重 psched_mtu（） 呼叫。重新建立錯誤的條件：其 MTU （加上 hard_header_len） 將 psched_mtu（） 包裝到符號位元中的裝置 （例如，max_mtu == 0 的虛擬裝置接受 MTU 2147483634）。需要在使用者命名空間中CAP_NET_ADMIN。
    (CVE-2026-90075)

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

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

  - wifi： iwlwifi： mvm：修正 TXF 金鑰清理程式中的差一錯誤 iwl_mvm_frob_txf_key_iter（） 會追蹤迴圈變數「i」中最後一個相符的位元組位置。當找到完整的索引鍵相符 （match == keylen） 時，'i' 指向相符索引鍵的最後一個位元組。因此，內存集的起始偏移量應該是 i + 1 - keylen，而不是 i - keylen;目前的程式碼在比對前將一個位元組歸零，並使最後一個金鑰位元組未清理。
    (CVE-2026-93064)

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

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

  - nvmet：修正 nvmet_auth_negotiate（） 中的堆積越界讀取 nvmet_execute_auth_send（） 會以主機提供的傳輸長度 （tl） 配置 DH-HMAC-CHAP 訊息緩衝區，並將其交給 nvmet_auth_negotiate（），而不傳遞 tl。然後，nvmet_auth_negotiate（） 讀取 negotiate 標頭，並針對每個 halen 雜湊識別碼和 dhlen DH 群組識別碼，索引到固定的 idlist[60] 陣列中（idlist[0..halen 處的雜湊值），idlist[30..] 處的群組）。傳輸長度和 halen/dhlen 都未經過驗證。惡意或不合規的主機可以報告小於協商結構的 tl，或大於陣列的 halen/dhlen （兩者都是 u8，最多 255），使迴圈讀取超過分配的緩衝區末端 （堆積越界讀取）。同級 nvmet_auth_reply（） 已針對結構大小驗證 tl;談判路徑沒有。將 tl 傳遞到 nvmet_auth_negotiate（） 中，拒絕未涵蓋協商資料的 tl 加上一個完整的通訊協定描述元，並拒絕大於 NVME_AUTH_DHCHAP_MAX_DH_IDS 的 halen/dhlen。（CVE-2026-90230）

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

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

  - RDMA/rvt：埠配置失敗後傳回空值 rvt_alloc_device（） 會在埠陣列無法配置 IB 裝置時解除配置，但接著傳回已釋放配置的指標。呼叫端會將任何非 NULL 值視為有效，並取消參照它，導致釋放後使用。在解除配置之後立即傳回 NULL，讓呼叫端可以傳播配置失敗。（CVE-2026-93104）

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

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

  - wifi： mt76： mt7915：如果 MCU 拒絕協議，則取消連結 TWT 流程 在將協議傳送至韌體之前，流程會新增至 dev->twt_list，但錯誤路徑會使其保持連結狀態，而從未設定 flowid_mask。然後，當流槽仍在清單中時，可以重複使用和記憶，從而損壞twt_list，並且刪除站點會在該 mt7915_mac_twt_sched_list_add（） 稍後遍歷後面留下一個懸空的條目。
    (CVE-2026-90357)

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

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

  - null_blk：裝置關機時的釋放區域陣列 null_init_zoned_dev（） 會在分區裝置開啟電源時配置 dev->zones，但 null_del_dev（） 永遠不會在關機時釋放它;dev->zones 只會在稍後的 null_free_dev（） 中移除 configfs 目錄時釋放。如果裝置關閉電源，然後再次開啟，null_init_zoned_dev（） 會配置一個新陣列並覆寫 dev->zones 指標，從而在每次電源循環時洩漏先前的配置。透過 null_free_zoned_dev（） 釋放 null_del_dev（） 中的 dev->zones 來解決這個問題。不再需要在 null_free_dev（） 中呼叫 null_free_zoned_dev（），因為每個呼叫者都已經先呼叫 null_del_dev（）：在 nullb_device_release（） 之前透過 nullb_group_drop_item（）、在 null_create_dev（） 的 null_add_dev（） 錯誤路徑中以及在 null_destroy_dev（） 中。移除冗餘呼叫。並在兩個存放區包裝函式中採用 zone_cond_store（） 周圍的 &lock，以序列化 dev->zones 檢查和取消參照，以針對其 alloc/free（已在 &lock 下執行）。以前沒有問題的原因是只有 nullb_device_release（） 或 null_exit（） 釋放了 dev->zones，這保證了後續使用者不會存取 configfs 介面。（CVE-2026-90187）

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

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

  - uprobes/x86：將最佳化的 uprobe 從 nop5 移至 nop10 Andrii 報告了最佳化 uprobes [1] 的問題，該問題可能會因呼叫指令將傳回位址儲存在堆疊上而破壞紅區區域，其中使用者程式碼可能會保留臨時資料而不調整 rsp。通過將優化的 uprobes 移動到 10 位元組 nop 指令之上來解決這個問題，這樣我們就可以在進行調用之前擠壓另一條指令以逸出紅區區域，例如： lea -0x80（%rsp）， %rsp call tramp 請注意，lea 指令用於調整 rsp 暫存器而不更改標誌。我們使用 nop10 並按照 Peterz [2] 的建議進行前後優化的轉換。最佳化路徑 （int3_update_optimize）： 1） set_swbp（） 安裝 uprobe 後的初始狀態：cc 2e 0f 1f 84 00 00 00 00 00 從偏移 0 開始，這是 INT3，後面接著原始 10 位元組 NOP 的尾部。在先前取消最佳化之後，位元組 5..9 可能仍包含舊的呼叫指令，該指令對已有的執行緒仍然有效。2） 重寫 LEA 尾部並呼叫位移：cc [8d 64 24 80 e8 d0 d1 d2 d3] 從偏移量 0 開始，這會卡在 uprobe INT3 上。位元組 1..9 不是可執行的進入點，而位元組 0 被困住。3） 發布第一個 LEA 位元組：[48] 8d 64 24 80 e8 d0 d1 d2 d3 從偏移量 0 開始，這是：
    lea -0x80（%rsp）， %rsp 調用 <uprobe-trampoline> 取消最佳化路徑 （int3_update_unoptimize）： 1） 初始最佳化狀態：48 8d 64 24 80 e8 d0 d1 d2 d3 與上述 3） 相同。2） 在還原 NOP 位元組之前捕獲新條目：[cc] 8d 64 24 80 e8 d0 d1 d2 d3 從偏移量 0 開始，此陷阱。已執行 LEA 的執行緒仍可在位移 5 到達完整的 CALL。3） 還原原始 NOP 的位元組 1..4，同時保留位元組 0 被捕獲，位元組 5 作為 CALL。cc [2e 0f 1f 84] e8 d0 d1 d2 d3 從偏移量 0 開始，這仍然會陷入困境。
    位移 5 仍然是已超過第一個 LEA 位元組的任何執行緒的呼叫。4） 發布原始 NOP 的第一個位元組：[66] 2e 0f 1f 84 e8 d0 d1 d2 d3 從偏移量 0 開始，這是恢復的 10 位元組 NOP;
    CALL 操作碼和位移現在只是 NOP 運算元。位移 5 仍解碼為已存在的執行緒的 CALL。給定的 nop10 指令位址只有一個目標 uprobe-trampoline，因此 CALL 指令不會在未最佳化/最佳化週期中變更。因此，在 CALL 指令中先佔的任何任務都保證會觀察該 CALL，而不是其他任何項目。注意，如 [2] 中所述，我們需要使用以下 nop10：PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10：
    0x66、0x2e、0x0f、0x1f、0x84、0x00、0x00、0x00、0x00 0x00 -- cs nopw 0x00000000（%rax，%rax，1），這意味著我們需要允許0x2e對應到函數中INAT_PFX_CS屬性is_prefix_bad前置詞。此外，將從 uprobe 蹦床調用時的 uprobe 系統調用錯誤更改為 -EPROTO，以便我們能夠檢測到固定的核心。最佳化的 uprobe 效能保持不變： uprobe-nop ： 3.129 0.013M/s uprobe-push ：
    3.045 0.006M/s uprobe-ret ： 1.095 0.004M/s --> uprobe-nop10 ： 7.170 0.020M/s uretprobe-nop ： 2.143 0.021M/s uretprobe-push ： 2.090 0.000M/s uretprobe-ret ： 0.942 0.000M/s --> uretprobe-nop10： 3.381 0.003M/s usdt-nop ： 3.245 0.004M/s --> usdt-nop10 ： 7.256 0.023M/s [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ [2] https://lore.kernel.org/bpf/20260518104306。GU3102624@noisy.programming.kicks-ass.net/#t （CVE-2026-93164）

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

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

  - wifi：mt76：取消重設和 rc 在裝置取消註冊時運作 兩個驅動程式在取消註冊時取消了 dump_work，但留下reset_work和rc_work只能由 mt76_free_device（） 中的 destroy_workqueue（） 排清，該 （） 會在硬體取消註冊和硬體停止後執行。在該視窗中觸發的reset_work會呼叫 ieee80211_restart_hw（） 並在未註冊的硬體上重新武裝mac_work，並且rc_work觸及正在拆除的站點狀態。提前取消兩者，並取消dump_work。（CVE-2026-90365）

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

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

  - firmware_loader：在將 fw_priv 新增至 pending_fw_head 之前，請勿將已完成的 sysfs 後援要求 fw_load_sysfs_fallback（） 呼叫排入佇列 device_add（）。device_add（） 會發佈後援載入介面，因此透過掃描 sysfs 發現裝置的使用者空間協助程式可以將 0 寫入載入屬性，並在要求排入佇列為擱置狀態之前完成要求。在交錯 firmware_loading_store（） 呼叫 fw_state_done（） 時，pending_list 仍然指向自身，因此它無法從pending_fw_head中刪除條目。接著，後續的無條件 list_add（） 會將已完成的fw_priv排入佇列。釋放要求之後，pending_fw_head可以保留釋放記憶體的指標，而下一個後援要求可能會在驗證清單時出錯。只有進行中的後援請求需要暫停或重新啟動中止處理。如果要求在 device_add（） 之後已完成，請從後援路徑傳回成功，而不傳送另一個 uevent、再次等待或將其排入待處理佇列。這會保留pending_fw_head僅包含作用中後援要求的不變量。（CVE-2026-90284）

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

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

  - SMB： SMBdirect：使用 ib_free_cq（） 釋放完成佇列 smbdirect_connection_destroy_qp（） 會使用 ib_alloc_cq_any（） 建立傳送和接收完成佇列，這IB_POLL_WORKQUEUE會啟用在工作佇列上執行 ib_cq_poll_work（） 的內部完成處理常式。使用 ib_destroy_cq（） 拆除這些 CQ 可以釋放它們，而無需先取消該輪詢工作。如果提供者延遲張貼完成 （例如，Soft-RoCE （rxe） 在 rdma_destroy_qp（） 之後從 rxe_receiver（） 張貼 RNR 錯誤，則處理常式會在已釋放的 CQ 上重新排入 ib_cq_poll_work（） 佇列，並在 rxe_req_notify_cq（） 中出現後續存取錯誤。使用 ib_free_cq（），這會在釋放 CQ 之前cancel_work_sync（）輪詢工作，因此任何完成處理常式都無法針對已釋放的佇列執行。[ 1236.599526] ================================================================== [ 1236.602142] 錯誤：KASAN：ib_cq_poll_work+0xd0/0x1a0 中的 slab-use-after-free [ 1236.605524] 透過任務 kworker/4：1H/82 在 addr ffff888111865800 讀取大小 8 [ 1236.609017] [ 1236.609270] CPU：4 UID：0 PID：82 Comm：kworker/4：1H 未受污染 7.2.0-rc3-next-20260717-virtme #110 PREEMPT（lazy） [ 1236.609287] 硬體名稱：QEMU 標準 PC （i440FX + PIIX， 1996）、BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 1236.609498] 工作佇列：ib-comp-wq ib_cq_poll_work [1236.609525] 呼叫追蹤： [ 1236.609536] [ 1236.609545<TASK> ] __dump_stack+0x21/0x60 [ 1236.609562] dump_stack_lvl+0xc2/0x100 [ 1236.609573] print_address_description+0x77/0x200 [ 1236.609587] ？ ib_cq_poll_work+0xd0/0x1a0 [ 1236.609597] print_report+0x58/0x70 [ 1236.609607] kasan_report+0x117/0x150 [1236.609623] ？ ib_cq_poll_work+0xd0/0x1a0 [ 1236.609636] ？ process_scheduled_works+0x954/0x1600 [1236.609650] ib_cq_poll_work+0xd0/0x1a0 [ 1236.609662] ？ process_scheduled_works+0x954/0x1600 [1236.609674] process_scheduled_works+0xc22/0x1600 [ 1236.609698] ?__pfx_process_scheduled_works+0x10/0x10 [ 1236.609713] ？ __pfx_assign_work+0x10/0x10 [ 1236.609726] ？ lock_is_held_type+0x7b/0x110 [ 1236.609741] worker_thread+0x975/0xee0 [ 1236.609757] ？ __pfx_do_raw_spin_lock+0x10/0x10 [ 1236.609775] ？
    __kthread_parkme+0x21e/0x260 [ 1236.609789] kthread+0x3a6/0x490 [ 1236.609800] ？
    __pfx_worker_thread+0x10/0x10 [ 1236.609809] ？ __pfx_kthread+0x10/0x10 [ 1236.609820] ret_from_fork+0x55a/0xa20 [ 1236.609835] ？ __pfx_ret_from_fork+0x10/0x10 [ 1236.609850] ？
    __pfx_kthread+0x10/0x10 [ 1236.609861] ret_from_fork_asm+0x1a/0x30 [ 1236.609880] 1236.609886</TASK> [ ]1236.661292 [] 作業 5076 分配： [ 1236.662640] kasan_save_track+0x3e/0x80 [ 1236.663842]
    __kasan_kmalloc+0x72/0x90 [ 1236.664763] __kmalloc_noprof+0x2b0/0x5d0 [ 1236.665356]
    __ib_alloc_cq+0x284/0x1000 [ 1236.666573] __ib_alloc_cq_any+0x23e/0x340 [ 1236.668654] smbdirect_connection_create_qp+0x6f7/0x1070 [ 1236.669757] smbdirect_accept_connect_request+0x500/0x1ca0 [1236.672625] smbdirect_listen_rdma_event_handler+0x1655/0x1c50 [ 1236.673930] cma_listen_handler+0x1bf/0x260 [ 1236.674923] cma_cm_event_handler+0x128/0x380 [ 1236.676926] cma_ib_req_handler+0x2d3d/0x4de0 [ 1236.678368] cm_process_work+0xb0/0x530 [ 1236.680454] cm_queue_work_unlock+0xb1/0x230 [ 1236.681673] cm_work_handler+0x969f/0xdca0 [ 1236.682704] process_scheduled_works+0xc22/0x1600 [ 1236.683447] worker_thread+0x975/0xee0 [ 1236.685901] kthread+0x3a6/0x490 [ 1236.688164] ret_from_fork+0x55a/0xa20 [ 1236.689522] ret_from_fork_asm+0x1a/0x30 [1236.690073] [ 1236.690378] 被任務 5137 釋放： [ 1236.692242] kasan_save_track+0x3e/0x80 [ 1236.694272] kasan_save_free_info+0x40/0x50 [ 1236.695514] __kasan_slab_free+0x3a/0x60 [ 1236.696773] kfree+0x14e/0x4e0 [ 1236.697216] ib_destroy_cq_user+0x18d/0x250 [ 1236.699817] smbdirect_connection_destroy_qp+0xf2/0x280 [1236.702115] smbdirect_socket_destroy_sync+0x1607/0x2720 [ 1236.704062] smbdirect_socket_release+0x140/0x280 [ 1236.705286] smb_direct_free_transpor ---truncated--- （CVE-2026-90173）

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

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

  - 從 /etc/resolv.conf 檔案或 LOCALDOMAIN 環境變數初始化 DNS Stub 解析器 （其搜尋清單包含 GNU C 程式庫版本2.262.44中大約 200 個字元或更多字元的網域），會導致宣告失敗，進而中止處理程序。將搜尋清單複製到固定大小的 _res.defdname 緩衝區時，解析器會截斷搜尋清單，然後宣告副本與完整組態一致。一致性檢查與錯誤的大小進行比較，並且未處理不適合的第一個項目，因此正確截斷的清單無法宣告。任何透過程式庫解析名稱的處理程序都會受到影響，包括長時間執行的處理程序，這些處理程序會在變更後的下一個查詢上重新載入 /etc/resolv.conf。搜尋網域通常是從透過 DHCP 或從 VPN 伺服器接收的資料寫入 /etc/resolv.conf，因此本機網路上的攻擊者可以在沒有目標系統權限的情況下觸發此動作，但需經過網路組態軟體的驗證。
    (CVE-2026-8674)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，未經驗證的攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。若要成功攻擊，必須有攻擊者以外之他人的互動。若成功攻擊此弱點，未經授權即可造成 Oracle VM VirtualBox 懸置或經常重複性當機 (完全 DOS)，以及未經授權即可更新、插入或刪除部分可存取的 Oracle VM VirtualBox 資料。(CVE-2026-87278)

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

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

  - 在 Artifex MuPDF 中發現一個缺陷，直到 b6d17493700c621c0e70036980a6ebd06d2202c9。受此弱點影響的是元件 PDF Xref Loading 的 pdf-stream.c 檔案的函式pdf_open_filter。
    執行操作可能會導致 NULL 指標解除參照。攻擊者可在遠端執行此攻擊。惡意利用已發布且可能遭到利用。此修補程式稱為 3df1e30f9d7b77260e13bd0dbe1928ddeba8386e。
    建議套用修補程式來解決此問題。（CVE-2026-92413）

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，高特權攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。雖然弱點存在於 Oracle VM VirtualBox 中，但攻擊可能對其他產品造成重大影響 (範圍變更)。若攻擊成功，攻擊者未經授權即可造成 Oracle VM VirtualBox 懸置或經常重複性當機 (完全 DOS)。
    (CVE-2026-87283)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，低權限攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。若成功攻擊此弱點，則可接管 Oracle VM VirtualBox。注意：
    此弱點僅適用於 Windows 主機。（CVE-2026-87269）

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，低權限攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。若成功攻擊此弱點，未經授權即可造成 Oracle VM VirtualBox 懸置或經常重複性當機 (完全 DOS)，以及未經授權即可更新、插入或刪除部分可存取的 Oracle VM VirtualBox 資料。(CVE-2026-87279)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，低權限攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。若成功攻擊此弱點，則可接管 Oracle VM VirtualBox。注意：
    此弱點僅適用於 Windows 主機。（CVE-2026-87270）

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。難以利用的弱點允許透過 RDP 存取網路的低權限攻擊者入侵 Oracle VM VirtualBox。若成功攻擊此弱點，可在未經授權的情況下導致 Oracle VM VirtualBox 懸置或經常重複性當機 (完全 DOS)。(CVE-2026-87267)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。低權限攻擊者可利用難以利用的弱點，登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。成功的攻擊需要攻擊者以外的人員進行人工互動，而當弱點位於 Oracle VM VirtualBox 中時，攻擊可能會嚴重影響其他產品 （範圍變更）。若成功攻擊此弱點，則可接管 Oracle VM VirtualBox。
    (CVE-2026-87276)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，高特權攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。雖然弱點存在於 Oracle VM VirtualBox 中，但攻擊可能對其他產品造成重大影響 (範圍變更)。若攻擊成功，攻擊者未經授權即可造成 Oracle VM VirtualBox 懸置或經常重複性當機 (完全 DOS)。
    (CVE-2026-87285)

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

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

  - Oracle Java SE 的 GraalVM 產品Oracle Oracle GraalVM for JDK 中的弱點 （元件：
    編譯器）。受影響的支援版本是適用於 JDK 17 的 Oracle GraalVM： 23.0.13.1;適用於 JDK 21 的 Oracle GraalVM： 23.1.12.1;Oracle GraalVM： 25.0.4.1. 難以惡意利用的弱點允許透過 HTTP 存取網路的未經驗證的攻擊者入侵 Oracle GraalVM for JDK、Oracle GraalVM。成功攻擊此弱點可導致接管 Oracle GraalVM for JDK、Oracle GraalVM。
    (CVE-2026-83408)

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

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

  - Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition、Oracle Java SE 的 Oracle GraalVM 產品 （元件：編譯器） 中存在弱點。受影響的支援版本是適用於 JDK 17 的 Oracle GraalVM：
    23.0.13.1;適用於 JDK 21 的 Oracle GraalVM： 23.1.12.1;Oracle GraalVM 企業版： 21.3.19.1;Oracle GraalVM： 25.0.4.1. 難以惡意利用弱點允許透過 HTTP 存取網路的未經驗證的攻擊者入侵 Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition、Oracle GraalVM。
    成功攻擊此弱點可導致未經授權存取重要資料或完全存取所有 Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition、Oracle GraalVM 可存取的資料，以及未經授權更新、插入或刪除對某些 Oracle GraalVM for JDK、Oracle GraalVM Enterprise Edition、Oracle GraalVM 可存取資料的存取權，以及未經授權導致 Oracle GraalVM for JDK 部分拒絕服務 （部分 DOS） 的能力。 Oracle GraalVM Enterprise Edition、Oracle GraalVM。
    (CVE-2026-83368)

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

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

  - Apache ZooKeeper 仲裁 TLS 無法在 FIPS 模式部署中強制執行對等主機名稱驗證。當啟用 sslQuorum=true、zookeeper.fips-mode=true、ssl.quorum.hostnameVerification=true 及 ssl.quorum.clientHostnameVerification=true 時，Java SSLSocket 仲裁路徑會接受 CA 信任的對等憑證，其 SAN 與連線的主機不相符。因此，惡意或錯誤核發的對等憑證可以加入仲裁流量、參與領導者選舉，以及進入複製流程。建議使用者升級至 3.8.7 或 3.9.6 版，即可修正此問題。(CVE-2026-59969)

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

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

  - SingularityCE 和 SingularityPRO 是開源容器平台。在 SingularityCE 4.4.2 和 SingularityPRO 4.3.9 之前 4.1.14，在 singularity.conf 限制容器路徑指令中不正確的路徑字串比對允許在 setuid 模式下允許 /data/safe 時，執行同級目錄 （例如 /data/safe-but-unsafe） 中的容器。這允許使用者從管理員設定的路徑允許清單之外執行容器。不使用限制儲存器路徑的安裝不受影響。此問題已在 SingularityCE 4.4.2 和 SingularityPRO 4.3.9 和 4.1.14中修正。（CVE-2026-47215）

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，未經驗證的攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。成功的攻擊需要攻擊者以外的人員進行人工互動，而當弱點位於 Oracle VM VirtualBox 中時，攻擊可能會嚴重影響其他產品 （範圍變更）。若成功攻擊此弱點，則可接管 Oracle VM VirtualBox。
    (CVE-2026-87273)

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，高特權攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。雖然弱點存在於 Oracle VM VirtualBox 中，但攻擊可能對其他產品造成重大影響 (範圍變更)。若攻擊成功，攻擊者未經授權即可造成 Oracle VM VirtualBox 局部拒絕服務 (局部 DOS)。(CVE-2026-87284)

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

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

  - RabbitMQ Java 用戶端程式庫可讓 Java 及 JVM 型應用程式連線至 RabbitMQ 節點並與之互動。在之前 5.34.0，AMQConnection.start（） 會在 Connection.Tune 交涉之後套用 Math.min（maxInboundMessageBodySize， frameMax），即使 AMQP 將 frameMax 值零定義為無限制且 ConnectionFactory.DEFAULT_FRAME_MAX 為零。當用戶端預設值和伺服器協商值均為零時，結果會傳遞至 Utils.framePayloadLimit（int），後者會將零解譯為 Integer.MAX_VALUE，並停用已設定的 maxInboundMessageBodySize 上限。惡意 AMQP 伺服器或能夠修改 Connection.Tune 並將框架插入連線的中間人攻擊者，然後可以傳送任何框架類型的過大框架，導致 Frame.readFrom（） 在內容層級驗證之前配置一個大的位元組陣列，並可能因記憶體耗盡而終止用戶端進程。5.34.0 版已修正此問題。(CVE-2026-75516)

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

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

  - 由於缺少 ACL 檢查，透過 Apache ZooKeeper 中的 SetWatches 重新連接重播洩露資訊。攻擊者可以在不存在的路徑上註冊存在監視，然後在使用受限制的 ACL 建立路徑後重新連線，以發現受 ACL 限制的路徑。問題是由 （ZOOKEEPER-4799） 的 CVE-2024-23944 修正不完整所造成。此修正將 ACL 檢查新增至 WatchManager.triggerWatch（）。不過，DataTree.setWatches（） SetWatches/SetWatches2 重新連接重播處理常式仍會呼叫具有 NULL ACL 的 watcher.process（event），完全繞過檢查。請務必注意，此弱點只會暴露路徑，而不會暴露 znode 的資料，但由於 znode 路徑可能包含敏感資訊，例如使用者名稱或登入 ID，因此這可能屬於嚴重問題。建議使用者升級至 3.9.6 或 3.8.7 版，即可修正此問題。(CVE-2026-59739)

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

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

  - 在 GPAC 26.07.0中發現弱點。這會影響元件 WebSocket 處理常式的 src/utils/rmt_ws.c 檔案的函式rmt_client_handle_ws_frame。執行引數 payload_size 的操作可能會導致堆積型緩衝區溢位。攻擊者可從遠端發動攻擊。該漏洞已被公開披露，可能會被利用。升級至 abi-16.26 版可緩解此問題。此修補程式稱為 37bccbb30cf53a0e1a084cea9a1ce422b3ddfe12。建議升級受影響的元件。（CVE-2026-92399）

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

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

  - 未經身份驗證的攻擊者可以通過發送包含新行字符 （\n） 的特製 add_auth （ensemble， ...） 請求，將任意虛假日誌行插入 ZooKeeper 的操作日誌Apache。當整體名稱不相符時，EnsembleAuthenticationProvider.handleAuthentication（） 會透過 LOG.warn（） 記錄原始的、未清理的名稱。由於 SLF4J 的 {} 佔位符保留了嵌入的換行符，因此攻擊者可以偽造具有任意時間戳記、日誌級別、類別名稱和訊息的完整日誌條目，這些條目在視覺上與真正的 ZooKeeper 日誌輸出無法區分。此問題會影響 Apache ZooKeeper： from 3.9.0 through 3.9.5， from 3.8.0 through 3.8.6. 建議使用者升級至 3.8.7 或 3.9.6 版，即可修正此問題。(CVE-2026-84501)

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

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

  - HP 已識別並修復 HPLIP 中多個外部報告的漏洞。這些發現會影響多個軟體元件，這些元件在某些情況下可能會實現遠端程式碼執行、權限提升、拒絕服務、資訊洩露或未經授權的文件修改。（CVE-2026-91101）

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

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

  - Oracle Virtualization 的 Oracle VM VirtualBox 產品中的弱點 (元件：Core)。受影響的支援版本是 7.2.16。此弱點較易攻擊成功，低權限攻擊者可藉此登入 Oracle VM VirtualBox 執行所在的基礎結構，進而入侵 Oracle VM VirtualBox。若成功攻擊此弱點，則可接管 Oracle VM VirtualBox。注意：
    此弱點僅適用於 Windows 主機。（CVE-2026-87268）

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

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

  - 在 libxml2 中發現一個瑕疵。提供特製 XML 型錄的本機使用者或攻擊者可在 XML 型錄剖析期間觸發 NULL 指標解除參照。當「nextCatalog」元素缺少其強制性的「catalog」屬性時，就會發生這種情況，從而導致應用程式當機並導致拒絕服務 （DoS）。（CVE-2026-76781）

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

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

  - 處理「deleteContainer」操作碼 （0x14/20） 而不驗證呼叫端的 ACL 許可權，因此允許任何經過驗證的用戶端刪除資料樹狀結構中的特定 znode，而不論 znode 或其母項的 ACL 限制為何。此操作碼被視為僅限內部操作碼，官方用戶端沒有它的 API，但可以在 ZooKeeper 用戶端連接埠 （預設為 2181） 上開啟純 TCP 工作階段的用戶端 （預設為 2181） - 具有無身份驗證和無 ACL 權限 - 可以透過發出原始通訊協定 OpCode deleteContainer （20） 來刪除任何空的持續性 znode （包括一般持續性節點、容器節點和 TTL 節點）。deleteContainer 要求路徑會完全略過一般刪除 （OpCode 2） 路徑所強制執行的工作階段檢查和 DELETE ACL 檢查。這是授權繞過/ACL 強制執行錯誤。此問題會影響 Apache ZooKeeper： from 3.9.0 through 3.9.5， from 3.8.0 through 3.8.6. 建議使用者升級至 3.9.6 或 3.8.7 版，即可修正此問題。(CVE-2026-79993)

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

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

  - Oracle Java SE 的 GraalVM 產品Oracle Oracle GraalVM for JDK 中的弱點 （元件：
    編譯器）。受影響的支援版本是適用於 JDK 17 的 Oracle GraalVM： 23.0.13.1;適用於 JDK 21 的 Oracle GraalVM： 23.1.12.1;Oracle GraalVM： 25.0.4.1. 難以惡意利用的弱點允許透過 HTTP 存取網路的未經驗證的攻擊者入侵 Oracle GraalVM for JDK、Oracle GraalVM。成功攻擊此弱點可導致接管 Oracle GraalVM for JDK、Oracle GraalVM。
    (CVE-2026-83357)

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

ID	名稱	嚴重性
347331	Linux Distros 未修補弱點：CVE-2026-90215	medium
347330	Linux Distros 未修補弱點：CVE-2026-93089	high
347329	Linux Distros 未修補弱點：CVE-2026-92522	high
347328	Linux Distros 未修補弱點：CVE-2026-90237	high
347327	Linux Distros 未修補弱點：CVE-2026-90181	medium
347326	Linux Distros 未修補弱點：CVE-2026-90129	medium
347325	Linux Distros 未修補弱點：CVE-2026-90304	medium
347324	Linux Distros 未修補弱點：CVE-2026-92484	medium
347323	Linux Distros 未修補弱點：CVE-2026-90271	medium
347322	Linux Distros 未修補弱點：CVE-2026-90053	medium
347321	Linux Distros 未修補弱點：CVE-2026-90417	medium
347320	Linux Distros 未修補弱點：CVE-2026-90076	medium
347319	Linux Distros 未修補弱點：CVE-2026-90172	high
347318	Linux Distros 未修補弱點：CVE-2026-92512	high
347317	Linux Distros 未修補弱點：CVE-2026-90227	high
347316	Linux Distros 未修補弱點：CVE-2026-90075	medium
347315	Linux Distros 未修補弱點：CVE-2026-93064	medium
347314	Linux Distros 未修補弱點：CVE-2026-90230	critical
347313	Linux Distros 未修補弱點：CVE-2026-93104	medium
347312	Linux Distros 未修補弱點：CVE-2026-90357	high
347311	Linux Distros 未修補弱點：CVE-2026-90187	medium
347310	Linux Distros 未修補弱點：CVE-2026-93164	medium
347309	Linux Distros 未修補弱點：CVE-2026-90365	medium
347308	Linux Distros 未修補弱點：CVE-2026-90284	medium
347307	Linux Distros 未修補弱點：CVE-2026-90173	critical
347045	Linux Distros 未修補弱點：CVE-2026-8674	medium
346977	Linux Distros 未修補弱點：CVE-2026-87278	medium
346975	Linux Distros 未修補弱點：CVE-2026-92413	medium
346974	Linux Distros 未修補弱點：CVE-2026-87283	medium
346973	Linux Distros 未修補弱點：CVE-2026-87269	high
346972	Linux Distros 未修補弱點：CVE-2026-87279	medium
346971	Linux Distros 未修補弱點：CVE-2026-87270	high
346970	Linux Distros 未修補弱點：CVE-2026-87267	medium
346969	Linux Distros 未修補弱點：CVE-2026-87276	high
346968	Linux Distros 未修補弱點：CVE-2026-87285	medium
346967	Linux Distros 未修補弱點：CVE-2026-83408	high
346966	Linux Distros 未修補弱點：CVE-2026-83368	high
346965	Linux Distros 未修補弱點：CVE-2026-59969	high
346964	Linux Distros 未修補弱點：CVE-2026-47215	medium
346963	Linux Distros 未修補弱點：CVE-2026-87273	high
346962	Linux Distros 未修補弱點：CVE-2026-87284	low
346961	Linux Distros 未修補弱點：CVE-2026-75516	high
346960	Linux Distros 未修補弱點：CVE-2026-59739	high
346959	Linux Distros 未修補弱點：CVE-2026-92399	medium
346958	Linux Distros 未修補弱點：CVE-2026-84501	medium
346957	Linux Distros 未修補弱點：CVE-2026-91101	medium
346956	Linux Distros 未修補弱點：CVE-2026-87268	high
346955	Linux Distros 未修補弱點：CVE-2026-76781	medium
346954	Linux Distros 未修補弱點：CVE-2026-79993	high
346952	Linux Distros 未修補弱點：CVE-2026-83357	high

偵測

Nessus 的 Misc. 系列

medium

high

high

high

medium

medium

medium

medium

medium

medium

medium

medium

high

high

high

medium

medium

critical

medium

high

medium

medium

medium

medium

critical

medium

medium

medium

medium

high

medium

high

medium

high

medium

high

high

high

medium

high

low

high

high

medium

medium

medium

high

medium

high

high