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

  - FreeRDP 是遠端桌面通訊協定的免費實作。 3.24.2版之前來自相鄰堆積記憶體的像素資料會轉譯至螢幕進而可能將敏感資料洩漏給攻擊者。此問題已在 3.24.2 版中修正。(CVE-2026-33985)

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

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

  - 已解決 Linux 核心中的下列弱點：ASoC: SDCA: Add allocation failure check for Entity name Currently find_sdca_entity_iot() can allocate a string for the Entity name but it doesn't check if that allocation succeeded. Add the missing NULL check after the allocation.
    (CVE-2026-23301)

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

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

  - NATS-Server 是適用於雲端與邊緣原生訊息系統 NATS.io 的高效能伺服器。在 2.11.15 與 2.12.6版之前NATS 訊息標頭「Nats-Request-Info:」應為 NATS 伺服器的身分保證但從傳入訊息去除此標頭的作業並未完全生效。攻擊者若具備任何一般用戶端介面的有效認證就可針對依賴此標頭的服務偽造其身分。 2.11.15 和 2.12.6 版包含一個修正。尚無已知的因應措施可以採用。(CVE-2026-33223)

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

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

  - NATS-Server 是適用於雲端與邊緣原生訊息系統 NATS.io 的高效能伺服器。從 2.2.0 版和 [] 版 2.11.142.12.5版及其之前的版本開始WebSockets 框架上缺少的例行性檢查可在 nats-server 中觸發伺服器錯誤。這會發生在驗證之前因此會暴露給可連線至 websockets 連接埠的任何人。 2.11.14 和 2.12.5 版包含一個修正。現也已提供因應措施。此弱點只會影響使用 WebSockets 且會將網路連接埠暴露給未受信任端點的部署。如果能夠做到這一點，限制其中任何一個的深度防禦將減輕攻擊。 (CVE-2026-27889)

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

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

  - NATS-Server 是適用於雲端與邊緣原生訊息系統 NATS.io 的高效能伺服器。 2.11.15 和 2.12.6版之前的版本, 針對使用使用者程式碼/密碼的 MQTT 部署MQTT 密碼被錯誤地歸類為非驗證身分陳述 (JWT)並透過監控端點洩漏。 2.11.14 和 2.12.6 版包含一個修正。因應措施為確保監控端點受到充分保護。最佳做法仍然是不要將監控端點洩漏給網際網路或其他不受信任的網路使用者。 (CVE-2026-33216)

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

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

  - NATS-Server 是適用於雲端與邊緣原生訊息系統 NATS.io 的高效能伺服器。在 2.11.15 和 2.12.6版之前可連線至分葉節點連接埠的用戶端可透過格式錯誤的預先驗證訊息使 nats-server 當機。 2.11.15 和 2.12.6 版包含一個修正。因應措施為在不需要時停用分葉節點支援或在合理情況下在不影響所提供服務的情況下限制分葉節點連接埠的網路連線。 (CVE-2026-33218)

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

遠端主機上安裝的 Vim 版本介於 9.1.0011 (含) 和 9.2.0137 (不含) 之間。因此會受到 GHSA-9phh-423r-778r 公告中所提及的一個弱點影響。

  - Vim 是開放原始碼命令列文字編輯器。在 9.1.0011 到 9.2.0137之前的版本中Vim 的 NFA regex 編譯器遇到含有作為字元範圍端點之組合字元的集合時會不正確地發出該字元的撰寫位元組作為獨立的 NFA 狀態。這會損毀 NFA postfix 堆疊造成 NFA_START_COLL 的 out1 指標為 NULL。當 nfa_max_width() 隨後遊走已編譯的 NFA 以估計向後宣告宣告的比對寬度時它會在未進行 NULL 檢查的情況下解除參照 state->out1->out進而造成分割錯誤。此弱點已在 9.2.0137 中修復。(CVE-2026-32249)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 Vim 版本低於 9.2.0202。因此，它受到 GHSA-w5jw-f54h-x46c 公告中提及的一個弱點影響。

  - Vim 是開放原始碼命令列文字編輯器。在類 Unix 系統中，Vim  9.2.0202 之前版本的 glob() 函式 (具體而言是 mch_expand_wildcards() 函式) 會建構萬用字元擴充的 shell 命令，但無法正確逸出新行字元。攻擊者可在 glob 模式中插入新行，以執行任意 shell 命令，具體視使用者的 shell 組態而定。此弱點已在 9.2.0202 中修復。(CVE-2026-33412)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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

  - 惡意特製的 TIFF 檔案會造成影像解碼嘗試配置 4GiB 的記憶體進而造成資源過度消耗或發生記憶體不足錯誤。 (CVE-2026-33809)

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

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修正 mt76_connac2_mac_write_txwi_80211() 中可能的 oob 存取 () 在存取 mt76_connac2_mac_write_txwi_80211 中的 mgmt 欄位之前檢查框架長度以避免可能的 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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - scsipm8001修正 pm8001_queue_command() 提交中的釋放後使用問題 (scsipm8001簡化 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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - nfcnci裝置關閉時完成擱置的資料交換在 nci_close_device() 中關閉前完成所有擱置的資料交換。資料交換回呼 (例如 rawsock_data_exchange_complete) 會保留通訊端參照。NIPA 偶爾會發生此洩漏 未參照的物件 0xff1100000f435000 (大小 2048)comm nci_dev、pid 3954、jiffies 4295441245 十六進位轉儲存 (前 32 個位元組)00 00 00 00 00 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 __dsys_socket+0x115/01115/011
    __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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - canbcm修正 bcm_op 運行時間更新的鎖定 提交 c2aba69d0c36 (canbcm新增 bcm_op 運行時間更新的鎖定) 針對某些變數新增鎖定在 bcm_tx_setup 中使用新的 TX_SETUP 命令更新傳送 bcm_op 時新增可在運行時間修改的鎖定 ( )。通常 RX_SETUP 只會處理和篩選傳入的流量有一個例外狀況：當設定 RX_RTR_FRAME 旗標時，會在收到特定 RTR 框架時傳送預定義的 CAN 框架。因此 rx bcm_op 會使用 bcm_can_tx()而 bcm_can_tx()會使用 bcm_tx_lock該 bcm_tx_lock 只在 bcm_tx_setup() 中初始化。在 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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - netipv6修正當 IPv4 路由參照回送 IPv6 nexthop 時發生的不穩定情形。使用回送裝置建立獨立 IPv6 nexthop 物件時 (例如 ip -6 nexthop add id 100 dev lo)fib6_nh_init() 會將其錯誤分類為拒絕路由。這是因為 nexthop 物件沒有目的地前置詞 (fc_dst=::)造成 fib6_is_reject() 符合任何回送 nexthop。拒絕路徑會略過 fib_nh_common_init()使 nhc_pcpu_rth_output 保持未配置狀態。如果 IPv4 路由稍後參照此 nexthop__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 路由參照此 nexthop 時發生的當機情況。 (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.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-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: 修正 mt7925_mac_write_txwi_80211() 中可能的 oob 存取權在存取 mt7925_mac_write_txwi_80211 中的 mgmt 欄位前檢查框架長度以避免可能的 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 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
303829	Linux Distros 未修補的弱點：CVE-2026-33985	high
303828	Linux Distros 未修補的弱點：CVE-2026-23301	medium
303827	Linux Distros 未修補的弱點：CVE-2026-33223	medium
303826	Linux Distros 未修補的弱點：CVE-2026-27889	high
303825	Linux Distros 未修補的弱點：CVE-2026-33216	high
303824	Linux Distros 未修補的弱點：CVE-2026-33218	high
303794	Vim >= 9.1.0011 < 9.2.0137 NULL 指標解除參照 (GHSA-9phh-423r-778r)	medium
303793	Vim < 9.2.0202 命令插入 (GHSA-w5jw-f54h-x46c)	high
303764	Linux Distros 未修補的弱點：CVE-2026-33809	medium
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	medium
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	high
303737	Linux Distros 未修補的弱點：CVE-2026-23330	high
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	high
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	high
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	high
303719	Linux Distros 未修補的弱點：CVE-2026-23334	medium
303718	Linux Distros 未修補的弱點：CVE-2026-23339	medium
303717	Linux Distros 未修補的弱點：CVE-2026-23352	high
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	high
303711	Linux Distros 未修補的弱點：CVE-2026-23346	medium
303710	Linux Distros 未修補的弱點：CVE-2026-23319	medium
303709	Linux Distros 未修補的弱點：CVE-2026-23369	medium
303708	Linux Distros 未修補的弱點：CVE-2026-23363	high
303707	Linux Distros 未修補的弱點：CVE-2026-23374	high
303705	Linux Distros 未修補的弱點：CVE-2026-23377	high

偵測

Nessus 的 Misc. 系列

high

medium

medium

high

high

high

medium

high

medium

high

medium

medium

medium

medium

high

medium

high

medium

high

high

high

medium

high

high

high

high

medium

medium

medium

medium

high

medium

medium

high

high

medium

high

medium

medium

high

high

medium

medium

high

medium

medium

medium

high

high

high