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

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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - canems_usbems_usb_read_bulk_callback()檢查訊息長度是否正確查看 USB urb 中的資料時actual_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 若要防止定時攻擊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 的判定取決於廠商所報告的套件是否存在。

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

  - canucan修正來自零長度訊息的無限迴圈 如果損毀的 ucan 裝置收到訊息長度欄位設為 0 的訊息則驅動程式將會在 ucan_read_bulk_callback() 中進行永遠迴圈進而使系統懸置。如果長度為 0則直接略過訊息並移至下一封訊息。這已在過去的認可 0c73772cd2b8 中的 kvaser_usb 驅動程式中修正 (cankvaser_usb: leaf修正命令剖析器中的潛在無限迴圈)因此某處必須有一些像這樣的損毀裝置。
    (CVE-2026-23298)

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

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

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

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

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

  - cxl修正建立 nvdimm 物件時的 nvdimm_bus 物件爭用。在執行 cxl-translate.sh 單元測試期間發現 問題。在測試前新增 3s 睡眠似乎可以相當一致地重現問題。cxl_translate 模組相依於 cxl_acpi並造成孤立的 nvdimm 物件在移除 cxl_acpi 後重新探測。cxl_nvb 物件會在呼叫 cxl_acpi_probe() 時註冊 nvdimm_bus 物件。由於缺少 nvdimm_bus 物件__nd_device_register() 會在存取指向 &nvdimm_bus->dev 的 dev->parent 時觸發 NULL 指標解除參照。 [ 192.884510] 錯誤
    核心 NULL 指標解除參照、位址000000000000006c [ 192.895383] 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)、BIOS edk2-20250812-19.fc42 2025 年 8 月 12 日 [ 192.897721] 工作佇列cxl_port cxl_bus_rescan_queue [cxl_core] [ 192.899459] RIP0010:kobject_get+0xc/0x90 [ 192.924871] 呼叫追踪 [192.925959] <TASK> [ 192.926976] ? pm_runtime_init+0xb9/0xe0 [ 192.929712]
    __nd_device_register.part.0+0x4d/0xc0 [libnvdimm] [ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm] [192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem] [ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core] [192.943349] ] ] real_probe+0xde/0x380 此修補程式也依賴先前的變更 (從 drivers/cxl/pmem.c 而非 drivers/cxl/core.c 呼叫 devm_cxl_add_nvdimm_bridge())以確保 cxl_acpi 與 cxl_pmem 的相依性。 1. 將 probe_type of cxl_nvb 設定為 PROBE_FORCE_SYNCHRONOUS確保呼叫 add_device() 時同步探查驅動程式。 2. 新增簽入
    __devm_cxl_add_nvdimm_bridge()確保在 cxl_acpi_probe() 期間附加 cxl_nvb 驅動程式。 3.
    檢查 nvdimm_bus 是否有效之前在 devm_cxl_add_nvdimm() 中取得 cxl_root uport_dev 鎖定和 cxl_nvb->dev 鎖定。 4. 將 cxl_nvdimm 旗標設定為 CXL_NVD_F_INVALIDATED以便 cxl_nvdimm_probe() 以 結束
    -EBUSY。cxl_nvdimm 裝置的移除應可防止任何孤立裝置在 nvdimm_bus 消失後進行探查。 [ dj修正 0 天報告的 kdoc 問題。 ] [ dj修正錯誤時發生的 cxl_nvb 參照洩漏。
    Gregory (kreview-0811365) ] (CVE-2026-23348)

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

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

  - 當使用 OpenWire 通訊協定的應用程式嘗試在不屬於具有 createDurableQueue 之經驗證使用者的位址上建立非持續的 JMS 主題訂閱時Apache Artemis 中存在不正確授權 (CWE-863) 弱點Apache ActiveMQ Artemis權限，但沒有 createAddress 權限，而且位址自動建立功能已停用。在此情況下將會建立一個暫存位址而建立非持續訂閱的嘗試反而會失敗因為使用者未獲得建立對應位址的授權。OpenWire 連線關閉時會移除位址。此問題會影響 Apache Artemis 從 2.50.0 到 2.52.0Apache ActiveMQ Artemis從 2.0.0 到 2.44.0。建議使用者升級至 2.53.0 版，即可修正此問題。(CVE-2026-32642)

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

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

  - netethernetmtk_eth_socmtk_xdp_setup() 發生錯誤時將 prog ptr 重設為 old_prog如果 mtk_xdp_setup() 中的 mtk_open 常式失敗則將 eBPF 程式指標重設為 old_prog且不減少其 ref-count。 (CVE-2026-23284)

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

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

  - canmcp251x修正 mcp251x_open 錯誤路徑中的鎖死。mcp251x_open() 函式利用保留的 mpc_lock mutex 呼叫其錯誤路徑中的 free_irq()。但若已發生中斷中斷處置程式將會等候 mpc_lock而 free_irq() 會等候處置程式完成而鎖死。此問題與提交 7dd9c26bd6cf (canmcp251x在 mcp251x_open 期間發生中斷時修正鎖死) 中修正的問題類似但針對錯誤路徑。若要解決此問題在鎖定釋放後將呼叫移至 free_irq()。預先設定 `priv->force_quit = 1`可確保 IRQ 處置程式在取得鎖定後立即結束。 (CVE-2026-23357)

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

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

  - Squid 是一種用於 Web 的快取代理伺服器。在 7.5版之前由於在預期存留期過早釋放資源以及堆積釋放後使用錯誤Squid 在處理 ICP 流量時容易受到拒絕服務影響。此問題允許遠端攻擊者對使用 ICP 通訊協定的 Squid 服務執行可靠且可重複的拒絕服務攻擊。此攻擊限於明確啟用 ICP 支援的 Squid 部署 (即設定非零 `icp_port`)。此問題_無法_透過使用 `icp_access` 規則拒絕 ICP 查詢來減輕。此錯誤已在 Squid 版本 7.5中修正。 (CVE-2026-32748)

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

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

  - wifi: cfg80211取消 wiphy_unregister() 中的 rfkill_block 工作。syzkaller 在 cfg80211_shutdown_all_interfaces 中發現一個釋放後使用錯誤錯誤KASAN7788 載入 cfg80211_shutdown_all_interfaces+0x213/0x220addr ffff888112 中的大小 8 讀取釋放後使用錯誤task kworker/0:5/5326 CPU0 UID0 PID5326 Commkworker/0:5 未受污染的 6.19.0-rc2 #2 PREEMPT(自發) 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: <TASK> dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/ 0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 </TASK> 發生此問題的原因是取消註冊 wiphy 時並未取消 rfkill_block 工作。若要修正此問題請取消 wiphy_unregister() 中的對應工作。由 Linux Verification Center (linuxtesting.org) 的 Syzkaller 發現。 (CVE-2026-23336)

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

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

  - netsched避免無鎖定 qdisc 的 qdisc_reset_all_tx_gt() 與 dequeue 爭用當縮減 real tx 佇列的數目時netif_set_real_num_tx_queues() 會呼叫 qdisc_reset_all_tx_gt() 來排清將不再使用的佇列的 qdisc。 qdisc_reset_all_tx_gt() 目前將 qdisc_reset() 與 qdisc_lock() 序列化。不過如果是無鎖定的 qdisc qdisc_run_begin/end() 會使用 qdisc->seqlock 來序列化取消佇列路徑因此 qdisc_reset() 可以與 __qdisc_run() 同時執行並在 skbs 仍處於取消佇列時加以釋放進而導致 UAF。這很容易在如 virtio-net 上藉由在頻繁變更佇列組數的同時強制繁重流量而重現 iperf3 -ub0 -c $peer -t 0 & while do ethtool -L eth0 combine 1 ethtool -L eth0 combine 2 done 在啟用 KASAN 的情況下這會導致產生如下報告
    BUG: KASAN__qdisc_run+0x133f/0x1760 ... 中的 slab 釋放後使用呼叫追踪 <TASK>...
    __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 3udp/0a/0x1590 3udp/0a/0x1590 3udp/0a/0x1590 3udp/0a/0x1590 ...1x9x_1g+0x10x2e6/0x480
    </TASK> 由 cpu 5 上的 44.558414s 工作 1270 配置... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendxfcg+0 ...x13a6/0x830 Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a /0x890 ... 針對 TCQ_F_NOLOCK qdiscs 採用 qdisc->seqlock 針對無鎖定的取消佇列路徑序列化 qdisc_reset_all_tx_gt()符合 dev_reset_queue() 已使用的序列化模型。此外重設後會清除 QDISC_STATE_NON_EMPTY因此 qdisc 狀態會反映空佇列避免不必要的重新排程。 (CVE-2026-23340)

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

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

  - bpf、arm64強制 JIT 緩衝區的 8 位元組對齊以防止不可部分完成破壞 bpf_plt 中含有 u64 目標欄位的結構。BPF JIT 配置器目前要求 JIT 緩衝區的 4 位元組對齊 (sizeof(u32))。由於 JIT 緩衝區的基底位址可以是 4 位元組對齊 (例如結尾為 0x4 或 0xc)因此 build_plt() 中的相對填補邏輯無法確保目標落在 8 位元組邊界上。這會導致兩個問題 1. UBSAN 報告解除參照結構時出現存取不當警告。 2. 更為重要的是目標是在 JIT 程式碼執行 ldr 時透過 bpf_arch_text_poke() 中的 WRITE_ONCE() 並行更新。在 arm64 中若 64 位元載入/儲存符合 64 位元則僅保證其為不可部分完成。未對齊的目標有可能發生讀取損毀進而導致 JIT 跳至損毀的位址。透過在 bpf_jit_binary_pack_alloc() 中將配置對齊要求提高到 8 位元組 (sizeof(u64)) 來修正此問題。這會將 JIT 緩衝區的基底錨定至 8 位元組邊界允許 build_plt() 中的相對填補數學正確對齊目標欄位。 (CVE-2026-23383)

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

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

  - net/schedact_ife修正 metalist 更新行為每當 ife 動作取代變更 metalist 目前 ife 程式碼並未取代 metalist 上的舊資料而是附加新的詮釋資料。
    這不僅是不當行為還可導致無限制地將詮釋資料新增至 metalist其可在執行編碼 op 時造成超出邊界錯誤 [ 138.423369][ C1] =========== ================================================== ===== [ 138.424317][ C1] 錯誤: KASANife_tlv_meta_encode (net/ife/ife.c:168) 發生平台超出邊界問題 [ 138.424906][ C1] 寫入位址 ffff8880077f4ffe 的大小為 4依 task ife_out_out_bou/255 [ 138.425778][ C1] CPU1 UID0 PID255 Comm
    ife_out_out_bou 未受污染的 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(完整) [ 138.425795][ C1] 硬體名稱: Bochs BochsBIOS Bochs 01/01/2011 [ 138.425800][ C1] 呼叫追踪[ 138.425804][ C1] <IRQ> [138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122) [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c 482) [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (辨別器 1) ./include/linux/rcupdate.h:975 (辨別器 1) ./include/linux/mmzone.h:2207 (辨別器 1 ) arch/x86/mm/physaddr.c:54 (辨別器 1)) [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (辨別器 1) mm/kasan/generic.c:200 (辨別器 1)) [ 138.425884][ C1]
    __asan_memset (mm/kasan/shadow.c:84 (辨別器 2)) [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171) [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57) [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ?
    __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45) [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879) 若要解決此問題請修正取代將 metalist 新增到 ife rcu 資料結構來處理此問題。 (CVE-2026-23378)

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

ID	名稱	嚴重性
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
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	high
303700	Linux Distros 未修補的弱點：CVE-2026-23324	high
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	high
303695	Linux Distros 未修補的弱點：CVE-2026-23298	medium
303694	Linux Distros 未修補的弱點：CVE-2026-23312	medium
303692	Linux Distros 未修補的弱點：CVE-2026-23348	medium
303691	Linux Distros 未修補的弱點：CVE-2026-32642	low
303690	Linux Distros 未修補的弱點：CVE-2026-23284	medium
303689	Linux Distros 未修補的弱點：CVE-2026-23357	medium
303688	Linux Distros 未修補的弱點：CVE-2026-32748	high
303687	Linux Distros 未修補的弱點：CVE-2026-23336	high
303686	Linux Distros 未修補的弱點：CVE-2026-23340	high
303685	Linux Distros 未修補的弱點：CVE-2026-23383	high
303684	Linux Distros 未修補的弱點：CVE-2026-23378	high

偵測

Nessus 的 Misc. 系列

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

medium

medium

critical

high

high

medium

high

high

high

medium

medium

medium

low

medium

medium

high

high

high

high

high