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

  - drm/logicvc修正logicvc_drm_config_parse() 中的裝置節點參照洩漏。logicvc_drm_config_parse() 函式會呼叫 of_get_child_by_name() 以尋找層節點但無法釋放參照進而導致裝置節點參照洩漏。透過使用 __free(device_node) 清理屬性在變數超出範圍時自動釋放參照來修正此問題。 (CVE-2026-23426)

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

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

  - drm/imagination修正軟重設序列中的鎖死問題軟重設序列目前是從執行緒 IRQ 處置程式執行因此無法呼叫 disable_irq()而後者會在內部等候 IRQ 處置程式即
    本身來完成。改為在軟重設期間使用 disable_irq_nosync()。 (CVE-2026-23470)

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

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

  - PMruntime修正與裝置移除相關的爭用情形。pm_runtime_work() 中的下列程式碼可能會在釋放父項裝置後解除參照 dev->parent 指標/*也許父項現在可以暫停。 */ if (parent && !parent->power.ignore_children) { spin_unlock(&dev->power.lock);
    spin_lock(&parent->power.lock); rpm_idle(parent, RPM_ASYNC); spin_unlock(&parent->power.lock);
    spin_lock(&dev->power.lock);透過在 pm_runtime_remove() 中插入 flush_work() 呼叫來修正此問題。若無此修補程式blktest block/001 會偶爾觸發下列投訴錯誤KASANkworker/u553:1/3081 工作在 lock_acquire+0x70/0x160 讀取位址 ffff88812bef7198 的大小 1 工作佇列 pm pm_runtime_work呼叫追踪 <TASK> dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0
    __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160
    _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 </TASK> Allocated by task 4314kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0
    __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50
    __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/ 0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506 /0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 (CVE-2026-23452)

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

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

  - net/rds修正 rds_tcp_tune 中的循環鎖定相依性。syzbot 報告 rds_tcp_tune() 中有一個循環鎖定相依性問題其中會在保留通訊端鎖定時呼叫 sk_net_refcnt_upgrade()
    ================================================== ==== 警告偵測到可能的循環鎖定相依性 ======================================= =============== kworker/u10:8/15040 正在嘗試取得鎖定ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}位於__kmalloc_cache_noprof+0x4b/ 0x6f0但工作已保留鎖定 ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930 此問題是因為 sk_net_refcnt_upgrade() 執行記憶體配置 (透過 get_net_track() - > ref_tracker_alloc()) 在保留通訊端鎖定時建立與 fs_reclaim 的循環相依性。將 sk_net_refcnt_upgrade() 移至通訊端鎖定重要區段外可修正此問題。這是安全的因為此時任何並行程式碼路徑都無法存取 sk_net_refcnt_upgrade() 呼叫修改的欄位 (sk_net_refcnt、ns_tracker)。 v2 - 已更正標籤 - 檢查修補程式換行 nits - ai 評論 nits (CVE-2026-23419)

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

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

  - netmacb修正 PTP 時鐘的釋放後使用存取 PTP 時鐘會在每次開啟介面時註冊並在每次關閉時損毀。不過其可透過 get_ts_info ethtool 呼叫存取而當介面剛剛存在於核心中時即有可能。BUG: KASAN在 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 中發生釋放後使用錯誤。由工作 syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not受污染的 6.1.164+ #109 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 呼叫追踪 <TASK> __dump_stack lib/ dump_stack.c:88 [內嵌] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [內嵌] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9 /0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/ net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [內嵌] __dev_ethtool net/ethtool/ioctl.c:3017 [內嵌] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/ core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl.c:870 [內嵌] __se_sys_ioctl fs/ioctl.c:856 [內嵌]
    __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [內嵌] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 </TASK> 由工作 457 分配kmalloc include/linux/slab.h:563 [內嵌] kzalloc include/linux/slab.h:699 [內嵌] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501
    __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core /rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net /netlink/af_netlink.c:1318 [內嵌] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [內嵌]
    __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [內嵌] __se_sys_sendto net/socket.c:2160 [內嵌] __x64_sys_sendto+0xdc/ 0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [內嵌] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 已由工作 938 釋放include/linux/kasan.h:177 [內嵌] slab_free_hook mm/slub.c:1729 [內嵌] slab_free_freelist_hook mm/slub.c:1755 [內嵌] slab_free mm/slub.c:3687 [內嵌] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [內嵌] kobject_release lib/kobject.c:712 [內嵌] kref_put include/linux/kref。 h:65 [內嵌] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/ 0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_ close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [內嵌] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl
    ---truncated--- (CVE-2026-31396)

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

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

  - mac80211修正 ieee80211_chan_bw_change 中 AP_VLAN 工作站的損毀問題 ieee80211_chan_bw_change() 會反覆所有工作站並透過 sta->sdata->link[link_id] 存取 link->reserved.oper。針對 AP_VLAN 介面上的工作站 (例如 4addr WDS 用戶端)sta->sdata 會指向 VLAN sdata其連結從不參與 chanctx 保留。這會使 link->reserved.oper 以 chan == NULL 零初始化造成在 CSA 期間存取 chandef->chan->band 時在 __ieee80211_sta_cap_rx_bw() 中發生 NULL 指標解除參照。在存取連結資料之前使用 get_bss_sdata() 將 VLAN sdata 解析為其父項 AP sdata。 [即使沒有問題也變更 ARRAY_SIZE 中的 sta->sdata] (CVE-2026-31394)

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

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

  - 已解決 Linux 核心中的下列弱點：net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].
    smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free:
    sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note:
    smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected.
    Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9 (CVE-2026-23450)

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

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

  - Dokuwiki v.2025-05-14b「Librarian」中的一個問題允許遠端攻擊者透過 media.php 檔案中的 media_upload_xhr() 函式造成拒絕服務 (CVE-2026-26477)

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

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

  - netmana重新排序卸除修正 mana_hwc_destroy_channel() 中的釋放後使用問題。mana_hwc_destroy_channel() 中可能存在爭用情形其中 hwc->caller_ctx 在 HWC 的完成佇列 (CQ) 和事件佇列 (EQ) 遭到破壞之前就釋放了。這會允許執行中的 CQ 中斷處置程式解除參照已釋放的記憶體進而導致 mana_hwc_handle_resp() 中發生釋放後使用或 NULL 指標解除參照。 mana_smc_teardown_hwc() 會向硬體發出停止的訊號但不會與已在其他 CPU 上執行的 IRQ 處置程式同步。IRQ 同步只會在 mana_hwc_destroy_cq() 中透過 mana_gd_destroy_eq() -> mana_gd_deregister_irq() 發生。由於此程式在 kfree(hwc->caller_ctx) 之後執行因此並行 mana_hwc_rx_event_handler() 可解除參照 mana_hwc_handle_resp() 中已釋放的 caller_ctx (和 rxq->msg_buf)。藉由將卸除重新排序為建立反向順序來修正此問題
    在釋放 hwc->caller_ctx 之前損毀 TX/RX 工作佇列與 CQ/EQ。這可確保所有執行中的中斷處置程式在其存取的記憶體釋放前完成。 (CVE-2026-23454)

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

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

  - OpenPrinting CUPS 是適用於 Linux 和其他類 Unix 作業系統的開放原始碼列印系統。在版本 2.4.16 和之前版本中，在具有共用目標佇列的網路公開 cupsd 中，未經授權的用戶端可以在不進行驗證的情況下將列印作業傳送至該共用 PostScript 佇列。伺服器接受以 textWithoutLanguage 形式提供的頁面框線值，透過選項逸出和重新剖析保留內嵌的換行，然後將產生的第二行 PPD: text 重新剖析為受信任的排程器控制記錄。因此，後續的原始列印工作可使伺服器執行攻擊者選擇的現有二進位檔，例如 /usr/bin/vim 作為 lp。發佈之時，尚無公開可用的修補程式。(CVE-2026-34980)

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

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

  - igc修正 XDP TX 時間戳記處理中的頁面錯誤如果要求 TX 時間戳記的 XDP 應用程式關閉而使用中的介面連結仍在使用中則會報告下列核心展開攻擊 [883.803618] [ T1554] 錯誤無法處理 ffffcfb6200fd008 位址的頁面錯誤 ... [ 883.803650] [T1554] 呼叫追踪 [ 883.803652] [ T1554] <TASK> [ 883.803654] [ T1554] igc_ptp_tx_tstamp_event+0xdf/0x160 [igc] [ 883.803660] [ T1554] igc_tsync_interrupt+0x2d5/0x300 [igc] ... TX 環關閉期間xsk_meta 指標會留下因此 IRQ 處置程式會嘗試接觸這些指標。此問題現在已透過在 TX 關機時清除過時的 xsk 中繼資料的方式獲得修正。其他佇列上的 TX 時間戳記不受影響。 (CVE-2026-23445)

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

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

  - OpenPrinting CUPS 是適用於 Linux 和其他類 Unix 作業系統的開放原始碼列印系統。在版本和之前的版本 2.4.16 中，CUPS 常駐程式 （cupsd） 包含一個授權繞過弱點，這是因為在授權檢查期間不區分大小寫的使用者名稱比較。此弱點可讓無特權的使用者使用使用者名稱與授權使用者大小寫不同的使用者，來取得對受限制作業的未經授權存取權。在發佈時，沒有公開可用的修補程式。
    (CVE-2026-27447)

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

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

  - mtd避免 RedBoot 磁碟分割表格剖析器中的開機損毀。在 CONFIG_FORTIFY_SOURCE=y 和最近的編譯器情況下提交 439a1bcac648 (fortify若可用則使用 __builtin_dynamic_object_size()) 會產生以下警告和 oops。搜尋 RedBoot 磁碟分割表中 50000000.flash 的位移 0x7e0000
    ------------[cut here ]------------ 警告lib/string_helpers.c:1035 at 0xc029e04c、 CPU#0swapper/0/1 memcmp偵測到緩衝區溢位 15 位元組讀取緩衝區大小 14 連結的模組CPU0 UID0 PID1 通訊swapper/0 未受污染 6.19.0 #1 NONE 如 Kees 所述'names' 指向許多最後的 'namelen'配置的位元組...「namelen」基本上可以是任何長度。這個 fortify 警告在我看來是合法的 -- 此程式碼之前會在超出配置結尾處讀取。由於動態配置的大小是使用 strlen() 計算我們可以使用 strcmp() 而非 memcmp()並維持在邊界內。 (CVE-2026-23474)

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

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

  - OpenPrinting CUPS 是一種適用於 Linux 和其他類似 Unix 的作業系統的開放原始碼列印系統。在 2.4.16 版及更舊版本中從工作屬性構建篩選選項字串時CUPS 排程器中有堆積型緩衝區溢位情形。發佈時無任何可公開取得的修補程式。
    (CVE-2026-34979)

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

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

  - netshaper防止階層建立後期。我們在 Netlink ops (預先回呼) 準備期間查閱 netdev並取得它的參照。稍後在回呼的內文中我們採取其鎖定或 RCU這是實際的保護。netdev 可能會在我們取得該參照到我們鎖定該參照之間取消註冊。我們可能會在排清執行後配置階層這會導致洩漏。預先取得執行個體鎖定避免發生爭用且完全不需要專用的鎖定/解鎖回呼。如果有任何機會與排清同時發生寫入我們又會回到洩漏階層。我們可能會針對不支援 Shaper 的裝置採取鎖定但我們在這裡僅處理 SET 作業如果不採取鎖定會針對錯誤情況進行最佳化。 (CVE-2026-23436)

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

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

  - drm/imagination在暫停 GPU 之前同步中斷。運行時間 PM 暫停回呼不知道 IRQ 處理常式是否在不同的 CPU 核心上進行中且不會等待其完成。
    視定時而定IRQ 處置程式可在 GPU 暫停時執行進而導致嘗試存取 GPU 暫存器時核心損毀。請參閱以下簽章範例。在由運行時間 PM 暫停回呼起始的電源關閉序列中請藉由呼叫 synchronize_irq()等待其他 CPU 核心上進行中的任何 IRQ 處置程式完成。同時移除執行緒 IRQ 處置程式中的運行時間 PM resume/put 呼叫。除了不是一開始就使用的正確方法而且放在錯誤的位置 (應該包裝所有 GPU 暫存器存取)之外此外驅動程式也會在從運行時間 PM 暫停回呼呼叫的 synchronize_irq() 保留裝置之間發生鎖死電源鎖定而需要相同電源鎖定的恢復回呼。TI AM68 SK 平台上的損毀簽章範例[ 337.241218] CPU0 上的 SError 中斷代碼 0x00000000bf000000 -- SError [ 337.241239] CPU0 UID0 PID112 Comm
    irq/234-gpu 受污染 GM 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] 受污染
    [M]=MACHINE_CHECK [ 337.241249] 硬體名稱Texas Instruments AM68 SK (DT) [ 337.241252] pstate
    60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pcpvr_riscv_irq_pending+0xc/0x24 [ 337.241277] lrpvr_device_irq_thread_handler+0x64/0x310 [ 337.241282] spffff800085b0bd30 [337.241284] x29 ffff800085b0bd50 x28 ffff0008070d9eab x27 ffff800083a5ce10 [ 337.241291] x26
    ffff000806e48f80 x25ffff0008070d9eac x240000000000000000 [ 337.241296] x23ffff0008068e9bf0 x22
    ffff0008068e9bd0 x21ffff800085b0bd30 [ 337.241301] x20 ffff0008070d9e00 x19 ffff0008068e9000 x18
    0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11:
    00000000000000c0 x10 0000000000000af0 x9 ffff800085b0bd00 [ 337.241318] x8 ffff0008071175d0 x7
    000000000000b955 x6 0000000000000003 [ 337.241323] x5 0000000000000000 x4 0000000000000002 x3
    000000000000000 [ 337.241327] x2 ffff800080e39d20 x1 ffff800080e3fc48 x0 0000000000000000 [337.241333] 核心錯誤 - 未同步非同步 SError 中斷 [ 337.241337] CPU 0 UID 0 PID 112 攻擊者入侵6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] 污染
    [M]=MACHINE_CHECK [ 337.241343] 硬體名稱德州儀器 AM68 SK (DT) [ 337.241345] 呼叫追踪[337.241348] show_stack+0x18/0x24 (C) [ 337.241357] dump_stack_lvl+0x60/0x80 [ 337.241364] dump_stack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] add_taint+0x0/0xbc [ 337.241384] arm64_serror_panic+0x70/0x80 [ 337.241389] do_serror+0x3c /0x74 [337.241392] el1h_64_error_handler+0x30/0x48 [ 337.241400] el1h_64_error+0x6c/0x70 [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P) [ 337.241410] irq_thread_fn+0x2c/0xb0 [ 337.241416] irq_thread+0x170/0x3334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] ret_from_fork+0x10/0x20 [337.241434] ] SMP停止次要 CPU [ 337.241451] 核心位移停用 [ 337.241453] CPU 功能
    0x040000、02002800、20002001、0400421b [ 337.241456] 記憶體限制無 [ 337.457921] ---[ 結束核心錯誤 - 未同步非同步 SError 中斷 ]--- (CVE-2026-23469)

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

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

  - HIDbpf現在防止 hid_hw_request 中發生緩衝區溢位傳回的值會被視為一律有效。但是使用 HID-BPF 時傳回值可以是任意大的值因為這是呼叫 struct_ops 的 dispatch_hid_bpf_raw_requests() 的傳回值而且我們不保證該值一定有意義。 (CVE-2026-31401)

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

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

  - OpenPrinting CUPS 是一種適用於 Linux 和其他類似 Unix 的作業系統的開放原始碼列印系統。在 2.4.16 版和更舊版本中無權限的本機使用者可使用可重複使用的 Authorization: Local ... token 來強制 cupsd 向受攻擊者控制的 localhost IPP 服務進行驗證。該 token 足以在 localhost 上驅動 /admin/ 要求攻擊者可結合 CUPS-Create-Local-Printer 與 printer-is-shared=true 以持續存在 file:///... 佇列即使一般 FileDevice 原則拒絕此類 URI 也一樣。
    列印至該佇列會使任意 root 檔案覆寫以下 PoC 使用該原語放置 sudoers 片段並示範 root 命令執行。發佈時無任何可公開取得的修補程式。 (CVE-2026-34990)

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

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

  - netusbaqc111不執行暫停回呼內的 PM syzbot 報告 rpm_resume 中的工作懸置這是由 aqc111_suspend 呼叫其 write_cmd 常式的 PM 變體所造成。簡化的呼叫追踪如下所示：rpm_suspend() usb_suspend_both() - 此處為 udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - call for the usb 裝置介面 aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() -此處我們會呼叫父項 rpm_resume() 上的 rpm_resume() - 此處我們會等待永遠不會發生的狀態變更。此時我們封鎖了另一個保留 rtnl_lock 並鎖定整個網路堆疊的工作。將 write_cmd 呼叫取代為其 _nopm 變體以修正此問題 (CVE-2026-23446)

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

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

  - 已解決 Linux 核心中的下列弱點：ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] <TASK> [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ?
    __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] </TASK> [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated--- (CVE-2026-23428)

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

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

  - mtd： rawnand：針對其他 NAND 操作 nand_lock（） 和 nand_unlock（） 調用 chip->ops.lock_area/unlock_area 序列化鎖定/解鎖，而無需保持 NAND 裝置鎖定。在透過多個低階 PIO 命令實作SET_FEATURES的控制器上，這些命令可能會與並行 UBI/UBIFS 背景擦除/寫入操作爭用，從而導致 NAND 控制器上的 cmd_pending 衝突。在鎖定/解鎖作業周圍新增 nand_get_device（）/nand_release_device（），以針對所有其他 NAND 控制器存取進行序列化。（CVE-2026-23434）

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

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

  - cryptoatmel-sha204a - 修正 OOM ->tfm_count 洩漏如果記憶體配置失敗請遞減 ->tfm_count 以避免封鎖未來的讀取。 (CVE-2026-31391)

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

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

  - OpenPrinting CUPS 是適用於 Linux 和其他類 Unix 作業系統的開放原始碼列印系統。在 2.4.16 版及更舊版本中，RSS 通知程式允許 notify-recipient-uri 中的路徑遊走 (例如 rss:///../job.cache)，進而讓遠端 IPP 用戶端在 CacheDir/rss 之外寫入 RSS XML 位元組 (lp-writable 的任何位置)。特別是，由於根據預設，CacheDir 為群組可寫入 (通常是 root:lp 和模式 0770)，因此通知程式 (以 lp 身分執行) 可透過 temp-file + rename() 取代 root 管理的狀態檔案。此概念驗證 (PoC) 會以 RSS XML 損毀 CacheDir/job.cache，並且在重新啟動 cupsd 後，排程器無法剖析工作快取，且先前排入佇列的工作會消失。發佈之時，尚無公開可用的修補程式。(CVE-2026-34978)

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

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

  - 已解決 Linux 核心中的下列弱點：dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ handler Commit 31a7a0bbeb00 (dpaa2-switch: add bounds check for if_id in IRQ handler) introduces a range check for if_id to avoid an out-of-bounds access. If an out-of-bounds if_id is detected, the interrupt status is not cleared. This may result in an interrupt storm. Clear the interrupt status after detecting an out-of-bounds if_id to avoid the problem. Found by an experimental AI code review agent at Google. (CVE-2026-23422)

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

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

  - netfilterctnetlink修正 ctnetlink_dump_exp_ct() 中的釋放後使用錯誤。ctnetlink_dump_exp_ct() 會針對 netlink 轉儲存回呼 ctnetlink_exp_ct_dump_table() 將 conntrack 指標儲存在 cb->data 中但在 netlink_dump_start() 之後立即中斷 conntrack 參照。當轉儲存跨越多個回合時第二個 recvmsg() 會觸發轉儲存回呼其會透過 nfct_help(ct) 將現已釋放的 conntrack 解除參照進而導致 ct->ext 發生釋放後使用。錯誤是 netlink_dump_control 沒有 .start 或 .done 回呼來管理轉儲存各輪次的 conntrack 參照。為此目的相同檔案中的其他轉儲存函式 (例如 ctnetlink_get_conntrack) 正確使用 .start/.done 回呼。新增在轉儲存期間保留和釋放 conntrack 參照的 .start 和 .done 回呼可修正此問題並在轉儲存回呼中的 cb->args[0] early-return 檢查後移動 nfct_help() 呼叫以避免不必要地解除參照 ct->ext。BUGKASAN在工作 ctnetlink_poc/133 CPU1 UID0 PID133 Commctnetlink_poc 未受污染的 7.0.0-rc2+ 中於 addr ffff88810597ebf0 讀取大小為 8 的 ctnetlink_exp_ct_dump_table+0x4f/0x2e0 中發生釋放後使用 7.0.0-rc2+ #3 PREEMPTLAZY 呼叫追踪 <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 由工作 133 分配 kmem_cache_alloc_noprof+0x134/0x440
    __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0:
    slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0 (CVE-2026-23458)

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

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

  - nvdimm/bus修正非同步初始化中可能發生的釋放後使用問題 Dingisoul with KASAN 報告 device_add() 在 nd_async_device_register() 中失敗時會發生釋放後使用。認可 b6eae0f61db2 (libnvdimm排程 async init 時保留父項上的參照) 已在父項裝置上正確新增一個參照直到完成非同步初始化為止。不過如果 device_add() 導致配置失敗則裝置的參照計數會在存取父項指標之前降至 0。因而導致釋放後使用。錯誤機器人 AI 正確識別該修正。儲存父項指標的參照以用於放置父項參照無論 device_add() 的結果為何。 (CVE-2026-31399)

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

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

  - NFSD延遲最後參照中斷時 (RCU 寬限期前) 在匯出放置回呼 svc_export_put() 中立即呼叫 path_put() 和 auth_domain_put()。e_show() 和 c_show() 中的 RCU 讀取程式在不保留參照的情況下同時存取 ex_path (透過 seq_path/d_path) 和 ex_client->name (透過 seq_escape)。如果 cache_clean 移除項目並同時中斷最後一個參照則會在仍在使用中釋放子物件進而在 d_path 中產生 NULL 指標解除參照。提交 2530766492ec (nfsd修正存取 ex_uuid 或 ex_stats 時的 UAF) 將 ex_uuid 和 ex_stats 的 kfree 移至 call_rcu 回呼但讓 path_put() 和 auth_domain_put() 在寬限期前執行因為可能會在 softirq 內容中休眠並執行 call_rcu 回呼。將 call_rcu/kfree_rcu 取代為 queue_rcu_work()將回呼延遲到 RCU 寬限期過後並在允許休眠的處理程序內容中執行。這允許將 path_put() 和 auth_domain_put() 移至其他資源釋放旁邊的延遲回呼中。將相同的修正套用至 expkey_put()其與 ek_path 和 ek_client 具有相同模式。專用的工作佇列將關機排出範圍僅限於 NFSD 匯出版本工作項目排清共用的 system_unbound_wq 會因來自其他子系統的不相關工作而停止。 nfsd_export_shutdown() 使用 rcu_barrier() 和 flush_workqueue()確保在匯出快取損毀前完成所有延遲的釋放回呼。修訂者：Jeff Layton <jlayton@kernel.org> (CVE-2026-31404)

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

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

  - nfsd修正 NFSv4.0 LOCK 重播快取中的堆積溢位 NFSv4.0 重播快取使用固定的 112 位元組內嵌緩衝區 (rp_ibuf[NFSD4_REPLAY_ISIZE]) 來儲存已編碼的作業回應。此大小是根據 OPEN 回應計算而未考量 LOCK 拒絕回應其中包含衝突鎖定擁有者作為最多 1024 位元組的變數長度欄位 (NFS4_OPAQUE_LIMIT)。當 LOCK 作業因為與擁有大型擁有者的現有鎖定衝突而遭拒絕時nfsd4_encode_operation() 會透過 read_bytes_from_xdr_buf() 將完整編碼的回應複製到尺寸過小的重播緩衝區中而無需進行邊界檢查。這會導致在超出緩衝區結尾處最多 944 位元組的平台超出邊界寫入進而損毀相鄰堆積記憶體。未經驗證的攻擊者可使用兩個合作的 NFSv4.0 用戶端遠端觸發此瑕疵一個使用大型擁有者字串設定鎖定另一個則要求衝突鎖定以引發拒絕。我們可以透過增加 NFSD4_REPLAY_ISIZE 來修正此問題以允許完全不透明但是這會增加每個狀態擁有者的大小而大多數鎖定擁有者並沒有那麼大。而是在復製到重播緩衝區之前檢查 NFSD4_REPLAY_ISIZE 的編碼回應長度以解決此問題。如果回應太大請將 rp_buflen 設為 0 以略過快取重播承載。其狀態仍在快取中且用戶端已收到針對原始要求的正確回應。 (CVE-2026-31402)

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

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

  - wifimac80211發生 ieee80211_tx_prepare_skb() 失敗時一律釋放 skb ieee80211_tx_prepare_skb() 具有三個錯誤路徑但其中只有兩個釋放 skb。第一個錯誤路徑 (傳回 TX_DROP 的 ieee80211_tx_prepare()) 不會釋放它但是 invoke_tx_handlers() 失敗和分割檢查兩者都會釋放。將 kfree_skb() 新增至第一個錯誤路徑使這三個路徑全部一致並移除呼叫端中現已多餘的釋放 (ath9k、mt76、mac80211_hwsim) 以避免重複釋放。在函式的 kdoc 中記錄 skb 擁有權保證。 (CVE-2026-23444)

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

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

  - netusbcdc_ncm新增 ndpoffset 至 NDP16 nframes 邊界檢查 cdc_ncm_rx_verify_ndp16() 會驗證 NDP 標頭及其 DPE 項目是否符合 skb。第一個檢查正確說明 ndpoffset
    if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len) 但是第二次檢查省略了 if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len) 這個會對照 skb 總長度驗證 DPE 陣列大小就像 NDP 位於位移 0 而非 ndpoffset 一樣。將 NDP 放置在 NTB (大 wNdpIndex) 的結尾附近時即使通過檢查DPE 項目仍可延伸超過 skb 資料緩衝區。然後cdc_ncm_rx_fixup() 會在反覆 DPE 陣列時讀取超出邊界的記憶體。將 ndpoffset 新增至 nframes 邊界檢查並使用 struct_size_t() 更清楚地表示 NDP-plus-DPE-array 大小。 (CVE-2026-23448)

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

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

  - Rack 是一種模組化的 Ruby Web 伺服器介面。從 3.2.0 版到 3.2.6之前的版本Rack::Multipart::Parser 會不正確地展開折疊的多部分標頭。當 multipart 標頭包含 obs-fold 序列時Rack 會保留剖析參數值 (例如檔案名稱或名稱) 中的內嵌 CRLF而不是在展開期間移除折疊的分行符號。因此之後在 HTTP 回應標頭中重複使用這些剖析值的應用程式可能容易受到下游標頭插入或回應分割的影響。此問題已在 3.2.6 版中修正。(CVE-2026-26962)

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

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

  - net/schedteql修正 teql_master_xmit 中的重複釋放問題每當 TEQL 裝置以未鎖定的 Qdisc 身分使用 root 時應使用 seq_lock 呼叫 qdisc_reset以避免與資料路徑爭用。否則可能會導致以下崩潰：[ 238.028993][ T318] BUG：KASAN：skb_release_data (net/core/skbuff.c:1139) 中出現雙重釋放 [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318 [238.029749][ T318] [ 238.029900][ T318] 任務 poc_teql_uaf_ke/318 釋放了位址 ffff88810c67ec00 [ CPU]未被污染 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] 硬體名稱：Bochs Bochs，BIOS Bochs 2011年1月1日 [ 238.029910][ T318] 呼叫追蹤：[ 238.029913][ T318] <TASK> [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122) [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029944][T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029989][T318] check_slab_allocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139) ... [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256) [ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827) [ 238.030039][T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034) [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077) [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091) [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556) ... [ 238.072958][ T318] 任務 303 在 CPU 5 上於 238.026275 秒分配：[ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369) [ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921) [238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318]
    __alloc_skb (net/core/skbuff.c:713) [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997) [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108 ) [ 238.081469][ T318] [ 238.081870][ T318] 已由 238.028496s 的 cpu 1 上的工作 299 釋放[ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58) [238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (判別器 5) mm/kasan/common.c:79 (判別器 5)) [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic .c:587 (辨別器 1)) [238.085900][ T318] __kasan_slab_free (mm/ ---truncated--- (CVE-2026-23449)

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

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

  - drm/xe開放程式碼 GGTT MMIO 存取保護 GGTT MMIO 存取目前受到熱插拔 (drm_dev_enter) 保護在驅動程式成功載入且之後解除系結或卸載時其可正確運作。不過如果驅動程式載入失敗此保護機制便不夠充分因為系統永遠不會呼叫 drm_dev_unplug()。此外devm 版本函式無法保證在移除 GGTT MMIO 區域之前具有 GGTT 對應的所有 BO 皆遭到損毀因為背景工作執行緒可能會非同步地釋放部分 BO。若要解決此問題請引入由 GGTT 鎖定保護的開放編碼旗標以保護 GGTT MMIO 存取。此旗標會在 dev_fini_ggtt devm 釋放函式期間遭到清除以確保在終止開始後停用 MMIO 存取。 (從認可 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431) (CVE-2026-23466)

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

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

  - spi修正統計資料配置。直到控制器使用驅動程式核心註冊之後才會配置控制器 per-cpu 的統計資料這會留下一個視窗在該視窗中存取 sysfs 屬性可觸發 NULL 指標解除參照。透過將統計資料配置移至控制器配置同時將其存留期與控制器的存留期 (而非使用隱含 devres) 來修正此問題。 (CVE-2026-23475)

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

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

  - drm/xe/configfs釋放 ctx_restore_mid_bb 記憶體中的 ctx_restore_mid_bb 版本在 wa_bb_store() 中配置但是 xe_config_device_release() 只會釋放 ctx_restore_post_bb。同時釋放 ctx_restore_mid_bb[0].cs 以避免在移除 configfs 裝置時洩漏配置。
    (從認可 a235e7d0098337c3f2d1e8f3610c719a589e115f 精選) (CVE-2026-23421)

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

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

  - net/mlx5e： 防止並行存取 IPSec ASO 環境定義 查詢或更新 IPSec 卸載物件是透過存取 ASO WQE。驅動程式會針對每個 PF 使用單一 mlx5e_ipsec_aso 結構，其中包含所有 ASO 作業的共用 DMA 對應內容。存在爭用情形，因為在硬體完成處理 WQE 之前釋放 ASO 微調鎖定。如果之後立即起始第二個作業，則會覆寫 DMA 區域中的共用內容。稍後處理第一個作業的完成時，它會讀取此損毀的內容，導致意外行為和不正確的結果。
    此認可會在每個 IPSec 卸載物件內引入私人內容來修正爭用。共用 ASO 內容現在會複製到此私有內容，同時保留 ASO 微調鎖定。後續處理會使用此已儲存的每個物件內容，以確保維護其完整性。（CVE-2026-23441）

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

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

  - sunrpc修正 cache_release 中的 cache_request 洩漏。當讀取器的檔案描述符號在讀取 cache_request (rp->offset != 0) 過程中關閉時cache_release() 會遞減要求的讀取器計數但從不檢查是否應釋放要求。在 cache_read() 中當讀取器減少至 0 且 CACHE_PENDING 清除時cache_request 會從佇列中移除並連同其緩衝區和 cache_head 參照一起釋放。 cache_release() 缺少此清理。釋放具有 reader == 0 之要求的其他唯一路徑是 cache_dequeue()但它只會在 CACHE_PENDING 從設定轉換為清除時執行。若在讀取器仍為非零時已發生轉換cache_dequeue() 將會略過要求且後續呼叫也不會將其清除。將 cache_read() 中的相同清理邏輯新增至 cache_release()讀取器遞減後檢查其是否達到 0 (清除 CACHE_PENDING 的情況)若為達到則將 cache_request 取消佇列並釋放。 (CVE-2026-31400)

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

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

  - SMB：用戶端：修正 Krb5 掛載（使用者名稱選項）客戶回報部分 krb5 掛載在單一伺服器時失敗，因為用戶端嘗試掛載錯誤的憑證。結果發現客戶端是在重複使用第一次掛載的 SMB 會話來嘗試掛載其他共享，儘管其他掛載被指定了不同的使用者名稱=選項。透過使用 username mount 選項搭配 sec=krb5 來搜尋 keytab 中的 principal，cifs.upcall（8） 自 cifs-utils-4.8 起已支援。所以即使用 Kerberos，也可以在 match_session（） 中匹配使用者名稱掛載選項來解決這個問題。例如，下面的第二個掛載在 -ENOKEY 時應該會失敗，因為 keytab（/etc/krb5.keytab）中沒有 'foobar' 原則。客戶端最後會重複使用第一個掛載的 SMB 會話來執行第二個掛載，這是錯誤的。''' $ ktutil ktutil： add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST： ktutil： write_kt /etc/krb5.keytab ktutil： quit $ klist -ke Keytab name：
    FILE：/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST （aes256-cts-hmac-sha1-96） $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5，username=testuser $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5，username=foobar $ mount -t cifs | grep -Po '\K\w+' testuser testuser ''' （CVE-2026-31392）

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

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

  - NFSD在 /proc/fs/nfs/exports fd 的存留期保留網路參照。/proc/fs/nfs/exports proc 項目是在模組初始化時建立並在模組的存留期持續存在。 exports_proc_open() 會擷取呼叫者目前的網路命名空間並將其 svc_export_cache 儲存在 seq->private 中但不會參照命名空間。如果隨後移除命名空間 (例如在 opener 對不同的命名空間執行 setns() 之後容器損毀)nfsd_net_exit() 會呼叫 nfsd_export_shutdown()其可釋放快取。在仍處於開啟狀態的 fd 上後續讀取會對已釋放的 cache_detail 執行遍歷已釋放的雜湊表。針對開啟檔案描述符號的存留期保留 struct net 上的參照。這可防止 nfsd_net_exit() 在任何匯出 fd 開啟時執行 -- 進而防止 nfsd_export_shutdown() 釋出快取。 cache_detail 已儲存其網路指標 (cd->net由 cache_create_net() 設定)因此 exports_release() 可擷取該指標而無需每個檔案的額外儲存空間。 (CVE-2026-31403)

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

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

  - spi：修正控制器註冊失敗時的免費使用（use-after-free）問題。確保在控制器註冊時，若每 CPU 統計分配失效，也要從驅動核心取消註冊，以避免驅動資源的自由使用後使用及未時鐘暫存器的存取。（CVE-2026-31389）

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

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

  - bnxt_en修正 DBG_BUF_PRODUCER 非同步事件處置程式中的 OOB 存取。bnxt_async_event_process() 中的 ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER 處置程式會直接使用韌體提供的「類型」欄位作為 bp->bs_trace[] 的索引而不進行邊界驗證。「type」欄位是從 DMA 對應的完成環記憶體擷取的 16 位元值其 NIC 會直接將其寫入主機 RAM。惡意或遭入侵的 NIC 可提供 0 到 65535 之間的任何值造成核心堆積記憶體越界存取。bnxt_bs_trace_check_wrap() 呼叫接著會解除參照 bs_trace->magic_byte 並寫入 bs_trace->last_offset 和 bs_trace->wrapped導致核心記憶體損毀或當機。透過新增邊界檢查並將 BNXT_TRACE_MAX 定義為 DBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 以涵蓋目前定義的所有韌體追踪類型 (0x0 到 0xc) 來修正。 (CVE-2026-31395)

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

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

  - 在 至 4.0.0版之前的 Mbed TLS 中存在編譯器引發的計時側通道 (在 RSA 和 CBC/ECB 解密中)只有 LLVM 的 select-optimize 功能才會發生。至 1.0.0 的TF-PSA-Crypto 也會受到影響。
    (CVE-2025-66442)

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

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

  - udp_tunnel修正 CONFIG_IPV6=n 時 udp_sock_create6 造成的 NULL 解除參照。當 CONFIG_IPV6 停用時udp_sock_create6() 函式會在未實際建立通訊端的情況下傳回 0 (成功)。然後 fou_create() 等呼叫端會解除參照未初始化的通訊端指標進而導致 NULL 指標解除參照。擷取的 NULL 解除參照損毀錯誤核心 NULL 指標解除參照解決
    0000000000000018 RIP 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] 呼叫追踪 <TASK> genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c 1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c: 1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (辨別器 1) net/ socket.c:742 (辨別器 1)) __sys_sendto (./include/linux/file.h:62 (辨別器 1) ./include/linux/file.h:83 (辨別器 1) net/socket.c:2183 (辨別器 1)) __x64_sys_sendto (net/socket.c:2213 (辨別器 1) net/socket.c:2209 (辨別器 1) net/socket.c:2209 (辨別器 1)) do_syscall_64 (arch/x86/entry/syscall_64. c:63 (辨別器 1) arch/x86/entry/syscall_64.c:94 (辨別器 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_6 4.S:130) 此修補程式會使 udp_sock_create6 改為傳回 -EPFNOSUPPORT因此呼叫者可正確採用其錯誤路徑。有弱點的函式只有一個呼叫者且只有有權限的使用者可觸發。 (CVE-2026-23439)

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

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

  - drm/xe/reg_sr修正 xa_store 失敗時的洩漏當 xa_store() 無法避免錯誤路徑上的記憶體洩漏時釋放新配置的項目。 v2使用 goto fail_free。(Bala) (從認可 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb) (CVE-2026-23418)

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

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

  - drm/i915/dmc修正在 DMC 尚未初始化且 dmc 因而為 NULL 時探查 intel_dmc_update_dc6_allowed_count() oops 不太可能發生的 NULL 指標解除參照。呼叫路徑為 intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() -> gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count() 時會發生上述情況因為 intel_power_domains_init_hw() 會在 *之前* intel_dmc_init() 被呼叫。不過gen9_set_dc_state() 會根據目前和目標 DC 狀態有條件地呼叫 intel_dmc_update_dc6_allowed_count()。探查時會停用目標但如果已啟用 DC6則會呼叫該函式並隨後發生 oops。顯然 DC6 在探查時不太可能啟用因為我們之前從未見過此失敗模式。在開機時啟用 DC6 也很奇怪因為這需要 DMC 韌體 (由 BIOS 載入)載入 DMC 韌體且驅動程式停止/重新程式設計韌體的 BIOS 是不當指定的序列因此不太可能是刻意的 BIOS 行為。BIOS 更有可能將一個意外啟用的 DC6 硬體狀態留下 (而實際上並未為此載入所需的 DMC 韌體)。只有在啟動/停止計數器取決於 _SW_ DC6 狀態與目前的 _HW_ DC6 狀態時才允許 DC6 計數器的追踪運作 (因為停止計數器需要在計數器啟動時擷取 DC5 計數器)。因此使用 HW DC6 狀態並不正確而且也會導致上述 oops。使用 SW DC6 狀態進行追踪修正這兩個問題。這是最初由 Jani 傳送的 v2 修正根據以下第一個 Link: 討論進行更新。 (從認可 2344b93af8eb5da5d496b4e0529d35f0f559eaf0 中精選出的內容) (CVE-2026-23467)

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

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

  - net/mlx5e：修正 IPSec ESN 更新期間的爭用情形 在 IPSec 完全卸載模式下，裝置會向驅動程式報告 ESN （擴充序號） 包裝事件。驅動程式會藉由查詢 IPSec ASO 並檢查 esn_event_arm 欄位是否0x0來驗證此事件，這表示已發生事件。處理事件之後，驅動程式必須將esn_event_arm設定回0x1，以重新武裝內容。此處理路徑中存在爭用情形。驗證事件之後，驅動程式會呼叫 mlx5_accel_esp_modify_xfrm（） 來更新核心的 xfrm 狀態。此函式會暫時釋放並重新取得 xfrm 狀態鎖定。因此，需要先將 esn_event_arm 設定為 0x1 來確認事件。
    如果硬體因其他原因傳送事件，這可防止驅動程式重新處理相同的 ESN 更新。由於下一次 ESN 更新只會在收到近 2^31 封包之後發生，因此不會有遺漏更新的風險，因為它會在此處理完成很久之後發生。處理事件兩次會導致 ESN 高階位元 （esn_msb） 不正確遞增。然後，驅動程式會使用此無效的 ESN 狀態對硬體進行程式設計，這會導致反重播失敗，並完全停止 IPSec 流量。在驗證 ESN 事件後，在呼叫 mlx5_accel_esp_modify_xfrm（） 之前立即重新布防 ESN 事件，以修正此問題。這可確保正確忽略任何虛假的重複事件，從而關閉爭用視窗。（CVE-2026-23440）

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

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

  - netfilternf_conntrack_h323修正 decode_int() CONS 案例中的 OOB 讀取。在 decode_int()CONS 案例中會呼叫 get_bits(bs, 2) 以讀取長度值然後在未檢查 len 位元組中是否還有剩餘的情況下呼叫 get_uint(bs, len)緩衝區。現有的邊界檢查只驗證 get_bits() 的 2 位元而不驗證 get_uint() 讀取的後續 1-4 位元組。這會允許格式錯誤的 H.323/RAS 封包造成 1-4 位元組 slab-out-of-bounds 讀取。在 get_bits() 之後get_uint() 之前針對 len 位元組新增邊界檢查。
    (CVE-2026-23456)

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

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

  - net： usb： cdc_ncm：將 ndpoffset 新增至 NDP32 nframes 邊界檢查 在先前修補程式中修正 NDP16 的相同邊界檢查錯誤也存在於 cdc_ncm_rx_verify_ndp32（） 中。DPE 陣列大小會根據 skb 總長度進行驗證，而不考慮 ndpoffset，因此當 放置在 NDP32 NTB 結尾附近時，允許越界讀取。將 ndpoffset 新增至 nframes 邊界檢查，並使用 struct_size_t（） 更清楚地表示 NDP 加 DPE 陣列大小。僅經過編譯測試。（CVE-2026-23447）

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

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

  - net： shaper：保護對階層的延遲讀取存取 我們在準備 Netlink 操作（預回呼）期間查找 netdev 並對其進行引用。然後，在回調的正文中，我們採用其鎖或 RCU，這是實際的保護。這是不合適的，從 ref 到鎖定的 netdev 的轉換必須包括活躍性檢查（檢查 netdev 是否尚未取消註冊）。修正讀取的案例 （RCU 下的案例）。寫入需要個別變更，以防止在排清已執行之後建立階層。（CVE-2026-23437）

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

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

  - 藍牙L2CAP在存取前驗證 L2CAP_INFO_RSP 承載長度 l2cap_information_rsp() 檢查 cmd_len 是否已修正 l2cap_info_rsp 標頭 (類型 + 結果、4 位元組)但接著在未驗證承載是否存在的情況下讀取 rsp->data- L2CAP_IT_FEAT_MASK 呼叫 get_unaligned_le32( rsp->data)其可讀取標頭之後的 4 個位元組 (需要 cmd_len >= 8)。- L2CAP_IT_FIXED_CHAN 讀取 rsp->data[0]超過標頭 1 個位元組 (需要 cmd_len >= 5)。結果 == L2CAP_IR_SUCCESS 的 L2CAP_INFO_RSP 截斷會觸發相鄰 skb 資料的超出邊界讀取。以必要的承載長度檢查保護每個資料存取。如果承載太短請略過讀取並讓狀態機器以安全的預設值完成 (feat_mask 和 remote_fixed_chan 仍保持來自 kzalloc 的零)如此資訊計時器清理和 l2cap_conn_start() 仍會執行且連線不會停止。 (CVE-2026-31393)

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

ID	名稱	嚴重性
304980	Linux Distros 未修補的弱點：CVE-2026-23426	medium
304979	Linux Distros 未修補的弱點：CVE-2026-23470	medium
304978	Linux Distros 未修補的弱點：CVE-2026-23452	medium
304977	Linux Distros 未修補的弱點：CVE-2026-23419	medium
304976	Linux Distros 未修補的弱點：CVE-2026-31396	high
304975	Linux Distros 未修補的弱點：CVE-2026-31394	medium
304974	Linux Distros 未修補弱點：CVE-2026-23450	critical
304973	Linux Distros 未修補的弱點：CVE-2026-26477	high
304972	Linux Distros 未修補的弱點：CVE-2026-23454	high
304971	Linux Distros 未修補弱點：CVE-2026-34980	medium
304970	Linux Distros 未修補的弱點：CVE-2026-23445	medium
304969	Linux Distros 未修補的弱點：CVE-2026-27447	medium
304968	Linux Distros 未修補的弱點：CVE-2026-23474	medium
304967	Linux Distros 未修補的弱點：CVE-2026-34979	medium
304966	Linux Distros 未修補的弱點：CVE-2026-23436	medium
304964	Linux Distros 未修補的弱點：CVE-2026-23469	medium
304963	Linux Distros 未修補的弱點：CVE-2026-31401	high
304962	Linux Distros 未修補的弱點：CVE-2026-34990	medium
304960	Linux Distros 未修補的弱點：CVE-2026-23446	medium
304959	Linux Distros 未修補弱點：CVE-2026-23428	high
304958	Linux Distros 未修補的弱點：CVE-2026-23434	medium
304957	Linux Distros 未修補的弱點：CVE-2026-31391	medium
304956	Linux Distros 未修補的弱點：CVE-2026-34978	medium
304955	Linux Distros 未修補的弱點：CVE-2026-23422	high
304954	Linux Distros 未修補的弱點：CVE-2026-23458	high
304933	Linux Distros 未修補的弱點：CVE-2026-31399	high
304932	Linux Distros 未修補的弱點：CVE-2026-31404	high
304931	Linux Distros 未修補的弱點：CVE-2026-31402	high
304930	Linux Distros 未修補的弱點：CVE-2026-23444	medium
304929	Linux Distros 未修補的弱點：CVE-2026-23448	high
304928	Linux Distros 未修補的弱點：CVE-2026-26962	medium
304927	Linux Distros 未修補的弱點：CVE-2026-23449	high
304926	Linux Distros 未修補的弱點：CVE-2026-23466	high
304925	Linux Distros 未修補的弱點：CVE-2026-23475	medium
304924	Linux Distros 未修補的弱點：CVE-2026-23421	medium
304923	Linux Distros 未修補的弱點：CVE-2026-23441	medium
304922	Linux Distros 未修補的弱點：CVE-2026-31400	medium
304921	Linux Distros 未修補的弱點：CVE-2026-31392	high
304920	Linux Distros 未修補的弱點：CVE-2026-31403	high
304919	Linux Distros 未修補的弱點：CVE-2026-31389	high
304918	Linux Distros 未修補的弱點：CVE-2026-31395	high
304917	Linux Distros 未修補的弱點：CVE-2025-66442	medium
304916	Linux Distros 未修補的弱點：CVE-2026-23439	medium
304915	Linux Distros 未修補的弱點：CVE-2026-23418	medium
304914	Linux Distros 未修補的弱點：CVE-2026-23467	medium
304913	Linux Distros 未修補的弱點：CVE-2026-23440	medium
304912	Linux Distros 未修補的弱點：CVE-2026-23456	high
304911	Linux Distros 未修補的弱點：CVE-2026-23447	high
304910	Linux Distros 未修補的弱點：CVE-2026-23437	medium
304909	Linux Distros 未修補的弱點：CVE-2026-31393	high

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

high

medium

critical

high

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

high

high

high

high

high

medium

high

medium

high

high

medium

medium

medium

medium

high

high

high

high

medium

medium

medium

medium

medium

high

high

medium

high