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

  - 在 6d780b3378829318ba5c2d29547e0012d5b29642 之前的 plexus-utils 中，org.codehaus.plexus.util.Expand 的 extractFile 方法中存在一個目錄遊走弱點。這個弱點允許攻擊者執行任意程式碼 (CVE-2025-67030)

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

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

  - 已解決 Linux 核心中的下列弱點：ice: fix crash in ethtool offline loopback test Since the conversion of ice to page pool, the ethtool loopback test crashes: BUG: kernel NULL pointer dereference, address: 000000000000000c #PF: supervisor write access in kernel mode #PF:
    error_code(0x0002) - not-present page PGD 1100f1067 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 23 UID: 0 PID: 5904 Comm: ethtool Kdump: loaded Not tainted 6.19.0-0.rc7.260128g1f97d9dcf5364.49.eln154.x86_64 #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:ice_alloc_rx_bufs+0x1cd/0x310 [ice] Code: 83 6c 24 30 01 66 41 89 47 08 0f 84 c0 00 00 00 41 0f b7 dc 48 8b 44 24 18 48 c1 e3 04 41 bb 00 10 00 00 48 8d 2c 18 8b 04 24 <89> 45 0c 41 8b 4d 00 49 d3 e3 44 3b 5c 24 24 0f 83 ac fe ff ff 44 RSP: 0018:ff7894738aa1f768 EFLAGS:
    00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI:
    0000000000000700 RDI: 0000000000000000 RBP: 0000000000000000 R08: ff16dcae79880200 R09: 0000000000000019 R10: 0000000000000001 R11: 0000000000001000 R12: 0000000000000000 R13: 0000000000000000 R14:
    0000000000000000 R15: ff16dcae6c670000 FS: 00007fcf428850c0(0000) GS:ff16dcb149710000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3:
    0000000121227005 CR4: 0000000000773ef0 PKRU: 55555554 Call Trace: <TASK> ice_vsi_cfg_rxq+0xca/0x460 [ice] ice_vsi_cfg_rxqs+0x54/0x70 [ice] ice_loopback_test+0xa9/0x520 [ice] ice_self_test+0x1b9/0x280 [ice] ethtool_self_test+0xe5/0x200 __dev_ethtool+0x1106/0x1a90 dev_ethtool+0xbe/0x1a0 dev_ioctl+0x258/0x4c0 sock_do_ioctl+0xe3/0x130 __x64_sys_ioctl+0xb9/0x100 do_syscall_64+0x7c/0x700 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] It crashes because we have not initialized libeth for the rx ring. Fix it by treating ICE_VSI_LB VSIs slightly more like normal PF VSIs and letting them have a q_vector. It's just a dummy, because the loopback test does not use interrupts, but it contains a napi struct that can be passed to libeth_rx_fq_create() called from ice_vsi_cfg_rxq() -> ice_rxq_pp_create().
    (CVE-2026-23353)

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

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

  - 已解決 Linux 核心中的下列弱點：libie: don't unroll if fwlog isn't supported The libie_fwlog_deinit() function can be called during driver unload even when firmware logging was never properly initialized. This led to call trace: [ 148.576156] Oops: Oops: 0000 [#1] SMP NOPTI [148.576167] CPU: 80 UID: 0 PID: 12843 Comm: rmmod Kdump: loaded Not tainted 6.17.0-rc7next-queue-3oct-01915-g06d79d51cf51 #1 PREEMPT(full) [ 148.576177] Hardware name: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10 Plus, BIOS A42 07/18/2020 [ 148.576182] RIP: 0010:__dev_printk+0x16/0x70 [148.576196] Code: 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 55 41 54 49 89 d4 55 48 89 fd 53 48 85 f6 74 3c <4c> 8b 6e 50 48 89 f3 4d 85 ed 75 03 4c 8b 2e 48 89 df e8 f3 27 98 [ 148.576204] RSP: 0018:ffffd2fd7ea17a48 EFLAGS: 00010202 [ 148.576211] RAX: ffffd2fd7ea17aa0 RBX:
    ffff8eb288ae2000 RCX: 0000000000000000 [ 148.576217] RDX: ffffd2fd7ea17a70 RSI: 00000000000000c8 RDI:
    ffffffffb68d3d88 [ 148.576222] RBP: ffffffffb68d3d88 R08: 0000000000000000 R09: 0000000000000000 [148.576227] R10: 00000000000000c8 R11: ffff8eb2b1a49400 R12: ffffd2fd7ea17a70 [ 148.576231] R13:
    ffff8eb3141fb000 R14: ffffffffc1215b48 R15: ffffffffc1215bd8 [ 148.576236] FS: 00007f5666ba6740(0000) GS:ffff8eb2472b9000(0000) knlGS:0000000000000000 [ 148.576242] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 148.576247] CR2: 0000000000000118 CR3: 000000011ad17000 CR4: 0000000000350ef0 [148.576252] Call Trace: [ 148.576258] <TASK> [ 148.576269] _dev_warn+0x7c/0x96 [ 148.576290] libie_fwlog_deinit+0x112/0x117 [libie_fwlog] [ 148.576303] ixgbe_remove+0x63/0x290 [ixgbe] [ 148.576342] pci_device_remove+0x42/0xb0 [ 148.576354] device_release_driver_internal+0x19c/0x200 [ 148.576365] driver_detach+0x48/0x90 [ 148.576372] bus_remove_driver+0x6d/0xf0 [ 148.576383] pci_unregister_driver+0x2e/0xb0 [ 148.576393] ixgbe_exit_module+0x1c/0xd50 [ixgbe] [ 148.576430]
    __do_sys_delete_module.isra.0+0x1bc/0x2e0 [ 148.576446] do_syscall_64+0x7f/0x980 It can be reproduced by trying to unload ixgbe driver in recovery mode. Fix that by checking if fwlog is supported before doing unroll. (CVE-2026-23329)

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

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

  - V8 的字串雜湊機制中有一個缺陷造成類似整數的字串被雜湊成其數值使得雜湊衝突輕鬆可預測。透過特製在 V8 的內部字串表格中造成許多此類衝突的要求攻擊者可大幅降低 Node.js 處理程序的效能。最常見的觸發因素是在攻擊者控制的輸入上呼叫「JSON.parse()」的任何端點因為 JSON 剖析會自動將短字串內化到受影響的雜湊表中。此弱點會影響
    **20.x、 22.x、 24.x和 25.x**。 (CVE-2026-21717)

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

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

  - xsk修正片段節點刪除以防止緩衝區洩漏在提交 b692bf9a7543 (xsk擺脫 xdp_buff_xsk::xskb_list_node)後list_node 欄位會同時用於 xskb 集區清單和緩衝區可用清單這會造成上述的緩衝區洩漏。 xp_free() 會使用 list_empty(&xskb->list_node) 來檢查緩衝區是否已在可用清單上。當使用 list_del() 從 xskb 集區清單中移除節點時它不會重新初始化節點指標。這表示即使在移除節點之後list_empty() 仍會傳回 false進而造成 xp_free() 不正確略過將緩衝區新增至可用清單的步驟。請在所有片段處理路徑中使用 list_del_init() 而非 list_del() 來修正此問題此可確保移除後會重新初始化清單節點進而允許 list_empty() 正確運作。 (CVE-2026-23326)

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

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

  - wifi：mt76：修正可能的 OOB 存取問題mt76_connac2_mac_write_txwi_80211（） 在存取 mt76_connac2_mac_write_txwi_80211 管理欄位前檢查幀長度，以避免可能的 OOB 存取。
    [修正檢查以涵蓋 mgmt->u.action.u.addba_req.capab，修正標籤正確]（CVE-2026-23315）

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

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

  - 版 2.52.0 之前的 Apache Artemis 受到一個驗證繞過瑕疵影響其允許讀取透過代理人交換的所有訊息以及插入新訊息 ( CVE-2026-27446 https://www.cve.org/CVERecord )。由於 KNIME Business Hub 使用的是 Apache Artemis因此也會受到 問題的影響。但是由於 Apache Artemis 不會暴露給外部因此它至少需要一般使用者權限以及在 executor 中執行工作流程的能力。這類使用者可以在不驗證原始 Apache Artemis 執行個體的情況下安裝和註冊同盟鏡像進而讀取所有內部訊息並插入新訊息。此問題會影響 KNIME Business Hub 的所有版本。 1.18.0、 1.17.4和 1.16.3版隨附修正的 Apache Artemis 版本。由於尚無已知的因應措施因此建議您盡快更新至修正的版本。 (CVE-2026-4649)

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

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

  - scsi： pm8001：修正 pm8001_queue_command（） 中 use-use-free，提交 e29c47fe8946（scsi： pm8001： Simplify pm8001_task_exec（）））重構 pm8001_queue_command（），但當 phy 關閉/裝置消失狀態時，將函式改為回傳 -ENODEV 時，可能會引發雙重自由情境。在此路徑中，pm8001_queue_command（） 更新任務狀態並呼叫 task_done，告知上層任務已處理。然而，這同時也釋放了底層的 SAS 任務。接著會回傳一個 -ENODEV 給呼叫者。當 libsas sas_ata_qc_issue（） 收到這個錯誤值時，它會假設該任務沒有被 LLDD 處理或排隊，於是會重新清理並釋放該任務，導致雙重空缺。由於 pm8001_queue_command（） 處理 SAS 任務，因此應回傳 0 給呼叫者，表示該任務已被處理。（CVE-2026-23306）

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

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

  - perf/core修正 ctx_sched_in() 中的無效等待內容。Lockdep 發現釘選事件失敗時事件排程中有一個錯誤喚醒環形緩衝區中的執行緒時如下所示。它似乎不應在 perf-context 鎖定下抓取等待佇列鎖定。讓我們以 irq_work 來執行。 [ 39.913691] ============================= [ 39.914157] [錯誤等待內容無效] [ 39.914623] 6.15. 0-next-20250530-next-2025053 #1 未受污染 [ 39.915271] ----------------------------------------- [ 39.915731] repro/837 嘗試鎖定 [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}位於
    __wake_up+0x26/0x60 [ 39.917182] 其他可協助我們除錯的其他資訊 [ 39.917761] context-{5:5} [39.918079] repro/837 保留的 4 個鎖定 [ 39.918530] #0ffffffff8725cd00 (rcu_read_lock ){....}-{1:3}, at
    __perf_event_task_sched_in+0xd1/0xbc0 [ 39.919612] #1: ffff88806ca3c6f8 (&cpuctx_lock){....}-{2:2}、@@
    __perf_event_task_sched_in+0x1a7/0xbc0 [ 39.920748] #2: ffff88800d91fc18 (&ctx->lock){....}-{2:2}
    __perf_event_task_sched_in+0x1f9/0xbc0 [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}、@@
    perf_event_wakeup+0x6c/0x470 (CVE-2026-23311)

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

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

  - RDMA/irdma修正 irdma_create_user_ah() struct irdma_create_ah_resp { // 8 位元組無填補 __u32 ah_id 中的核心堆疊洩漏// 位移 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // 位移 4
    - NEVER SET <- LEAK } rsvd[4]堆疊記憶體的 4 位元組無條件洩漏。在 ib_respond_udata() 之前只指派 ah_id。結構的保留成員並未歸零。 (CVE-2026-23335)

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

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

  - nfc： nci：在裝置關閉時完成擱置的資料交換 在 nci_close_device（） 中，在關閉前完成任何擱置的資料交換。資料交換回呼 （例如 rawsock_data_exchange_complete） 會保留通訊端參照。NIPA 偶爾會遇到此洩漏： 未引用的物件0xff1100000f435000（大小 2048）：comm nci_dev、pid 3954、jiffies 4295441245 hex 轉儲（前 32 個位元組）：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............回溯 （CRC EC2B3C5）：__kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0
    __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 （CVE-2026-23330）

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

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

  - bpf修正 devmap 中的堆疊超出邊界寫入。get_upper_ifindexes() 反覆使用所有上層裝置並將其索引寫入陣列而不檢查邊界。此外呼叫者假設上層裝置的最大數目為 MAX_NEST_DEV並在堆疊上配置 Likewise_devices[1+MAX_NEST_DEV]但該假設不正確而且上層裝置的數目可能大於 MAX_NEST_DEV (例如許多 macvlans)導致一個堆疊超出邊界寫入。為 get_upper_ifindexes() 新增最大參數以避免發生此問題。當上層裝置過多時傳回 -EOVERFLOW 併中止重新導向。若要重現請在使用 BPF_F_BROADCAST 附加 XDP 程式的裝置上建立 MAX_NEST_DEV(8) 以外的 macvlan | BPF_F_EXCLUDE_INGRESS。然後傳送封包至裝置以觸發 XDP 重新導向路徑。 (CVE-2026-23359)

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

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

  - can：bcm：修正 bcm_op 執行階段更新的鎖定 提交 c2aba69d0c36 （can：bcm：為 bcm_op 執行階段更新新增鎖定） 為某些變數新增鎖定，當使用 bcm_tx_setup（） 中的新 TX_SETUP 命令更新傳送bcm_op時，可以在執行階段修改這些變數。通常，RX_SETUP僅處理和過濾傳入流量，但有一個例外：設定 RX_RTR_FRAME 標誌時，當收到特定的 RTR 幀時，會傳送預先定義的 CAN 幀。因此，rx bcm_op使用 bcm_can_tx（），它使用僅在 bcm_tx_setup（） 中初始化的bcm_tx_lock。在 bcm_rx_setup（） 中配置bcm_op時新增缺少的 spin_lock_init（），以正確處理 RTR 情況。（CVE-2026-23362）

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

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

  - 如果 BIND 解析器正在執行 DNSSEC 驗證並遇到惡意製作的區域則該解析器可能會過度消耗 CPU。僅授權伺服器通常不會受到影響但是在某些情況下授權伺服器可能會進行遞回查詢 (請參閱 https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries)。此問題會影響 BIND 9 版本 9.11.0 至 9.16.50、 9.18.0 至 9.18.46、 9.20.0 至 9.20.20、 9.21.0 至 9.21.19、9.11.3-S1 至 9.16.50-S1、9.18.11-S1 至 9.18。 46-S1以及 9.20.9-S1 至 9.20.20-S1。 (CVE-2026-1519)

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

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

  - PCI: dwc: ep在取消對應其 ATU 項目之前排清 MSI-X 寫入端點驅動程式會使用 dw_pcie_ep_raise_msix_irq() 來產生使用 writel() 的主機的 MSI-X 中斷進而產生 PCI 已發布寫入交易。已發布的寫入未完成因此 writel() 可能會在 PCI 寫入完成前傳回。 dw_pcie_ep_raise_msix_irq() 也會取消對應用於 PCI 寫入的輸出 ATU 項目因此會發生寫入與取消對應的爭用情形。如果 PCI 寫入遺失與 ATU 取消對應的爭用作業可能會損毀主機記憶體或造成 IOMMU 錯誤例如當對 nvmet-pci-epfarm-smmu-v3 fc900000.iommu 執行具有較大佇列深度的 fio 時發生這些錯誤0x0000010000000010 arm-smmu-v3 fc900000.iommu
    0x0000020000000000 arm-smmu-v3 fc900000.iommu 0x000000090000f040 arm-smmu-v3 fc900000.iommu
    0x000000000000000 arm-smmu-v3 fc900000.iommu事件F_TRANSLATION 用戶端0000:01:00.0 sid0x100 ssid
    0x0 iova 0x90000f040 ipa 0x0 arm-smmu-v3 fc900000.iommuunpriv 資料寫入 s1 輸入位址造成錯誤 stag: 0x0 對相同位址執行 readl() 以排清寫入以確保寫入已在 之前到達目的地ATU 項目未對應。已解決認可 8719c64e76bf (PCI: dwc: ep快取 MSI 傳出 iATU 對應) 中的 dw_pcie_ep_raise_msi_irq() 的相同問題但透過將傳出 iATU 專用於 MSI 來解決此問題。我們無法針對 MSI-X 執行相同動作因為每個向量都可以有不同的 msg_addr而且在向量遭到遮罩時msg_addr 可能會變更。
    [bhelgaas認可記錄] (CVE-2026-23361)

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

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

  - nfc: rawsock在中斷通訊端之前取消 tx_work。在 rawsock_release() 中取消任何擱置的 tx_work 並清除寫入佇列然後再將通訊端孤立。 rawsock_tx_work 在系統 workqueue 上執行並呼叫 nfc_data_exchange其可解除參照 NCI 裝置。若未進行同步處理處理程序遭到終止 (例如 SIGKILL) 時tx_work 可與通訊端爭用及裝置終止進而導致釋放後使用或參照洩漏。先設定 SEND_SHUTDOWN如果 tx_work 已經在執行中它會看見旗標並略過傳輸然後使用 cancel_work_sync 等待任何進行中的執行結束最後清除所有剩餘的已排入佇列的 skbs。 (CVE-2026-23372)

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

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

  - net註解 sk->sk_{data_ready,write_space} skmsg (可能還有其他層) 變更這些指標而其他 cpu 可能同時讀取這些指標時的資料爭用。針對 UDP、TCP 和 AF_UNIX 新增對應的 READ_ONCE()/WRITE_ONCE() 註解。 (CVE-2026-23302)

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

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

  - netipv4修正多路徑雜湊種子「struct sysctl_fib_multipath_hash_seed」中的對齊錯誤 ARM64 對齊錯誤包含兩個 u32 欄位 (user_seed 和 mp_seed)使其成為具有 4 位元組對齊要求的 8 位元組結構。在 `fib_multipath_hash_from_keys()` 中程式碼透過 `READ_ONCE()` 以原子方式評估整個結構 mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;雖然這會回復至 ARM64 核心允許的未對齊規則載入以無訊息模式在 GCC 上運作但在啟用 Clang 和 LTO 的情況下編譯時會造成嚴重的核心錯誤。認可 e35123d83ee3 (arm64: ltoCONFIG_LTO=y 時加強 READ_ONCE() 獲取) 加強「READ_ONCE()」以使用 Load-Acquire 指示 (「ldar」/「ldapr」) 防止編譯器在 Clang LTO 下重新排序錯誤。由於該巨集會評估完整的 8 位元組結構因此 Clang 會發出 64 位元「ldar」指令。 ARM64 架構嚴格要求「ldar」自然對齊因此在 4 位元組對齊的位址上執行它會觸發嚴格的對齊錯誤 (FSC = 0x21)。將 `READ_ONCE()` 直接移至 `u32` 成員 (會發出安全的 32 位元 `ldar Wn`) 修正讀取端。此外Eric Dumazet 指出「proc_fib_multipath_hash_set_seed()」中整個結構上的「WRITE_ONCE()」也有瑕疵。分析顯示Clang 將此 8 位元組寫入分割為兩個獨立的 32 位元「str」指示。雖然這可以避免對齊錯誤，但它會破壞原子性並暴露一個斷裂寫入弱點。透過明確地將寫入分割成兩個 32 位元 `WRITE_ONCE()` 作業來修正此問題。最後在「proc_fib_multipath_hash_seed()」中讀取「user_seed」時新增遺漏的「READ_ONCE()」以確保正確配對和並行安全。 (CVE-2026-23316)

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

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

  - 在某些情況下處理包含 TKEY 記錄且正確簽署的查詢時`named` 可能會損毀。只有當傳入的要求具有從「named」組態中宣告的金鑰取得的有效交易簽章 (TSIG) 時才能接觸到受影響的程式碼。此問題會影響 BIND 9 9.20.0 至 9.20.20版、 9.21.0 至 9.21.19版以及 9.20.9-S1 至 9.20.20-S1 版。BIND 9 9.18.0 至 9.18.46 版以及 9.18.11-S1 至 9.18.46-S1 版不受影響。 (CVE-2026-3119)

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

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

  - mptcp pm核心內一律將 signal+subflow endp 標記為已使用 Syzkaller 設法找到產生此警告的動作組合 msk->pm.local_addr_used == 0 警告net/mptcp/pm_kernel.c __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 的 1071 [內嵌]、 CPU#1syz.2.17/961 警告
    net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [內嵌] CPU#1syz.2.17/961 警告 net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net /mptcp/pm_kernel.c:1210、 CPU#1syz.2.17/961 模組連結於 CPU1 UID0 PID961 Commsyz.2.17 未受污染的 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full)硬體名稱QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 機器, 1996)BIOS 1.17.0-debian-1.17.0-1build1 2014 年 4 月 1 日 RIP
    0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [內嵌] RIP
    0010mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [內嵌] RIP
    0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 程式碼89 c5 e8 46 30 6f fe e9 21 fd ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 0 9 9 db4 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP0018:ffffc90001663880 EFLAGS00010293 RAX
    ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10:
     R11ffffffff82de18ba  : 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink. c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [內嵌] netlink_unicast+0x3e9/0x4c0 網路/netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [內嵌] __sock_sendmsg+0xc9/0xf0 net/socket.c:742____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 __sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c: 2678 [內嵌]
    __do_sys_sendmsg net/socket.c:2683 [內嵌] __se_sys_sendmsg net/socket.c:2681 [內嵌]
    __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0xRIP7f
    0033:0x7f66346f826d 程式碼ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 0c <48> ] 2 4 0 4c 8b 0c 5c 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP002b:00007ffc83d8bdc8 EFLAGS00000246 ORIG_RAX000000000000002e RAXffffffffffffffda RBX
    00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000246 R1200007f6634985fa8 R1300007f6634985fac R140000000000000000 R150000000000001770 </TASK> 造成 的動作似乎為- 將 MPTCP 子流程限制設為 0' 和 'TCPsubflow' 訊號端點「旗標 - 從不同位址建立新的 MPTCP 連線將傳送連結至 MPTCP 端點的 ADD_ADDR ('signal' 旗標)但不會初始化任何子流程 ('subflow' 旗標) - 移除 MPTCP 端點 ---truncated--- (CVE-2026-23321)

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

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

  - cpufreq: intel_pstate修正 turbo 停用期間的當機系統以核心命令行引數 nosmt 或 maxcpus 開機以限制 CPU 數量停用 turbo 時 透過 echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo 結果在損毀中PFerror_code(0x0000) - 不存在頁面 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI ... RIP
    0010:store_no_turbo+0x100/0x1f0 ... 會發生此情況是因為即使 CPU 未在線 for_each_possible_cpu() 仍會傳回 CPU。對於這些 CPU all_cpu_data[] 將為 NULL。自從提交 973207ae3d7c (cpufreq
    intel_pstate重新排列最大頻率更新處理程式碼) all_cpu_data[] 會解除參照 (即使是離線 CPU)進而造成 NULL 指標解除參照。若要修正此問題請將 CPU 編號傳送至 intel_pstate_update_max_freq()並針對存在有效 cpufreq 原則的 CPU 使用 all_cpu_data[] 。 (CVE-2026-23332)

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

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

  - sched/deadline修正 PI 解除增強期間缺少的 ENQUEUE_REPLENISH 在大型機器上的 RT 核心上執行stress-ng --schedpolicy 0 時可能會導致下列警告 (已編輯)。 schedDL 取消提升工作 PID 22725REPLENISH 旗標遺失0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228
    __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ... 問題在於透過 sched_setscheduler() 將 SCHED_DEADLINE 工作 (鎖定持有者) 變更為優先順序較低的類別時如果過去未繼承潛在 DEADLINE 提供者的參數 (較短的期限比當時的授權者)。這可能會導致頻寬計量損毀因為 enqueue_task_dl() 不會將鎖定持有者識別為已提升。在以下情況下會發生此狀況 1. DEADLINE 工作 (提供者) 在由另一個 DEADLINE 工作 (持有者) 持有的 PI mutex 上封鎖但該持有者並未繼承參數 (例如其已有較短的期限) 2. sched_setscheduler()將持有者從 DEADLINE 變更為較低類別同時仍持有 mutex 3. 持有者現在應繼承提供者的 DEADLINE 參數並使用 ENQUEUE_REPLENISH 加入佇列但是這不會發生 透過引入 __setscheduler_dl_pi() 來修正問題其會偵測時間DEADLINE (適當或提升) 工作被設定為較低優先順序的類別。在此情況下函式會使工作繼承提供者 (pi_se) 的 DEADLINE 參數並設定 ENQUEUE_REPLENISH 旗標以確保下次加入佇列作業期間的頻寬計量正確。 (CVE-2026-23371)

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

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

  - NET：IPv6：當 IPv4 路由引用回環 IPv6 nexthop 時，修正恐慌。當 IPv6 下一跳物件與回環裝置建立獨立 IPv6 下一跳物件（例如 ip -6 nexthop add ID 100 dev lo）時，fib6_nh_init（） 會誤將其歸類為拒絕路由。這是因為下一跳物件沒有目的地前綴（fc_dst=：:)），導致fib6_is_reject（）與任何回環下一跳相符。拒絕路徑跳過 fib_nh_common_init（），nhc_pcpu_rth_output未分配。如果 IPv4 路由後來引用此下一跳，__mkroute_output（） 會取消參照 NULL nhc_pcpu_rth_output，並陷入恐慌。簡化 fib6_nh_init（） 中的檢查，只匹配明確的拒絕路由（RTF_REJECT），而非使用 fib6_is_reject（）。fib6_is_reject（） 中的迴回升變啟發式由 ip6_route_info_create_nh（） 分別處理。
    此變更後，三種情況的行為如下：1. 明確拒絕路由（ip -6 route add unreachable 2001：db8：：/64）：RTF_REJECT 設定，進入拒絕路徑，跳過 fib_nh_common_init（）。行為沒有改變。2. 隱含迴圈拒絕路由（ip -6 route add 2001：db8：：/32 dev lo）：RTF_REJECT 未設定，採用正常路徑，fib_nh_common_init（） 被呼叫。ip6_route_info_create_nh（） 仍然會讓它在之後被拒絕。nhc_pcpu_rth_output 是分配但未被使用，這無害。3. 獨立 nexthop 物件（ip -6 nexthop add id 100 dev lo）：RTF_REJECT 未設定，採用正常路徑，fib_nh_common_init（） 被呼叫。nhc_pcpu_rth_output 正確配置，解決了當 IPv4 路由引用此下一跳時的崩潰問題。（CVE-2026-23300）

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

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

  - scsi目標修正 __configfs_open_file() 中的遞回鎖定。在 flush_write_buffer 中取得 &p->frag_sem然後呼叫已載入的儲存函式此處為 target_core_item_dbroot_store()。
    根據呼叫追踪此函式稱為 filp_open()然後呼叫下列函式 (以相反順序)down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_iter target_core_item_dbroot_store() 會透過嘗試 來驗證新檔案路徑開啟提供給它的檔案路徑不過在此情況下錯誤報告會顯示 db_root: not a directory
    /sys/kernel/config/target/dbroot 指出系統已嘗試開啟相同的 configfs 檔案而其目前正在處理該檔案。因此它會嘗試取得其已持有在 flush_write_buffer() 中取得之旗號之相同檔案的 frag_sem 旗號進而導致以巢狀方式取得旗號且可能發生遞回鎖定。修正此方法為將 target_core_item_dbroot_store() 修改為使用 kern_path() 而非 filp_open()避免使用檔案系統特定函式 __configfs_open_file() 開啟檔案並進一步修改該函式使其與此修正相容。
    (CVE-2026-23292)

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

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

  - ALSAusb-audio使用 UAC3 標頭驗證的正確版本UAC3 AC 標頭描述符號的驗證器表格項目是以錯誤的通訊協定版本 UAC_VERSION_2 定義而其原本應為 UAC_VERSION_3。這會導致驗證器永遠不會比對實際的 UAC3 裝置 (通訊協定 == UAC_VERSION_3)進而造成其標頭描述符號完全繞過驗證。呈現截斷 UAC3 標頭的惡意 USB 裝置可惡意利用此弱點在驅動程式稍後存取未經驗證的描述元欄位時造成超出邊界讀取。此錯誤是在最近修正的 UAC3 功能單位子類型錯字所在的同一個認可中引入而且從 UAC2 區段建立 UAC3 區段時似乎也起因於同一個複制貼上錯誤。 (CVE-2026-23318)

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

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

  - 一個特別設計的網域，只要查詢該網域，就能在 BIND 解析器中造成記憶體洩漏。此問題影響 BIND 9 版本 9.20.0 至 9.20.20、 9.21.09.21.19、 及 9.20.9-S1 至 9.20.20-S1 版本。BIND 9 版本9.18.09.18.46至 9.18.11-S1 至 9.18.46-S1 不受影響。（CVE-2026-3104）

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

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

  - 處理以 SIG(0) 簽署的 DNS 查詢時`named` 伺服器中存在一個返回後使用弱點。使用特製的 DNS 要求攻擊者可以造成 ACL 不當 (mis) 比對 IP 位址。在預設允許 ACL (僅拒絕特定 IP 位址) 中這可能會導致未經授權的存取。預設拒絕 ACL 應具備容錯安全性。此問題會影響 BIND 9 9.20.0 至 9.20.20版、 9.21.0 至 9.21.19版以及 9.20.9-S1 至 9.20.20-S1 版。BIND 9 9.18.0 至 9.18.46 版以及 9.18.11-S1 至 9.18.46-S1 版不受影響。 (CVE-2026-3591)

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

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

  - pinctrl平衡修正載入時的警告追踪。在回呼函式「eqbr_irq_mask_ack()」中也會呼叫回呼函式「eqbr_irq_mask()」和「eqbr_irq_ack()」。這麼做是為了避免複製原始程式碼。問題在於函式「eqbr_irq_mask()」中也呼叫 gpiolib 函式「gpiochip_disable_irq()」。這會在載入時於每個 gpio 的記錄中產生下列警告追踪。 [ 6.088111] ------------[cut here ]------------ [ 6.092440] WARNING CPU: 3 PID: 1 at drivers/gpio/gpiolib .c:3810 gpiochip_disable_irq+0x39/0x50 [ 6.097847] 連結的模組[ 6.097847] CPU
    3 UID0 PID1 通訊swapper/0 污染GW 6.12.59+ #0 [ 6.097847] 污染[W]=WARN [ 6.097847] RIP
    0010:gpiochip_disable_irq+0x39/0x50 [ 6.097847] 程式碼39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 ff ff 77 80 66 09 fb c3 <0f> 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 [ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046 [ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX0000000000000008 [ 6.097847] RDXffff888001be9000 RSI
    ffff888001b2dd00 RDIffff888001be02a0 [ 6.097847] RBP ffffc9000000b860 R080000000000000000 R09
    0000000000000000 [ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514 [ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000 [ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS :0000000000000000 [ 6.097847] CS0010 DS0000 ES0000 CR0
    0000000080050033 [ 6.097847] CR20000000000000000 CR30000000003030000 CR400000000001026b0 [ 6.097847] 呼叫追踪 [ 6.097847] <TASK> [ 6.097847] eqbr_irq_mask+0x63/0x70 [ 6.097847] ? no_action+0x10/0x10 [6.097847] eqbr_irq_mask_ack+0x11/0x60 在其他驅動程式 (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) 中未在此處停用中斷。若要修正此問題請不要呼叫「eqbr_irq_mask()」和「eqbr_irq_ack()」函式。改為直接實作而不停用中斷。
    (CVE-2026-23308)

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

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

  - canusbf81604正確處理短中斷 urb 訊息如果收到長度不正確的中斷 urb請正確偵測該資料且不嘗試將資料視為有效。 (CVE-2026-23334)

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

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

  - nfcnci釋放 nci_transceive 早期錯誤路徑上的 skb nci_transceive() 取得呼叫者傳遞的 skb 的擁有權但 -EPROTO、-EINVAL 和 -EBUSY 錯誤路徑在未釋放的情況下傳回。由於後續變更修正的 NCI_DATA_EXCHANGE 清除問題導致 nci/nci_dev 自我測試偶爾會在 NIPA 中命中錯誤路徑且 kmemleak 會偵測到洩漏未參照物件 0xff11000015ce6a40 (大小 640)通訊 nci_dev、pid 3954、jiffies 4295441246 十六進位轉儲存 (前 32 個位元組) 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk..kkkakk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk 反向追踪 (crc 7c40_ccnode_alockmcache_c40_ccnode_alock_crc 7c40_ccnode_alock_crc 7c40_ccnode_alock_crc) +0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_06CVE-2026-23339) 1

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

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

  - x86/efi延遲釋放開機服務記憶體 efi_free_boot_services() 會使用 memblock_free_late() 釋放 EFI_BOOT_SERVICES_CODE 和 EFI_BOOT_SERVICES_DATA 佔用的記憶體。其有兩個問題memblock_free_late() 應用於以 memblock_alloc() 配置的記憶體而以 memblock_reserve() 保留的記憶體則應以 free_reserved_area() 釋放。更確切地說是在記憶體對應的延遲初始化完成之前呼叫 CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services()。Benjamin Herrenschmidt 報告這會造成只有 512MB 或 RAM 的 EC2 t3a.nano 執行個體發生 ~140MB RAM 洩漏。如果已釋放的記憶體所在的區域其記憶體對應仍未初始化則這些記憶體不會實際釋放因為 memblock_free_late() 會呼叫 memblock_free_pages()而後者會略過未初始化的頁面。此時使用 free_reserved_area() 也有問題因為 __free_page() 會存取已釋放頁面的 buddy而這可能再次出現在記憶體對應的未初始化部分。延遲整個 efi_free_boot_services() 可能會有問題因為除了釋放開機服務記憶體之外它還會在沒有任何同步的情況下更新 efi.memmap而且當有並行時這在開機後期是不可取的。更健全的方法是僅延遲釋放 EFI 開機服務記憶體。將 efi_free_boot_services() 分割為兩部分。首先 efi_unmap_boot_services() 會將應釋放的範圍收集到陣列中然後 efi_free_boot_services() 會在延遲的 init 完成後釋放這些範圍。 (CVE-2026-23352)

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

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

  - xdp當計算出的 tailroom 為負值時產生警告。許多乙太網路驅動程式報告 xdp Rx 佇列片段大小與 DMA 寫入大小相同。不過此欄位的唯一使用者 bpf_xdp_frags_increase_tail() 顯然預期的是一個 truesize。這種差異會導致在特定情況下發生不明的記憶體損毀問題例如在 ixgbevf 中最大的 DMA 寫入大小為 3 KB因此當執行 xskxceiver 的 XDP_ADJUST_TAIL_GROW_MULTI_BUFF、6K 封包時會完全使用 2 個緩衝區中的所有 DMA 可寫入空間。如果只有 rxq->frag_size 正確設定為 4K就沒有問題但是 3K 的值會產生負的 tailroom因為有非零的頁面位移。我們應該傳回 -EINVAL 並在這種情況下完成處理但由於 tailroom 被儲存為未簽署的 int因此據報其位於 UINT_MAX 附近導致即使要求的位移過大也會導致結尾增加多 (在上述測試中約為 2K)。這稍後會導致所有類型的不明呼叫追踪。 7340.337579[  ] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000 +160000] [ 7340.339230] 在 xskxceiver[42b5,400000+69000] 中 [ 7340.340300] 可能在 CPU 6 (核心 0 通訊端 6) 中 [ 7340.340302] 程式碼ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 85 ec fe [ 7340.340888] 可能在 CPU 3 (核心 0、通訊端 3)上 [ 7340.345088] 程式碼
    00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops一般保護錯誤可能針對非正式位址 0x6d255010bdffc0000 [#1] SMP NOPTI [7340.405972] CPU7 UID0 PID1439 通訊xskxceiver 未受污染 6.19.0-rc1+ #21 PREEMPT(lazy) [7340.408006] 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.17.0-5.fc42 04/01/ 2014 [7340.409716] RIP 0010:lookup_swap_cgroup_id+0x44/0x80 [ 7340.410455] 程式碼 83 f8 1c 73 39 48 ba ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP0018:ffffcc5c04f7f6d0 EFLAGS
    00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS0000 ES0000 CR00000000080050033 [ 7340.420286] CR200007f415bfffd58 CR3
    0000000103f03002 CR40000000000772ef0 [ 7340.421237] PKRU55555554 [ 7340.421623] 呼叫追踪 [7340.421987] <TASK> [ 7340.422309] ? softleaf_from_pte+0x77/0xa0 [ 7340.422855] swap_pte_batch+0xa7/0x290 [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zap_pte_range+0x281/0x580 [ 7340.424607] zap_pmd_range.isra.0+ 0xc9/0x240 [ 7340.425177] unmap_page_range+0x24d/0x420 [ 7340.425714] unmap_vmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] __mmput+0x41/0x150 [ 7340.427098] exit_mm+0xb1/0x110 [ 7340.427539] do_exit+0x1b2/0x460 [ 7340.427992] do_group_exit+0x2d/0xc0 [7340.428477] get_signal+0x79d/0x7e0 [ 7340.428957] arch_do_signal_or_restart+0x34/0x100 [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0 [ 7340.430159] do_syscall_64+08888 / ---truncated--- (CVE-2026-23343)

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

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

  - wifi: mac80211修正 mesh_rx_csa_frame() 中的 NULL 指標解除參照。在mesh_rx_csa_frame() 中elems->mesh_chansw_params_ie 在未進行事先 NULL 檢查的情況下於第 1638 和 1642 行解除參照
    ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value);上述的 mesh_matches_local() 檢查只會驗證 Mesh ID、Mesh Configuration 和 Supported Rates IE。它不會驗證 Mesh Channel Switch Parameters IE (元素 ID 118) 是否存在。當收到的 CSA 動作框架省略該 IE 時ieee802_11_parse_elems() 會將 elems->mesh_chansw_params_ie 保留為 NULL且無條件解除參照會造成核心 NULL 指標解除參照。已建立對等節點連結 (PLINK_ESTAB) 的遠端 Mesh 對等節點可藉由傳送特製的 SPECTRUM_MGMT/CHL_SWITCH 動作框架來觸發此弱點其中包含相符的 Mesh ID 和 Mesh Configuration IE但省略 Mesh Channel Switch Parameters IE。除了預設的開放網狀對等之外不需要任何驗證。透過 mac80211_hwsim在核心 6.17.0-5-generic 上確認損毀錯誤
    核心 NULL 指標解除參照、位址0000000000000000 OopsOops0000 [#1] SMP NOPTI RIP
    0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 進行修正。在 mesh_matches_local() 傳回後針對 mesh_chansw_params_ie 新增 NULL 檢查此問題與在整個 Mesh 程式碼中保護其他選用 IE 的方式一致。此錯誤自 v3.13 (2014-01-19 發布) 後即存在。
    (CVE-2026-23279)

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

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

  - netusbpegasus驗證 USB 端點pegasus 驅動程式應先驗證其正在探查的裝置在系結之前是否具有預期的 USB 端點數量和類型。如果惡意裝置沒有相同的 urb驅動程式稍後會在盲目存取這些端點時損毀。 (CVE-2026-23290)

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

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

  - smb用戶端修正因 smb2_unlink() 中的未初始化 var 所導致的 oops。如果 SMB2_open_init() 或 SMB2_close_init() 失敗 (例如重新連線)iovs 集 @rqst 將會保持未初始化因此會呼叫 SMB2_open_free()、SMB2_close_free() 或 smb2_set_related () 會發生 oops。透過在 @rqst 中設定 @close_iov 和 @open_iov 之前將其初始化即可修正。 (CVE-2026-23282)

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

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

  - arm64io: 擷取 ioremap_prot() 中的使用者記憶體類型泛型 ioremap() 實作之外的 ioremap_prot() 唯一呼叫端是 generic_access_phys()其會傳送從目標「pfn」的使用者對應確定的「pgprot_t」值' 遭到核心存取。在 arm64 上「pgprot_t」包含來自 pte 的所有非位址位元 (包括權限控制項)因此我們最終會從 ioremap_prot() 傳回新的使用者對應這在從具有 PAN 之系統上的核心存取時會發生錯誤|無法處理在虛擬位址 ffff80008ea89000 | 無法讀取的記憶體讀取的核心... |呼叫追踪|
    __memcpy_fromio+0x80/0xf8 | 版generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | 版access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178|
    __arm64_sys_read+0x4c/0x68 只擷取 ioremap_prot() 中使用者 'pgprot_t' 的記憶體類型並宣告我們收到了一個使用者對應以保護我們免於日後需要額外處理的任何變更。為避免錯誤地標記 ioremap() 的使用者請提供我們自己的 ioremap() 巨集其僅包裝 __ioremap_prot()。 (CVE-2026-23346)

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

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

  - bpf修正 bpf_trampoline_link_cgroup_shim 中的 UAF 問題。此錯誤的根本原因是當「bpf_link_put」將「shim_link->link.link」的 refcount 減少為零時系統會將資源視為已釋放但仍可透過「tr- 'cgroup_shim_find' 中的 >progs_hlist'。「bpf_shim_tramp_link_release」中「tr->progs_hlist」的實際清理已延遲。在此視窗中其他處理程序可透過「bpf_trampoline_link_cgroup_shim」造成釋放後使用。根據 Martin KaFai Lau 的建議我已建立一個簡單的修補程式。若要修正此問題： 在「bpf_trampoline_link_cgroup_shim」中新增不可部分完成的非零檢查。僅在 refcount 還不是零時才增加該計數。測試我已在「bpf_shim_tramp_link_release」中新增延遲以使錯誤更容易觸發以驗證此修正
    static void bpf_shim_tramp_link_release(struct bpf_link *link) { /* ... */ if (!shim_link->trampoline) 傳回+ msleep(100) WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline)在此修補程式之前執行 PoC 時執行 PoC 可輕鬆重現當機問題 (幾乎 100%)其呼叫追踪與 KaiyanM 的報告類似。在修補程式之後即使經過數百萬次重複該錯誤也不會再發生。 (CVE-2026-23319)

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

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

  - i2ci801還原 i2ci801以 I2C 匯流排鎖定取代 acpi_lock。這會還原認可 f707d6b9e7c18f669adfdb443906d46cfbaaa0c1。在極少數情況下多個 udev 執行緒可在開機時收集 i801 裝置資訊並以某種方式並行執行 i801_acpi_io_handler。第一個版本會記錄 acpi 保留的區域以防止進一步接觸。這最終會造成該區域遭到取消註冊。第二個弱點會在區域取消註冊之後但在可以檢查區域是否已取消註冊之前進入 i801_acpi_io_handler。 i2c_lock_bus 依賴現已取消註冊且含有 lock_ops 的區域來鎖定匯流排。最終會導致開機時發生核心錯誤且反向追踪如下[ 14.971872] ioatdma 0000:09:00.2啟用裝置 (0100 -> 0102) [ 14.971873] 錯誤核心 NULL 指標解除參照、位址
    0000000000000000 [ 14.971880] #PF核心模式中的監督讀取存取權 [ 14.971884] #PF
    error_code(0x0000) - 不存在頁面 [ 14.971887] PGD 0 P4D 0 [ 14.971894] Oops: 0000 [#1] PREEMPT SMP PTI [ 14.971900] ] CPU: 5 PID: 956 Comm: systemd-udevd 未受污染 5.14。 0-611.5.1.el9_7.x86_64 #1 [14.971905] 硬體名稱 XXXXXXXXXXXXXXXXXXXXXXX BIOS 1.20.10。SV91 2023 年 1 月 30 日 [ 14.971908] RIP
    0010:i801_acpi_io_handler+0x2d/0xb0 [i2c_i801] [ 14.971929] 程式碼00 00 49 8b 40 20 41 57 41 56 4d 8b b8 30 04 00 00 49 89 ce 41 55 41 89 d5 41 54 0 9 09 f4 00 55 4c 89 c5 53 89 fb <48> 8b 00 4c 89 c7 e8 18 61 54 e9 80 bd 80 04 00 00 00 75 09 4c 3b [ 14.971933] RSP: 0018:ffffbaa841483838 EFLAGS: 00010282 [14.971938] RAX: 0000000000000000 RBX0000000000000000 RCXffff9685e01ba568 [ 14.971941] RDX
    0000000000000008 RSI0000000000000002 RDI0000000000000000 [ 14.971944] RBPffff9685ca22f028 R08
    ffff9685ca22f028 R09ffff9685ca22f028 [ 14.971948] R10000000000000000b R110000000000000580 R12
    0000000000000580 [ 14.971951] R13: 0000000000000008 R14: ffff9685e01ba568 R15: ffff9685c222f000 [14.971954] FS: 00007f8287c0ab40(0000) GS:ffff96a47f940000(0000) knlGS:0000000000000000 [ 14.971959] CS:
    0010 DS0000 ES0000 CR00000000080050033 [ 14.971963] CR20000000000000000 CR30000000168090001 CR4
    00000000003706f0 [ 14.971966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [14.971968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 14.971972] Call Trace: [14.971977] <TASK> [ 14.971981] ? show_trace_log_lvl+0x1c4/0x2df [ 14.971994] ? show_trace_log_lvl+0x1c4/0x2df [ 14.972003] ? acpi_ev_address_space_dispatch+0x16e/0x3c0 [ 14.972014]
    __die_body.cold+0x8/0xd [ 14.972021] ? page_fault_oops+0x132/0x170 [ 14.972028] ? exc_page_fault+0x61/0x150 [ 14.972036] ? asm_exc_page_fault+0x22/0x30 [ 14.972045] i801_acpi_io_handler+0x2d/0xb0 [i2c_i801] [ 14.972061] acpi_ev_address_space_dispatch+0x16e/0x3c0 [14.972069] ? __pfx_i801_acpi_io_handler+0x10/0x10 [i2c_i801] [ 14.972085] acpi_ex_access_region+0x5b/0xd0 [ 14.972093] acpi_ex_field_datum_io+0x73/0x2e0 [ 14.972100] acpi_ex_read_data_from_field+0x8e/0x230 [14.972106] acpi_ex_resolve_node_to_value+0x23d/0x310 [ 14.972114] acpi_ds_evaluate_name_path+ 0xad/0x110 [14.972121] acpi_ds_exec_end_op+0x321/0x510 [ 14.972127] acpi_ps_parse_loop+0xf7/0x680 [ 14.972136] acpi_ps_parse_aml+0x17a/0x3d0 [ [] ] acpi_ps_execute_method+0x137/0x270 [ 14.972143] acpi_ps_parse_loop+0xf7/0x680 [ [] ] acpi_ps_execute_method+0x137/0x270 [ 14.972150x1evalf]4_nsx2_70 [0x2+ 14.972158] ] ] acpi_evalulate_object+0x134/0x2f0 [ 14.972164] acpi_evalulate_integer+0x50/0xe0 [ 14.972173] ? vsnprintf+0x24b/0x570 [ 14.972181] acpi_ac_get_state.part.0+0x23/0x70 [ 14.972189] get_ac_property+0x4e/0x60 [ 14.972195] power_supply_show_property+0x90/0x1f0 [ 14.972205] add_prop_uevent+0x29/0x90 [ 14.972213] power_supply_uevent +0x109/0x1d0 [ 14.972222] dev_uevent+0x10e/0x2f0 [ 14.972228] uevent_show+0x8e/0x100 [14.972236] dev_attr_show+0x19 ---truncated--- (CVE-2026-23369)

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

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

  - wifi：MT76：MT7925：修正可能的 OOB 存取問題mt7925_mac_write_txwi_80211 在存取 mt7925_mac_write_txwi_80211 管理欄位前檢查幀長度，以避免可能的 OOB 存取。
    (CVE-2026-23363)

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

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

  - blktrace修正搶占式內容中的 __this_cpu_read/write tracing_record_cmdline() 內部使用
    per-CPU 變數 trace_cmdline_save 和 trace_save_cmdline() 上的 __this_cpu_read() 和 __this_cpu_write() 透過 lockdep_assert_preemption_disabled() 明確宣告先佔已停用。
    這些作業只有在先佔關閉時才是安全的因為這些作業原本是設計來從排程器內容呼叫 (probe_wakeup_sched_switch() / probe_wakeup())。 __blk_add_trace() 在 blk_tracer 路徑中較早地在環緩衝區保留之前從完全啟用先佔的處理程序內容呼叫 tracing_record_cmdline(current)。這會使用 blktests/blktrace/002 觸發下列問題
    blktrace/002 (具有 sysfs 追踪的 blktrace ftrace 損毀) [失敗] 運行時間在 dmesg 中發現 0.367s ... 0.437s 某個項目[ 81.211018] 在 2026-02-25 22:24:33 執行 blktests blktrace/002 [ 81.239580] null_blk已建立磁碟 nullb1 [ 81.357294] 錯誤在搶占式中使用 __this_cpu_read() [00000000] 代碼dd/2516 [81.362842] 呼叫者為 tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU16 UID0 PID2516 Comm dd 污染的 GN 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] 污染的 [N]=TEST [ 81.362878] 硬體名稱
    QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [81.362881] 呼叫追踪[ 81.362884] <TASK> [ 81.362886] dump_stack_lvl +0x8d/0xb0 ... (請參閱「/mnt/sda/blktests/results/nodev/blktrace/002.dmesg」的完整訊息」) [ 81.211018] 在 2026-02-25 22:24:33 執行 blktests blktrace/002 [ 81.239580] null_blk已建立磁碟 nullb1 [ 81.357294] 錯誤使用
    preemptible 中的 __this_cpu_read() [00000000] 程式碼dd/2516 [ 81.362842] 呼叫者為 tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU16 UID0 PID 2516 通訊dd 污染GN 7.0.0-rc1lblk+ #84 PREEMPT (完整) [ 81.362877] 受污染[N]=TEST [ 81.362878] 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/ 01/2014 [ 81.362881] 呼叫追踪 [ 81.362884] [] <TASK> [ 81.362886] dump_stack_lvl+0x8d/0xb0 [ 81.362895] check_preemption_disabled+0xce/0xe0 [ 81.362902] tracing_record_cmdline+0x10/0x40 [ 81.362923]
    __blk_add_trace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30 [ 81.362959] blk_add_trace_bio+0x106/0x1e0 [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0 [ 81.362979] lockdep_init_map_type+0x58/0x260 [ 81.362988] submit_bio_wait+0x56/0x90 [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250 [ 81.363026] ?
    __pfx_submit_bio_wait_endio+0x10/0x10 [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0 [ 81.363051] blkdev_read_iter+0xc1/0x140 [ 81.363059] vfs_read+0x20b/0x330 [ 81.363083] ksys_read+0x67/0xe0 [81.363090] do_syscall_64+0xbf/0xf00 [ 81.363102] entry_SYSCALL_64_after7_hwframe+0x76/0 [ 81.363106] RIP 0033:0x7f281906029d [ 81.363111] 程式碼31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 00 3d 41 33 0e 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP002b00007ffca127dd48 EFLAGS00000246 ORIG_RAX
    0000000000000000 [ 81.363120] RAX ffffffffffffffda RBX 0000000000000000 RCX 00007f281906029d [81.363122] RDX 0000000000001000 RSI 0000559f8bfae000 RDI: 00000000 81.3631230000000000000000]
    000000000001000 R080000002863a10a81 R0900007f281915f000 [ 81.363124] R1000007f2818f77b60 R11
    0000000000000246 R120000559f8bfae000 [ 81.363126] R130000000000000000 R140000000000000000 R15
    000000000000000a [ 81.363142</TASK> ]  blk_add_trace_plug()、blk_add_trace_unplug() 和 blk_add_trace_rq() 路徑也會觸發相同的錯誤。tracen 的用途 ---truncated--- (CVE-2026-23374)

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

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

  - ice將 XDP RxQ frag_size 從 DMA 寫入長度變更為 xdp.frame_sz。XDP RxQ 資訊中 frag_size 欄位的唯一使用者是 bpf_xdp_frags_increase_tail()。它顯然會預期完整的緩衝區大小而非 DMA 寫入大小。ice 驅動程式組態中的不同假設導致負的 tailroom。當使用 XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver 測試並將封包大小變更為 6912 並將要求的位移變更為巨大值 (例如 XSK_UMEM__MAX_FRAME_SIZE * 100) 時允許觸發核心錯誤。由於 ice 中 ZC 組態的其他 quirk 在 ZC 模式下不會觀察到錯誤但 tailroom 成長 (其實並非如此) 時仍會失敗。在 XDP RxQ 資訊中使用填滿佇列緩衝區 truesize而非 DMA 寫入大小。使用新的協助程式也修正 ZC 模式。 (CVE-2026-23377)

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

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

  - drbd修正本機讀取錯誤上的 null 指標解除參照。在 drbd_request_endio() 中READ_COMPLETED_WITH_ERROR 會以 NULL peer_device __req_mod(req, what, NULL, &m); 傳送至 __req_mod() READ_COMPLETED_WITH_ERROR 處置程式會無條件將此 NULL peer_device 傳送至 drbd_set_out_of_sync()並予以解除參照進而造成 null 指標解除參照。透過 first_peer_device(device) 取得 peer_device 來修正此問題符合 drbd_req_destroy() 處理相同情況的方式。
    (CVE-2026-23285)

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

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

  - nfsd修正 nfsd_nl_threads_set_doit() 中的 cred ref 洩漏。 syzbot 報告結構 cred 的記憶體洩漏。 [0] nfsd_nl_threads_set_doit() 將 get_current_cred() 傳送至 nfsd_svc()但之後不會呼叫 put_cred()。cred 最終會向下傳遞至 _svc_xprt_create()然後再以 struct svc_xprt 的 cred 呼叫 get_cred()。get_current_cred() 對 refcount 的擁有權並未轉移至任何位置而且只會洩漏。 nfsd_svc() 也會從 write_threads() 呼叫但它不會在該處緩衝 file->f_cred。
    從 sendmsg() 呼叫 nfsd_nl_threads_set_doit()而 current->cred 並未消失。讓我們使用 nfsd_nl_threads_set_doit() 中的 current_cred()。 [0]錯誤記憶體洩漏未參照物件 0xffff888108b89480 (大小 184)comm syz-executor、pid 5994、jiffies 4294943386 十六進位轉儲存 (前 32 個位元組)01 00 00 00 00 00 00 00 00 00 00 000 00 00 00 0 ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ 反向追踪 ( crc 369454a7): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [內嵌] slab_post_alloc_hook mm/slub.c:4958 [內嵌] slab_alloc_node mm/slub.c:5263 [內嵌] kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c 5270 prepare_creds+0x22/0x600 kernel/cred.c:185 copy_creds+0x44/0x290 kernel/cred.c:286 copy_process+0x7a7/0x2870 kernel/fork.c:2086 kernel_clone+0xac/0x6e0 kernel/fork.c:2651 __do_sys_clone +0x7f/0xb0 kernel/fork.c:2792 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2026-23297)

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

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

  - InsightSoftwareConsortium ITK 中的整數溢位或 Wraparound 弱點 (Modules/ThirdParty/Expat/src/expat 模組)。此問題會影響 ITK 2.7.1之前的版本。 (CVE-2026-4739)

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

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

  - can： ems_usb： ems_usb_read_bulk_callback（）：檢查訊息的適當長度 檢視 USB URB 中的數據時，actual_length是傳遞給驅動程式的緩衝區大小，而不是驅動程式設定為緩衝區大小上限的transfer_buffer_length。在剖析 ems_usb_read_bulk_callback（） 中的訊息時，請在剖析訊息的開始時正確檢查大小，以確保它對於預期的結構足夠大，並在訊息結束時檢查大小，以確保我們不會溢位超過下一條訊息的緩衝區末尾。（CVE-2026-23307）

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

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

  - canusbetas_es58x在讀取大量回呼中正確錨定 urb 提交使用錨點模式的 urb 時必須先錨定該指標再提交否則可能會在呼叫 usb_kill_anchored_urbs() 時洩漏。此邏輯已在驅動程式的其他位置正確完成但讀取大量回呼故此處也正確執行。 (CVE-2026-23324)

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

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

  - drbd修正 drbd_al_begin_io_nonblock() 中的邏輯錯誤即使我們檢查了保留 device->al_lock spinlock 時是否應可執行 lc_get_cumulative()仍可能會失敗如果其他程式碼路徑決定使用 進行 lc_try_lock()時機錯誤。如果發生這種情況我們會記錄 enr=... 的邏輯錯誤但仍未傳回錯誤。程式碼的其餘部分現在假設此要求具有相關活動記錄範圍的參照。這表示主動重新同步期間無法保證重新同步與應用程式 IO 會相互獨占。且此時的潛在損毀可能並未意識到這些範圍可能是執行中 IO 的目標且需要重新同步以防萬一。此外一旦要求完成會放棄甚至不保留的活動記錄參照這會在 lc_put() 中觸發 BUG_ON(refcnt == 0)。修正在正常作業期間不會因無害的情況不損毀核心也擷取 e->refcnt == 0當非作用中範圍 %u 上呼叫的 al_complete_io() 有雜訊時不只擷取 e == NULL\n。也不要自作聰明地去猜測某項工作是否會運作，然後在沒有結果的時候感到意外。處理它可能會或可能無法運作的事實。
    否則請記住可能部分處於活動記錄狀態 (只有跨範圍邊界的要求才可能)並從 drbd_al_begin_io_nonblock() 傳回錯誤碼。之後針對相同要求的呼叫將從中斷處繼續。 (CVE-2026-23356)

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

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

  - drm/vmwgfx在 vmw_translate_ptr 函式中傳回正確值。在參照的修正程式之前這些函式使用可傳回指標的查閱函式。這已變更為另一個查閱函式該函式傳回錯誤碼且指標變成 out 參數。查閱失敗時的錯誤路徑並未變更以反映此變更且程式碼會繼續傳回現已未初始化之指標的 PTR_ERR。這可造成 vmw_translate_ptr 函式在實際失敗進而導致進一步未初始化和 OOB 存取時傳回成功。 (CVE-2026-23317)

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

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

  - ksmbd：在常數時間內比較 為防止時序攻擊，MAC 比較必須為常數時間。
    將 memcmp（） 替換成正確的函式，crypto_memneq（）。（CVE-2026-23364）

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

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

  - 藍牙清除通訊端解構函式中的錯誤佇列透過 SO_TIMESTAMPING 啟用 TX 時間戳記時SKB 可能會排入 sk_error_queue 佇列並留在那裡直到消耗。如果使用者空間永遠無法讀取時間戳記或控制器遭到意外移除這些 SKB 將會洩漏。透過在受影響的藍牙解構函式中新增 sk_error_queue 的 skb_queue_purge() 呼叫來修正。RFCOMM 目前未使用 sk_error_queue。 (CVE-2026-23299)

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

ID	名稱	嚴重性
303763	Linux Distros 未修補的弱點：CVE-2025-67030	high
303762	Linux Distros 未修補的弱點：CVE-2026-23353	medium
303761	Linux Distros 未修補的弱點：CVE-2026-23329	medium
303760	Linux Distros 未修補的弱點：CVE-2026-21717	medium
303743	Linux Distros 未修補的弱點：CVE-2026-23326	high
303742	Linux Distros 未修補的弱點：CVE-2026-23315	high
303741	Linux Distros 未修補的弱點：CVE-2026-4649	medium
303740	Linux Distros 未修補的弱點：CVE-2026-23306	high
303739	Linux Distros 未修補的弱點：CVE-2026-23311	medium
303738	Linux Distros 未修補的弱點：CVE-2026-23335	medium
303737	Linux Distros 未修補弱點：CVE-2026-23330	medium
303736	Linux Distros 未修補的弱點：CVE-2026-23359	high
303735	Linux Distros 未修補弱點：CVE-2026-23362	medium
303734	Linux Distros 未修補的弱點：CVE-2026-1519	high
303733	Linux Distros 未修補的弱點：CVE-2026-23361	high
303732	Linux Distros 未修補的弱點：CVE-2026-23372	high
303731	Linux Distros 未修補的弱點：CVE-2026-23302	medium
303730	Linux Distros 未修補的弱點：CVE-2026-23316	medium
303729	Linux Distros 未修補的弱點：CVE-2026-3119	medium
303728	Linux Distros 未修補的弱點：CVE-2026-23321	medium
303727	Linux Distros 未修補的弱點：CVE-2026-23332	medium
303726	Linux Distros 未修補的弱點：CVE-2026-23371	medium
303725	Linux Distros 未修補的弱點：CVE-2026-23300	medium
303724	Linux Distros 未修補的弱點：CVE-2026-23292	medium
303723	Linux Distros 未修補的弱點：CVE-2026-23318	high
303722	Linux Distros 未修補的弱點：CVE-2026-3104	high
303721	Linux Distros 未修補的弱點：CVE-2026-3591	medium
303720	Linux Distros 未修補的弱點：CVE-2026-23308	medium
303719	Linux Distros 未修補的弱點：CVE-2026-23334	medium
303718	Linux Distros 未修補的弱點：CVE-2026-23339	medium
303717	Linux Distros 未修補的弱點：CVE-2026-23352	medium
303716	Linux Distros 未修補的弱點：CVE-2026-23343	high
303715	Linux Distros 未修補的弱點：CVE-2026-23279	medium
303714	Linux Distros 未修補的弱點：CVE-2026-23290	medium
303712	Linux Distros 未修補的弱點：CVE-2026-23282	medium
303711	Linux Distros 未修補的弱點：CVE-2026-23346	medium
303710	Linux Distros 未修補的弱點：CVE-2026-23319	high
303709	Linux Distros 未修補的弱點：CVE-2026-23369	medium
303708	Linux Distros 未修補的弱點：CVE-2026-23363	high
303707	Linux Distros 未修補的弱點：CVE-2026-23374	medium
303705	Linux Distros 未修補的弱點：CVE-2026-23377	medium
303704	Linux Distros 未修補的弱點：CVE-2026-23285	medium
303703	Linux Distros 未修補的弱點：CVE-2026-23297	medium
303702	Linux Distros 未修補的弱點：CVE-2026-4739	critical
303701	Linux Distros 未修補的弱點：CVE-2026-23307	medium
303700	Linux Distros 未修補的弱點：CVE-2026-23324	medium
303699	Linux Distros 未修補的弱點：CVE-2026-23356	medium
303698	Linux Distros 未修補的弱點：CVE-2026-23317	high
303697	Linux Distros 未修補的弱點：CVE-2026-23364	high
303696	Linux Distros 未修補的弱點：CVE-2026-23299	medium

偵測

Nessus 的 Misc. 系列

high

medium

medium

medium

high

high

medium

high

medium

medium

medium

high

medium

high

high

high

medium

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

high

medium

high

medium

medium

medium

medium

critical

medium

medium

medium

high

high

medium