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

  - inetfrags排清 fqdir_pre_exit() 中的擱置 skbs 自 NIPA 的 9 月以來我們就發現 pernet_ops_rwsem 上偶爾出現鎖死情況。卡住的工作通常是 modprobe (通常會載入 ipvlan 之類的驅動程式)嘗試以寫入器的身分取得鎖定。 lockdep 未追踪 rwsems 的讀取器因此讀取在報告中並不明顯。進一步研究發現持有鎖定的 Reader 在 nf_conntrack_cleanup_net_list() 中會出現一個永遠的 conntrack 迴圈問題。根據過去 NIPA 偶爾當機的經驗我查看了當機前執行的測試發現 ip_defrag.sh 之後發生當機。立即出現的紅色旗標。Scouring thru (de)fragmentation 佇列會發現 skbs 閒置並保留 conntrack 參照。
    問題在於由於 conntrack 依賴 nf_defrag_ipv6因此會先載入 nf_defrag_ipv6。由於 nf_defrag_ipv6 會先載入因此其 netns 結束勾點會執行 _after_ conntrack 的 netns 結束勾點。在 fqdir_pre_exit() 期間排清所有片段佇列 SKB以便在 conntrack 清理執行前釋放 conntrack 參照。
    此外當計時器到期處置程式發現 fqdir->dead 已設定時也會排清處置程式中的佇列以防我們在執行 pre_exit 排清時封包偷偷進入。「修正」下的提交並非確切原因但我認為先前的計時器觸發最終會解除封鎖旋轉的 conntrack。 (CVE-2025-68768)

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

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

  - ipv6pskb_expand_head() 中的錯誤 () 屬於 calipso_skbuff_setattr() 的一部分。pskb_expand_head() 中存在一個由 net/core/skbuff.c:2232 的 BUG_ON(nhead < 0) 造成的核心 oops。當傳遞 skb_cow() 的空餘空間 > INT_MAX (即 (int)(skb_headroom(skb) + len_delta) < 0) 時會觸發此錯誤作為 calipso_skbuff_setattr() 常式的一部分。此錯誤的根本原因是 __skb_cow() 中的隱含整數轉換。檢查 (headroom > skb_headroom(skb)) 是為了確保 delta = headroom - skb_headroom(skb) 絕不為負值否則我們會在 pskb_expand_head() 中觸發 BUG_ON。不過如果 headroom > INT_MAX 且 delta <= -NET_SKB_PAD則檢查會通過該檢查會變成負值且 pskb_expand_head() 會收到 nhead 的負值。修正 calipso_skbuff_setattr() 中的觸發條件。藉由只使用 skb_cow() 來增加空餘空間以避免將負空餘空間大小傳遞至 calipso_skbuff_setattr() 內的 skb_cow()。PoC
    使用 `netlabelctl` 工具netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 然後執行下列 PoCint fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP ); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60 struct msghdr 訊息
    struct sockaddr_in6 dest_addr struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL
    msg.msg_iovlen = 0 msg.msg_control = cmsg; msg.msg_controllen = cmsg_len msg.msg_flags = 0 // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback dest_addr.sin6_scope_id = 31337 // 設定 cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6 cmsg->cmsg_type = IPV6_HOPOPTS char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9 //設定躍點大小 - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0); (CVE-2025-71085)

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

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

  - net: openvswitch修正 push_nsh() 動作中的中間屬性驗證 push_nsh() 動作結構如下所示 OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...)) 最外層的 OVS_ACTION_ATTR_PUSH_NSH 屬性由 __ovs_nla_copy_actions 內的 nla_for_each_nested() 執行()。
    最內層的 OVS_NSH_KEY_ATTR_BASE/MD1/MD2 由 nsh_key_put_from_nlattr() 內的 nla_for_each_nested() 驗證。但是沒有任何項目會檢查中間的屬性是否正常。我們甚至不檢查此屬性是否為 OVS_KEY_ATTR_NSH。我們只是透過一對 nla_data() 呼叫執行雙重解包裝 - 第一次是在呼叫 validate_push_nsh() 時直接第二次作為 nla_for_each_nested() 巨集的一部分執行此操作並不安全可能會造成無效的記憶體存取此屬性的 不正確。由於 netlink 緩衝區較大因此在驗證期間可能不會注意到失敗但稍後會在緩衝區完全分配給大小的動作執行期間造成問題
    BUGKASANnsh_hdr_from_nlattr+0x1dd/0x6a0 中的 slab 超出邊界 [openvswitch] 工作 a.out/22624 CPU 在 addr ffff88816459a634 讀取大小 184 CPU8 UID0 PID22624 6.18.0-rc7+ #115 PREEMPT(vulnerable) 呼叫追踪 <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0xsh+0x] push_switch_nsh+0x60 0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+ 0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> 讓我們新增一些檢查項目屬性大小是否適當且其為動作屬性內的唯一一個。從技術上來說OVS_KEY_ATTR_NSH 並沒有真正的原因存在因為我們知道我們已經推送 NSH 標頭它只會建立額外的巢狀但這就是今天 uAPI 的運作方式。因此，請維持原狀。 (CVE-2025-68785)

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

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

  - 已解決 Linux 核心中的下列弱點：bnxt_en: Fix XDP_TX path For XDP_TX action in bnxt_rx_xdp(), clearing of the event flags is not correct. __bnxt_poll_work() -> bnxt_rx_pkt()
    -> bnxt_rx_xdp() may be looping within NAPI and some event flags may be set in earlier iterations. In particular, if BNXT_TX_EVENT is set earlier indicating some XDP_TX packets are ready and pending, it will be cleared if it is XDP_TX action again. Normally, we will set BNXT_TX_EVENT again when we successfully call __bnxt_xmit_xdp(). But if the TX ring has no more room, the flag will not be set. This will cause the TX producer to be ahead but the driver will not hit the TX doorbell. For multi-buf XDP_TX, there is no need to clear the event flags and set BNXT_AGG_EVENT. The BNXT_AGG_EVENT flag should have been set earlier in bnxt_rx_pkt(). The visible symptom of this is that the RX ring associated with the TX XDP ring will eventually become empty and all packets will be dropped. Because this condition will cause the driver to not refill the RX ring seeing that the TX ring has forever pending XDP_TX packets. The fix is to only clear BNXT_RX_EVENT when we have successfully called __bnxt_xmit_xdp(). (CVE-2025-68770)

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

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

  - ipvs修正路由錯誤路徑中的 ipv4 null-ptr-deref。__ip_vs_get_out_rt() 中的 IPv4 程式碼路徑在未確保 skb->dev 已設定的情況下呼叫 dst_link_failure()導致 ipv4_link_failure() 嘗試時在 fib_compute_spec_dst() 中發生 NULL 指標解除參照傳送 ICMP 目的地無法連線訊息。
    此問題是在認可 ed0de45a1008 (ipv4重新編譯 ipv4_link_failure 中的 ip 選項) 開始從 ipv4_link_failure() 呼叫 __ip_options_compile() 後出現。此程式碼路徑最終會呼叫 fib_compute_spec_dst()其會解除參照 skb->dev。已嘗試修正認可 0113d9c9d1cc 中的 NULL skb->dev 解除參照 (ipv4修正 ipv4_link_failure 中的 null-deref)但透過使用遞補裝置僅能解決直接的 dev_net(skb->dev) 解除參照。修正並不完整因為呼叫鏈中稍後的 fib_compute_spec_dst() 仍會直接存取 skb->dev而這會在 IPVS 呼叫 dst_link_failure() 時維持 NULL。在下列情況下會發生當機 1. IPVS 在 NAT 模式下處理目的地設定錯誤的封包 2. 建立路由之前在 __ip_vs_get_out_rt() 中路由查閱失敗 3. 錯誤路徑以 skb->dev == NULL 呼叫 dst_link_failure(skb) 4 . ipv4_link_failure() ipv4_send_dest_unreach() __ip_options_compile() fib_compute_spec_dst() 5. fib_compute_spec_dst() 解除參照 NULL skb->dev 在認可 326bf17ea5d4 中套用用於 IPv6 的修正 (ipvs修正 ipv6 路由未連線錯誤)設定 skb->dev skb_dst(skb)->dev 前先呼叫 dst_link_failure()。KASAN範圍 [0x0000000000000328-0x000000000000032f] CPU 1 PID 12732 通訊 syz.1.3469 未受污染 6.6.114 #2 RIP0010:__in_dev_get_rcu include/linux/inetdevice.h:233 RIP
    0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285 呼叫追踪 <TASK> spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/v ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764 (CVE-2025-68813)

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

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

  - nfsd修正 nfsd4_add_rdaccess_to_wrdeleg() 中的 nfsd_file 參照洩漏。nfsd4_add_rdaccess_to_wrdeleg() 會無條件以新取得的 nfsd_file 覆寫 fp->fi_fds[O_RDONLY]。不過如果用戶端已有從前一個 OPEN 作業開啟的 SHARE_ACCESS_READ此動作會覆寫現有指標而不釋放其參照進而使先前的參照孤立。此外函式原本將相同的 nfsd_file 指標儲存在只有一個參照的 fp->fi_fds[O_RDONLY] 和 fp->fi_rdeleg_file 中。當 put_deleg_file() 執行時它會清除 fi_rdeleg_file 並呼叫 nfs4_file_put_access() 以釋放檔案。不過nfs4_file_put_access() 只會在 fi_access[O_RDONLY] 計數器降為零時釋放 fi_fds[O_RDONLY]。如果在檔案上存在另一個 READ 開啟則計數器仍會維持提升狀態且永遠不會釋放來自委派的 nfsd_file 參照。這可能會在該檔案上造成開放衝突。然後在伺服器關閉時這些洩漏造成 __nfsd_file_cache_purge() 遇到檔案參照計數較高且無法清除由於該快取中仍配置 nfsd_file 物件因此最終觸發 kmem_cache_destroy() 中的 BUG()。 (CVE-2025-71090)

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

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

  - mediadvb-usbdtv5100修正 dtv5100_i2c_msg() 中的超出邊界問題 rlen 值是使用者控制的值但是 dtv5100_i2c_msg() 不會檢查 rlen 值的大小。因此如果將其設定為大於 sizeof(st->data) 的值st->data 就會發生超出邊界弱點。因此我們需要新增適當的範圍檢查以防止此弱點發生。 (CVE-2025-68819)

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

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

  - mlxswspectrum_router修正鄰居釋放後使用我們解除參照鄰居 [1] 時有時會發現釋放後使用。問題似乎在於驅動程式儲存了一個指標鄰居但未保留其參照。只有在下一個躍點使用鄰居時才會採取參照。
    透過簡化參照計數配置來修正。在相鄰項目中儲存相鄰指標時一律採用參照。避免在下一個躍點使用鄰居時進行參照因為與下一個躍點相關聯的鄰居項目已持有參照。已執行未涵蓋問題的測試超過 300 次以進行測試。若未使用此修補程式數次重複此問題就會重現。 [1] 錯誤KASAN在 mlxsw_sp_neigh_entry_update+0x2d4/0x310 中發生釋放後使用問題 ip/3929 CPU3 UID0 PID3929 Commip 未受污染的 6.18.0- rc4-virtme-g36b21a067510 #3 PREEMPT(完整) 硬體名稱Nvidia SN5600/VMOD0013、BIOS 5.13 2023 年 5 月 31 日 呼叫追踪 <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+ 0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130
    __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100
    __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg +0x75b/0xc90 __sock_sendmsg+0xbe/0x160____sys_sendmsg+0x5b2/0x7d0
    ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...] Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0
    ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread +0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 已由工作 154 釋放
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60
    __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 Last可能相關的工作建立
    kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 (CVE-2025-68801)

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

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

  - 輸入ti_am335x_tsc - 修正 wire_order 驗證中的差一錯誤。目前的驗證「wire_order[i] > ARRAY_SIZE(config_pins)」允許 wire_order[i] 等於 ARRAY_SIZE(config_pins)而這在做為 'config_pins[wire_order[i]]' 中的索引使用。由於 config_pins 有 4 個元素 (索引 0-3)因此 wire_order 的有效範圍應為 0-3。修正差一錯誤方法為在驗證檢查中使用 >= 而非 >。 (CVE-2025-68777)

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

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

  - 已解決 Linux 核心中的下列弱點：fuse: fix readahead reclaim deadlock Commit e26ee4efbc79 (fuse: allocate ff->release_args only if release is needed) skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim: >>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27 Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()). (CVE-2025-68821)

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

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

  - 已解決 Linux 核心中的下列弱點：net/sched: ets: Always remove class from active list before deleting in ets_qdisc_change zdi-disclosures@trendmicro.com says: The vulnerability is a race condition between `ets_qdisc_dequeue` and `ets_qdisc_change`. It leads to UAF on `struct Qdisc` object. Attacker requires the capability to create new user and network namespace in order to trigger the bug. See my additional commentary at the end of the analysis. Analysis: static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack) { ... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc);
    } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active);
    q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0);
    q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats);
    memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0; } Comment: This happens because some of the classes have their qdiscs assigned to NULL, but remain in the active list. This commit fixes this issue by always removing the class from the active list before deleting and freeing its associated qdisc Reproducer Steps (trimmed version of what was sent by zdi-disclosures@trendmicro.com) ``` DEV=${DEV:-lo} ROOT_HANDLE=${ROOT_HANDLE:-1:} BAND2_HANDLE=${BAND2_HANDLE:-20:} # child under 1:2 PING_BYTES=${PING_BYTES:-48} PING_COUNT=${PING_COUNT:-200000} PING_DST=${PING_DST:-127.0.0.1} SLOW_TBF_RATE=${SLOW_TBF_RATE:-8bit} SLOW_TBF_BURST=${SLOW_TBF_BURST:-100b} SLOW_TBF_LAT=${SLOW_TBF_LAT:-1s} cleanup() { tc qdisc del dev $DEV root 2>/dev/null } trap cleanup EXIT ip link set $DEV up tc qdisc del dev $DEV root 2>/dev/null || true tc qdisc add dev $DEV root handle $ROOT_HANDLE ets bands 2 strict 2 tc qdisc add dev $DEV parent 1:2 handle $BAND2_HANDLE \ tbf rate $SLOW_TBF_RATE burst $SLOW_TBF_BURST latency $SLOW_TBF_LAT tc filter add dev $DEV parent 1:
    protocol all prio 1 u32 match u32 0 0 flowid 1:2 tc -s qdisc ls dev $DEV ping -I $DEV -f -c $PING_COUNT -s $PING_BYTES -W 0.001 $PING_DST \ >/dev/null 2>&1 & tc qdisc change dev $DEV root handle $ROOT_HANDLE ets bands 2 strict 0 tc qdisc change dev $DEV root handle $ROOT_HANDLE ets bands 2 strict 2 tc -s qdisc ls dev $DEV tc qdisc del dev $DEV parent ---truncated--- (CVE-2025-71066)

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

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

  - fsnotify不在特殊檔案的子項目上產生 ACCESS/MODIFY 事件 inotify/fanotify 不允許對檔案沒有讀取存取權的使用者訂閱事件 (例如 IN_ACCESS/IN_MODIFY)但會允許相同使用者訂閱當使用者可存取父目錄 (例如 /dev) 時監視子項目的事件。對檔案沒有讀取存取權但對其父目錄具有讀取存取權的使用者仍可統計檔案並查看其是否已透過 atime/mtime 變更存取/修改。特殊檔案 (例如 /dev/null) 的情況並非如此。其他使用者讀取/寫入特殊檔案時使用者通常不會觀察到 atime/mtime 變更只有在有人透過 utimensat() 設定 atime/mtime 時才會如此。使 fsnotify 事件與此 stat 行為一致並且在讀取/寫入特殊檔案時不產生父項監看程式的 ACCESS/MODIFY 事件。事件仍會產生至 utimensat() 上的父項監看程式。這會關閉一些可能用於資訊洩漏的側通道 [1]。 [1] https://snee.la/pdf/pubs/file-notification-attacks.pdf (CVE-2025-68788)

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

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

  - 已解決 Linux 核心中的下列弱點：RDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats() Commit ef56081d1864 (RDMA/bnxt_re: RoCE related hardware counters update) added three new counters and placed them after BNXT_RE_OUT_OF_SEQ_ERR. BNXT_RE_OUT_OF_SEQ_ERR acts as a boundary marker for allocating hardware statistics with different num_counters values on chip_gen_p5_p7 devices. As a result, BNXT_RE_NUM_STD_COUNTERS are used when allocating hw_stats, which leads to an out-of-bounds write in bnxt_re_copy_err_stats(). The counters BNXT_RE_REQ_CQE_ERROR, BNXT_RE_RESP_CQE_ERROR, and BNXT_RE_RESP_REMOTE_ACCESS_ERRS are applicable to generic hardware, not only p5/p7 devices. Fix this by moving these counters before BNXT_RE_OUT_OF_SEQ_ERR so they are included in the generic counter set.
    (CVE-2025-71092)

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

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

  - 已解決 Linux 核心中的下列弱點：platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing The hp_populate_*_elements_from_package() functions in the hp-bioscfg driver contain out-of-bounds array access vulnerabilities. These functions parse ACPI packages into internal data structures using a for loop with index variable 'elem' that iterates through enum_obj/integer_obj/order_obj/password_obj/string_obj arrays. When processing multi-element fields like PREREQUISITES and ENUM_POSSIBLE_VALUES, these functions read multiple consecutive array elements using expressions like 'enum_obj[elem + reqs]' and 'enum_obj[elem + pos_values]' within nested loops. The bug is that the bounds check only validated elem, but did not consider the additional offset when accessing elem + reqs or elem + pos_values. The fix changes the bounds check to validate the actual accessed index.
    (CVE-2025-71101)

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

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

  - ntfs掛載時設定虛擬區塊大小以讀取 boot_block。當掛載時sb->s_blocksize 會用於在未定義或驗證的情況下讀取 boot_block。在嘗試讀取 boot_block 之前設定虛擬區塊大小。此問題可透過下列 syz 播放器觸發mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4 0x40081271、&(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb、&(0x7f0000000040)='./cgroup\x00'、&(0x7f0000000000)='ntfs3\x00'、08004、0x022 syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0) 在這裡ioctl 將 bdev 區塊大小設定為 16384。在掛載期間get_tree_bdev_flags() 呼叫 sb_set_blocksize(sb, block_size(bdev))但是因為 block_size(bdev) > PAGE_SIZEsb_set_blocksize() 會將 sb->s_blocksize 保留為零。之後ntfs_init_from_boot() 會在 sb->s_blocksize 仍為零時嘗試讀取 boot_block而這會觸發該錯誤。
    [almaz.alexandrovich@paragon-software.com變更註解樣式新增傳回值處理] (CVE-2025-71067)

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

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

  - f2fswhiteout 建立失敗時的 dentry 快取失效 F2FS 可以掛載具有損毀目錄深度值的檔案系統其在運行時間中會被限制為 MAX_DIR_HASH_DEPTH。當在此類目錄上執行 RENAME_WHITEOUT 作業時f2fs_rename 會先執行目錄修改 (更新目標項目和刪除來源項目)然後再嘗試透過 f2fs_add_link 新增 whiteout 項目。如果 f2fs_add_link 因目錄結構損毀而失敗該函式會將錯誤傳回至 VFS但部分目錄修改已提交至磁碟。VFS 假設整個重新命名作業失敗且不會更新 dentry 快取而留下過時對應。在錯誤路徑中VFS 未呼叫 d_move() 來更新 dentry 快取。這導致 new_dentry 仍指向 i_nlink 遞減為零的舊 inode (new_inode)。過時的快取造成後續作業不正確地參照釋出的 inode。這會造成後續作業使用不再符合磁碟上狀態的快取 dentry 資訊。當第二次重新命名以相同的項目為目標時VFS 會嘗試遞減過時 inode (可能已有 i_nlink=0) 上的 i_nlink進而在 drop_nlink() 中觸發警告。範例序列1. 首先重新命名 (RENAME_WHITEOUT)file2 file1 - f2fs 更新磁碟上的 file1 項目 (指向 inode 8) - f2fs 刪除磁碟上的 file2 項目 - f2fs_add_link(whiteout) 失敗 (目錄損毀) - 將錯誤傳回至 VFS - VFS因為錯誤未呼叫 d_move() - VFS 快取仍有 file1 inode 7 (過時!) - inode 7 有 i_nlink=0 (已遞減) 2. 第二次重新命名 file3 file1 - VFS 使用過時快取 file1 inode 7 -嘗試在 inode 7 上進行 drop_nlink (i_nlink 已經是 0) - drop_nlink() 中的警告在白名單建立期間 f2fs_add_link 失敗時明確地使 old_dentry 和 new_dentry 無效。方法是明確地作廢 old_dentry 和 new_dentry。這會強制 VFS 在進行後續作業時從磁碟重新整理即使部分重新命名成功仍可確保快取一致性。Reproducer1. 以損毀的 i_current_depth 掛載 F2FS 影像 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. 系統在 drop_nlink() 中觸發警告 (CVE-2025-71069)

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

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

  - f2fs修正 f2fs_recover_fsync_data() 的傳回值使用下列指令碼時會在 f2fs 中觸發錯誤
    mkfs.f2fs -f /dev/vdd mount /dev/vdd /mnt/f2fs touch /mnt/f2fs/foo sync echo 111 >> /mnt/f2fs/foo f2fs_io fsync /mnt/f2fs/foo f2fs_io shutdown 2 /mnt/ f2fs umount /mnt/f2fs mount -o ro,norecovery /dev/vdd /mnt/f2fs or mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs F2FS-fs (vdd)f2fs_recover_fsync_data
    復原 fsync 資料 check_only: 0 F2FS-fs (vdd)使用檢查點版本 = 7f5c361f 掛載 F2FS-fs (vdd)因原因而停止檔案系統 0 F2FS-fs (vdd)f2fs_recover_fsync_data復原 fsync 資料 check_only檔案系統 f2fs get_tree() 未設定 fc->root 傳回 1 ------------[在此剪切]------------ fs/super 的核心錯誤.c:1761! Oops無效 opcode0000 [#1] SMP PTI CPU3 UID0 PID
    722 Commmount 未受污染的 6.18.0-rc2+ #721 PREEMPT(自發) 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.16.3-debian-1.16.3-2 2014 年 4 月 1 日 RIP 0010:vfs_get_tree.cold+0x18/0x1a 呼叫追踪
    <TASK> fc_mount+0x13/0xa0 path_mount+0x34e/0xc50 __x64_sys_mount+0x121/0x150 do_syscall_64+0x84/0x800 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fa6cc126cfe 當根本原因是我們遺漏了掛載影像時無法處理從 f2f 掛載的問題 () 傳回了錯誤 number_sync 資料若具有 ro,norecovery 或 ro,disable_roll_forward 掛載選項會導致將正錯誤數傳回 vfs_get_tree()修正此問題。 (CVE-2025-68769)

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

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

  - 已解決 Linux 核心中的下列弱點：shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir;
    the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout(). (CVE-2025-71072)

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

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

  - ipv4使用含有 nexthop 物件的錯誤路由時修正參照計數洩漏。nexthop 物件遭到刪除時系統會將其標記為無作用然後呼叫 fib_table_flush() 以排清使用無作用 nexthop 的所有路由。fib_table_flush() 的目前邏輯只會在網路命名空間卸除 (亦即 flush_all=true) 過程中呼叫它時排清錯誤路由 (如 blackhole)。因此刪除錯誤路由的 nexthop 物件時不會排清錯誤路由# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1 因此它們會持續保留 nexthop 物件的參照而 nexthop 物件會保留 nexthop 裝置上的參照導致參照計數洩漏 # ip link del dev dummy1 [ 70.516258] unregister_netdevice等待 dummy1 變為可用。使用量計數 = 2 透過在錯誤路由的 nexthop 標記為無作用時排清錯誤路由來修正。IPv6 不會受到此問題影響。 (CVE-2025-71097)

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

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

  - netrose修正 rose_kill_by_device() 中的無效陣列索引 rose_kill_by_device() 會將通訊端收集到本機陣列 []然後重複使用這些通訊端以中斷系結至即將關閉之裝置的通訊端。迴圈錯誤地索引 array[cnt] 而非 array[i]。針對 cnt < ARRAY_SIZE(陣列)這會讀取未初始化的項目若為 cnt == ARRAY_SIZE(陣列)則為超出邊界讀取。這兩種情況皆可導致無效的通訊端指標解除參照且也會洩漏透過 sock_hold() 取得的參照。修正索引以使用 i。 (CVE-2025-71086)

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

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

  - ksmbdvfs修正 vfs_cache 中 m_flags 的爭用 ksmbd 在 ksmbd_inode->m_flags 中維護關閉時刪除和擱置刪除狀態。在 vfs_cache.c 中此欄位是在不一致的鎖定下存取部分路徑會讀取並修改 ci->m_lock 下的 m_flags而另一些則完全不採取鎖定來進行此操作。範例- ksmbd_query_inode_status() 和 __ksmbd_inode_close() 在檢查或更新 m_flags 時使用 ci->m_lock。 - ksmbd_inode_pending_delete()、ksmbd_set_inode_pending_delete()、ksmbd_clear_inode_pending_delete() 和 ksmbd_fd_set_delete_on_close() 用來在沒有 ci->m_lock 的情況下讀取和修改 m_flags。當多個執行緒同時開啟、關閉和刪除相同檔案時這會在 m_flags 上造成潛在的資料爭用。在最壞的情況下，delete-on-close 和 pending-delete 位元可能會遺失或觀察到不一致的狀態，從而導致混淆刪除語意 (關閉時刪除後仍保留在磁碟上的檔案，或仍在使用中時消失的檔案) )。修正方法為 - 在放置 inode_hash_lock 之後讓 ksmbd_query_inode_status() 查看 ci->m_lock 下的 m_flags。- 新增 ci->m_lock 保護至所有讀取或修改 m_flags (ksmbd_inode_pending_delete()、ksmbd_set_inode_pending_delete()、ksmbd_clear_inode_pending_delete()、ksmbd_fd_set_delete_on_close()) 的協助程式。- 保留 __ksmbd_inode_close() 中現有的 ci->m_lock 保護並將實際的 unlink/xattr 移除作業移至鎖定之外。這會統一 m_flags 的鎖定並移除資料爭用同時保留現有的 delete-on-close 行為。 (CVE-2025-68809)

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

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

  - 已解決 Linux 核心中的下列弱點：io_uring: fix filename leak in
    __io_openat_prep() __io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak. Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.
    (CVE-2025-68814)

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

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

  - 輸入alps - 修正 dev3_register_work 造成的釋放後使用錯誤。dev3_register_work 延遲的工作項目會在 alps_reconnect() 內初始化並在從連線至 ALPS 觸控板的外部 PS/2 裝置收到第一個 PS/2 封包時排程。在裝置卸離期間原始實作會呼叫 psmouse_disconnect() 中的 flush_workqueue()以確保完成 dev3_register_work。
    不過psmouse_disconnect() 中的 flush_workqueue() 只會封鎖並等候在叫用之前已排入工作佇列的工作項目。呼叫 flush_workqueue() 後提交的所有工作項目不包含在排清作業等候的工作集中。這表示 flush_workqueue() 完成執行後仍可排程 dev3_register_work。雖然在 psmouse_disconnect() 中將 psmouse 狀態設定為 PSMOUSE_CMD_MODEdev3_register_work 的排程仍不受影響。可能會發生如下爭用情形CPU 0 (清理路徑) | CPU 1 (延遲工作) psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // 使用 | priv->dev3 // USE 在 alps_disconnect() 中新增 disable_delayed_work_sync()確保在解除配置 alps_data 結構後正確取消 dev3_register_work 並防止執行。此錯誤是由靜態分析所發現。 (CVE-2025-68822)

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

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

  - 已解決 Linux 核心中的下列弱點：media: vidtv: initialize local pointers upon transfer of memory ownership vidtv_channel_si_init() creates a temporary list (program, service, event) and ownership of the memory itself is transferred to the PAT/SDT/EIT tables through vidtv_psi_pat_program_assign(), vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign(). The problem here is that the local pointer where the memory ownership transfer was completed is not initialized to NULL. This causes the vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and in the flow that jumps to free_eit, the memory that was freed by vidtv_psi_*_table_destroy() can be accessed again by vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it is freed once again. Therefore, to prevent use-after-free and double-free vulnerability, local pointers must be initialized to NULL when transferring memory ownership. (CVE-2025-68808)

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

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

  - React Router 是一個適用於 React 的路由器。在 6.0.0 至 6.30.1 和 7.0.0 至 7.9.5版本中攻擊者可特製攻擊者提供的路徑當 React Router 應用程式透過 Navigation()、 <Link>或 redirect() 導覽至該路徑時該應用程式會執行導覽/redirect 至外部 URL。只有在您將未受信任的內容傳遞至應用程式程式碼中的導覽路徑時才會發生此問題。此問題已在 6.30.2、7.9.6 和 CVE-2025-68470 版本中修正。

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

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

  - 已解決 Linux 核心中的下列弱點：net: usb: asix: validate PHY address before use The ASIX driver reads the PHY address from the USB device via asix_read_phy_addr(). A malicious or faulty device can return an invalid address (>= PHY_MAX_ADDR), which causes a warning in mdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76 Validate the PHY address in asix_read_phy_addr() and remove the now-redundant check in ax88172a.c. (CVE-2025-71094)

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

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

  - 已解決 Linux 核心中的下列弱點：ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RT On PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, the current task can be preempted. Another task running on the same CPU may then execute rt6_make_pcpu_route() and successfully install a pcpu_rt entry. When the first task resumes execution, its cmpxchg() in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longer NULL, triggering the BUG_ON(prev). It's easy to reproduce it by adding mdelay() after rt6_get_pcpu_route(). Using preempt_disable/enable is not appropriate here because ip6_rt_pcpu_alloc() may sleep. Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT: free our allocation and return the existing pcpu_rt installed by another task.
    The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RT kernels where such races should not occur.
    (CVE-2025-71080)

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

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

  - 輸入lkkbd - 透過 schedule_work() 釋放裝置 lkkbd_interrupt() 排程 lk->tq 前停用擱置的工作且工作處置程式 lkkbd_reinit() 解除參照 lkkbd 結構及其 serio/input_dev 欄位。 lkkbd_disconnect() 和 lkkbd_connect() 中的錯誤路徑釋放 lkkbd 結構時沒有阻止 reinit 工作再次排入佇列直到 serio_close() 傳回為止。這可允許工作處置程式在釋放結構後執行進而導致可能的釋放後使用。使用 disable_work_sync() 而非 cancel_work_sync()確保 reinit 工作無法重新排入佇列並在 lkkbd_disconnect() 和 lkkbd_connect() 錯誤路徑中 (serio_open() 之後) 呼叫它。 (CVE-2025-71073)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/amdgpu: fix a job->pasid access race in gpu recovery Avoid a possible UAF in GPU recovery due to a race between the sched timeout callback and the tdr work queue. The gpu recovery function calls drm_sched_stop() and later drm_sched_start().
    drm_sched_start() restarts the tdr queue which will eventually free the job. If the tdr queue frees the job before time out callback completes, the job will be freed and we'll get a UAF when accessing the pasid. Cache it early to avoid the UAF. Example KASAN trace: [ 493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323 [ 493.074892] [ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary) [ 493.076493] Tainted:
    [E]=UNSIGNED_MODULE [ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019 [ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] [ 493.076512] Call Trace: [ 493.076515] <TASK> [ 493.076518] dump_stack_lvl+0x64/0x80 [ 493.076529] print_report+0xce/0x630 [493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0 [ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.077253] kasan_report+0xb8/0xf0 [493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu] [ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu] [ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu] [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu] [ 493.080903] ? pick_task_fair+0x24e/0x330 [ 493.080910] ?
    __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu] [ 493.081702] ? _raw_spin_lock+0x75/0xc0 [ 493.081708] ?
    __pfx__raw_spin_lock+0x10/0x10 [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched] [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 493.081725] process_one_work+0x679/0xff0 [ 493.081732] worker_thread+0x6ce/0xfd0 [ 493.081736] ? __pfx_worker_thread+0x10/0x10 [ 493.081739] kthread+0x376/0x730 [ 493.081744] ? __pfx_kthread+0x10/0x10 [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 493.081751] ?
    __pfx_kthread+0x10/0x10 [ 493.081755] ret_from_fork+0x247/0x330 [ 493.081761] ? __pfx_kthread+0x10/0x10 [493.081764] ret_from_fork_asm+0x1a/0x30 [ 493.081771] </TASK> (cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d) (CVE-2025-68793)

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

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

  - 已解決 Linux 核心中的下列弱點：ext4: xattr: fix null pointer deref in ext4_raw_inode() If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc(). Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-68820)

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

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

  - charapplicom修正 ac_ioctl 中的 NULL 指標解除參照由 Atuin - Automated Vulnerability Discovery Engine 發現。在 ac_ioctl 中cmd 為 6 時系統會略過 IndexCard 的驗證和有效的 RamIO 指標檢查。不過該函式會在結尾無條件執行 readb(apbs[IndexCard].RamIO + VERS)。如果 cmd 為 6IndexCard 可能會參照不存在的面板 (其中 RamIO 為 NULL)導致 NULL 指標解除參照。透過在 cmd 為 6 時略過 readb 存取來修正此命令是全域資訊查詢且不以特定的 board 內容為目標。 (CVE-2025-68797)

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

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

  - mptcp在同步連線上較早地遞補Syzkaller 報告同步連線爭用導致遞補狀態不一致 警告 net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow 的 CPU: 3 PID: 33。 c:1515 模組連結於 CPU3 UID0 PID33 Comm
    ksoftirqd/3 未受污染的 syzkaller #0 PREEMPT(full) 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.16.3-debian-1.16.3-2~bpo12+1 2014 年 4 月 1 日 RIP 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 程式碼89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX:
    ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12:
    ffff88802ba69900 R131ffff920000d9e67 R14ffff888046f81800 R150000000000000004 FS
    0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0
    0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: <TASK> tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197 tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922 tcp_v6_do_rcv+0x492/0x1740 net/ ipv6/tcp_ipv6.c:1672 tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918 ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1e4/0x4b0 net/ipvNF6_HOOKinput_c44 include/linux/netfilter.h:318 [內嵌] NF_HOOK include/linux/netfilter.h:312 [內嵌] ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500 dst_input include/net/dst.h:471 [內嵌] ip6_rcv_finish net/ipv6/ip6_input.c:79 [內嵌] NF_HOOK include/linux/netfilter.h:318 [內嵌] NF_HOOK include/linux/netfilter.h:312 [內嵌] ipv6_rcv+0x264/0x650 net/ipv6/ ip6_input.c:311 __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979
    __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092 process_backlog+0x442/0x15e0 net/core/dev.c:6444
    __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494 napi_poll net/core/dev.c:7557 [內嵌] net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684 handle_softirqs+0x216/0x8e0 kernel/softirq.c:579 run_ksoftirqd kernel/softirq.c:968 [內嵌] run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread .c:463 ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> TCP 子流程可以處理 simult-connect syn-ack轉換至 TCP_FIN1 狀態後的封包繞過 MPTCP 遞補檢查因為不會針對 * -> FIN_WAIT1 轉換叫用 sk_state_change() 回呼。這會將 msk 通訊端移至不一致的狀態且下一個傳入資料將會命中報告的展開。儘早解決移動 simult-fallback 檢查的爭用階段 - 即產生 syn-ack 時。關於修正標籤 [2] 應該也修正了這個由 [3] 引入的問題。需要 [1] 做為相依性其並未明確標記為修正但確實是一個修正而且在 [3] 之前就已反向移植。換言之此認可應最多反向移植至 [3]包括 [2] 和 [1] (若該處尚不存在)。 (CVE-2025-71088)

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

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

  - iommu設定 CONFIG_X86 時停用 SVA 修補程式系列 修正核心位址空間的過時 IOTLB 項目v7。這會針對與 IOMMU 共用虛擬定址 (SVA) 相關的一個安全性弱點提出修正。在 SVA 內容中IOMMU 可以快取核心頁面表格項目。當釋放核心頁面表格頁面並重新配置用於其他目的時IOMMU 可能仍保留過時、不正確的項目。攻擊者可惡意利用此問題造成釋放後使用或釋放後寫入情形進而可能導致權限提升或資料損毀。此解決方案引入了適用於核心頁面表格頁面的延遲釋放機制其提供安全視窗來通知 IOMMU使其快取無效然後再重複使用頁面。此修補程式 (共 8 個)在 IOMMU 共用虛擬定址 (SVA) 內容中IOMMU 硬體會共用並遍歷 CPU 的頁面表格。x86 架構會將核心的虛擬位址空間對應至每個處理程序頁面表格的上方部分。因此在 SVA 內容中IOMMU 硬體可以遍歷和快取核心頁面表格項目。Linux 核心目前缺少核心頁面表格變更的通知機制特別是在釋放和重複使用頁面表格頁面時。IOMMU 驅動程式只會收到使用者虛擬位址對應變更的通知。這可造成 IOMMU 的內部快取為核心 VA 保留過時項目。釋放核心頁面表格頁面但之後又重新配置時會出現釋放後使用 (UAF) 和釋放後寫入 (WAF) 情形。IOMMU 可將新資料錯誤解譯為有效的頁面表格項目。然後 IOMMU 可能會深入受攻擊者控制的記憶體進而導致任意實體記憶體 DMA 存取或權限提升。這也是一個釋放後寫入問題因為 IOMMU 在嘗試遍歷過時頁面表格時可能會繼續將已存取和已變更位元寫入釋放的記憶體。目前SVA 內容無權限無法存取核心對應。不過IOMMU 仍會一直遍歷僅限核心的分頁表直到分頁項目在該分頁項目中它會意識到對應是針對核心而輸出錯誤。這表示 IOMMU 仍會快取這些中繼頁面表格項目造成上述弱點成為真正的問題。停用 x86 架構上的 SVA直到 IOMMU 可收到通知以排清分頁快取然後再釋放 CPU 核心頁面表格頁面。 (CVE-2025-71089)

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

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

  - Fulcio 是一種憑證授權單位針對 OpenID Connect (OIDC) 身分發出程式碼簽署憑證。在 1.8.5之前的版本中Fulcio 的 metaRegex() 函式使用未錨定的 regex進而允許攻擊者繞過 MetaIssuer URL 驗證並觸發 SSRF 進入任意內部服務。由於 SSRF 只能觸發 GET 要求因此要求無法變動狀態。GET 要求的回應並未傳回給呼叫者因此不可能發生資料洩漏。惡意執行者可嘗試透過 Blind SSRF 探查內部網路。此弱點已在 1.8.5 中修復。(CVE-2026-22772)

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

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

  - functionfs修正 ffs_epfile_open() 可與移除發生的 open/removal 爭用進而導致 file->private_data 指向已釋放的物件。functionfs 上有已開啟檔案的總計數 (ep0 和動態檔案)且當其達到零時會移除動態檔案。遺憾的是當其他執行緒位於 ffs_epfile_open() 中但尚未增加計數時可能會發生移除作業。在此情況下open 會成功在後續的 read() 或 write() 中留下 UAF。根本原因是誤用 ffs->opened。當物件始終保持可見時atomic_dec_and_test() 與 atomic_add_return() 不是一個好主意。若要解開該問題 * 序列化 ffs->mutex 上的 opener (ep0 和動態檔案適用) * 讓動態項目使用 atomic_inc_not_zero()如果零 ->opened 則失敗如此一來我們開啟的檔案就會遭到破壞。 * 在移除時標記動態檔案的 inode (來自 simple_recursive_removal() 的回呼) - 清除 ->i_private 。 * 已開啟動態項目驗證其尚未移除以及檢查狀態是否為 FFS_ACTIVE。 (CVE-2025-71074)

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

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

  - iavf修正 iavf_config_rss_reg() 中的差一問題。設定 RSS 雜湊金鑰和查閱表格時有差一錯誤可造成記憶體 [1] 的超出邊界讀取和超出邊界寫入複製到裝置暫存器。在認可 43a3d9ba34c9 之前 (i40evf允許 PF 驅動程式設定 RSS)迴圈上限為 i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX 由於值為最後一個有效索引因此較為安全。該認可將邊界變更為 i <= Adapter->rss_{key,lut}_size / 4其中「rss_{key,lut}_size / 4」是 dword 的數量因此最後一個有效索引是「(rss_{ key,lut}_size / 4) - 1`. 因此使用 `<=` 會存取超出結尾的一個元素。修正使用 `<` 而非 `<=` 的問題確保我們不會超出邊界。 [1] KASAN 展開關於 rss_key_size 差一錯誤KASAN作業 kworker/u8:6/63 在 iavf_config_rss+0x619/0x800 中於位址 ffff888102c50134 讀取大小為 4 的 4 錯誤 CPU: 0 UID 0 PID63 通訊kworker/u8:6 未受污染 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(自發) 硬體名稱：QEMU Standard PC (Q35 + ICH9, 2009)、BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作佇列iavf iavf_watchdog_task 呼叫追踪 <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf iavf_watchdog_task 呼叫process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK> 由工作 63 配置
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90
    __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc -64 (大小為 64) 錯誤位址位於已配置之 52 位元組區域右側 0 位元組處 [ffff888102c50100, ffff888102c50134) 錯誤位址屬於下列實體頁面page: refcount:0 mapcount:0 mapping:0000000000000000 索引:0x0 pfn 0x102c50 flags 0x200000000000000(node=0|zone=2) page_type
    f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc ffff888102c50200fc fc fc fc fc fc fc fc fc fc fc fc fc (CVE-2025-71087)

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

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

  - 團隊修正 team_queue_override_port_prio_changed() 中啟用的連接埠檢查。最近報告了一個具有下列追踪的 syzkaller 錯誤list_del 損毀、ffff888058bea080->prev 為 LIST_POISON2 (dead000000000122) ------------[在此處截斷]------------ lib/list_debug.c:59! 的核心錯誤Oops無效 opcode0000 [#1] SMP KASAN NOPTI CPU3 UID0 PID21246 Commsyz.0.2928 未受污染的 syzkaller #0 PREEMPT(完整) 硬體名稱 QEMU Standard PC (Q35 + ICH9, 2009) 、BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 程式碼48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09:
     R100000000000000000  : 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 CR2000000110c3afcb0 CR3
    00000000382c7000 CR40000000000352ef0 呼叫追踪 <TASK> __list_del_entry_valid include/linux/list.h:132 [內嵌] __list_del_entry include/linux/list.h:223 [內嵌] list_del_rcu include/linux/rculist.h:178 [內嵌] __team_queue_override_port_del drivers /net/team/team_core.c:826 [內嵌]
    __team_queue_override_port_del drivers/net/team/team_core.c:821 [內嵌] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [內嵌] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net /team/team_core.c:376 [內嵌] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c 1195 [內嵌] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink /af_netlink.c:1320 [內嵌] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [內嵌] __sock_sendmsg 網路/socket.c:742 [內嵌]____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684
    __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 的問題處於此流程中1) 連接埠已啟用 queue_id != 0在 qom_list 中2) 連接埠已停用 -> team_port_disable() -> team_queue_override_port_del() -> del (已從清單中移除) 3) 連接埠已停用 queue_id != 0而非任何清單 4) 優先順序變更 -> team_queue_override_port_prio_changed() -> 檢查
    已停用連接埠 && queue_id != 0 -> 呼叫 del - 遇到錯誤因為該錯誤已移除。若要修正此問題請變更 team_queue_override_port_prio_changed() 中的檢查以便在未啟用連接埠的情況下提早傳回。
    (CVE-2025-71091)

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

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

  - powerpc/64s/slb修正 SLB 預先載入期間的 SLB 多次點擊問題。在使用雜湊 MMU 的系統上軟體 SLB 預先載入快取會鏡像載入至硬體 SLB 緩衝區的項目。此預先載入快取通常會在每執行 256 次內容切換以移除舊項目之後遭到定期收回。
    為了最佳化效能核心會在上一個和下一個 mm_struct 相同時略過 switch_mm_irqs_off() 中的 switch_mmu_context()。不過在雜湊 MMU 系統上這可導致硬體 SLB 和軟體預先載入快取之間的不一致。如果從某個 CPU 的軟體快取中收回某個處理程序的 SLB 項目而之後在另一個 CPU 上執行相同的處理程序卻未執行 switch_mmu_context()則硬體 SLB 可能會保留過時的項目。如果之後核心嘗試重新載入該項目可能會觸發 SLB 多次點擊錯誤。以下時間軸顯示過時 SLB 項目的建立方式以及當處理程序在沒有 MMU 內容切換的 CPU 之間移動時可造成多次點擊錯誤的方式。CPU 0 CPU 1 -----
    ----- Process P exec swapper/1 load_elf_binarybegin_new_exc active_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * 這會讓 HW * 中的所有項目失效* 並根據預先載入快取設定新的 HW * SLB 項目。 */ context_switch sched_migrate_task 將處理程序 P 移轉至 cpu-1 處理程序 swapper/0 內容切換 (至處理程序 P) (使用處理程序 P 的 mm_struct) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb 在這裡變成 0 *而且我們從以下項目收回項目 *以 * preload_age() 預先載入快取。我們仍 * 保持硬體 SLB 和預先載入 * 快取同步這是因為 * 因為在 SLBIA 期間所有硬體 SLB 項目 * 在 switch_slb 中都會被收回。 * 然後我們只會在 HW SLB 中重新新增那些 * 目前 * 存在於 preload_cache 中的項目 * (收回後)。 */ load_elf_binary 繼續...
    setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task 將處理程序 P 移轉至 cpu-0 context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * 由於上一個和下一個 mm 結構相同我們不呼叫 * switch_mmu_context()。這會造成硬體 SLB 和軟體預先載入 * 快取在 preload_new_slb_context 中不同步。因為有 * 有一個 SLB 項目從硬體和 cpu-1 上的預先載入快取中收回 *。現在稍後在 preload_new_slb_context() 中當我們* 再次嘗試新增相同的預先載入項目時我們會將其新增至 SW * 預先載入快取然後再將其新增至 HW SLB。由於在 cpu-0 * 此項目從未失效因此新增此項目至 HW * SLB 會造成 SLB 多次點擊錯誤。 */ load_elf_binary 續 ---truncated--- (CVE-2025-71078)

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

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

  - RDMA/核心正確檢查 LS_NLA_TYPE_DGID 是否存在。RDMA_NL_LS_OP_IP_RESOLVE 的 netlink 回應應該一律有 LS_NLA_TYPE_DGID 屬性否則無效。
    正確使用 nl 剖析邏輯並呼叫 nla_parse_deprecated() 以填入 nlattrs 陣列然後直接索引該陣列以取得 DGID 的資料。若為 NULL則失敗。移除 nla 的搜尋迴圈並將驗證和剖析壓縮為一個函式。修正未將 DGID 提供給核心啟動的 RDMA_NL_LS_OP_IP_RESOLVE 查詢時由使用者空間觸發的未初始化堆疊讀取。錯誤 KMSANhex_byte_pack include/linux/hex.h:13 中的 uninit-value [內嵌] 錯誤 KMSANip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h 中的 uninit-value 13 [內嵌] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 指標+0xc09/0x1bd0 lib/vsprintf.c 2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk /printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [內嵌] ib_nl_handle_ip_res_resp +0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [內嵌] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [內嵌] rdma_nl_rcv+0xefa/ 0x11c0 drivers/infiniband/core/netlink.c :259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [內嵌] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c 714 [內嵌]
    __sock_sendmsg+0x333/0x3d0 net/socket.c:729____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
    ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703
    __compat_sys_sendmsg net/compat.c:346 [內嵌] __do_compat_sys_sendmsg net/compat.c:353 [內嵌]
    __se_compat_sys_sendmsg net/compat.c:350 [內嵌] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86 syscall_32.c:83 [內嵌] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry /syscall_32.c:3 (CVE-2025-71096)

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

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

  - 已解決 Linux 核心中的下列弱點：iommu/mediatek: fix use-after-free on probe deferral The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers. Fix this by keeping the references as expected while the iommu driver is bound. (CVE-2025-71071)

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

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

  - ksmbd略過相等大小時的鎖定範圍檢查以避免 size==0 反向溢位當大小等於目前 i_size (包括 0)時程式碼會用來呼叫 check_lock_range(filp, i_size, size - 1, WRITE)其會計算 `大小
    - 1` 且 size==0 會發生反向溢位。略過大小寫相等的情況。 (CVE-2025-68786)

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

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

  - ip6_gre使 ip6gre_header() 變得更健全。這些年syzbot 發現許多在 ip6gre_header() 中造成核心當機的方法 [1]。這涉及團隊或連結驅動程式動態變更其 dev->needed_headroom 和/或 dev->hard_header_len 的能力。在此特定損毀中mld_newpack() 以太小的保留/空餘空間配置 skb而且在呼叫 mld_sendpack() 時syzbot 設法附加 ip6gre 裝置。 [1] skbuffskb_under_panictext:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[截到此處 ]--- --------- net/core/skbuff.c:213 的核心錯誤 <TASK> skb_under_panic net/core/skbuff.c:223 [內嵌] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice。 h:3436 [內嵌] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [內嵌] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ ipv6/ip6_output.c:-1 [內嵌] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [內嵌] ip6_output+0x340/0x550 net/ipv6/ip6_output.c :247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [內嵌] mld_ifc_work+0x83e/0xd60 net/ ipv6/mcast.c:2693 (CVE-2025-71098)

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

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

  - 已解決 Linux 核心中的下列弱點：svcrdma: use rc_pageoff for memcpy byte offset svc_rdma_copy_inline_range added rc_curpage (page index) to the page base instead of the byte offset rc_pageoff. Use rc_pageoff so copies land within the current page. Found by ZeroPath (https://zeropath.com) (CVE-2025-68811)

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

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

  - btrfs如果是在目前交易中移動的目錄則不記錄衝突的 inode。如果是目錄並且在目前的交易中從一個父目錄移動到另一個父目錄則無法記錄衝突的 inode因為這可能會導致在記錄重播期間嘗試使用具有兩個硬連結的目錄一個用於舊的父目錄另一個用於新的父目錄。下列狀況會觸發該問題1) 我們在過去的交易中建立了目錄 dir1 和 dir2。目錄 dir1 將 inode A 做為其父目錄2) 將 dir1 移至其他目錄3) 我們在目錄 inode A 中建立名稱為 dir1 的檔案4) fsync 新檔案。這會導致記錄新檔案的 inode 以及先前在目前交易中移動的目錄 dir1 的 inode。因此記錄樹狀結構具有 dir1 新位置的 INODE_REF 項目
    5) 我們將新檔案移至其他某個目錄。這會導致將記錄樹狀結構更新為包含檔案新位置的新 INODE_REF並移除舊位置的 INODE_REF。這會在我們呼叫 btrfs_log_new_name() 時發生6) 我們 fsync 檔案這會保留在之前步驟中完成的記錄樹狀結構變更 (btrfs_log_new_name() 只會更新記憶體中的記錄樹狀結構) 7) 發生電源故障8) 下次掛載 fs 時會發生記錄重播且在處理目錄 dir1 的 inode 時我們會找到新的 INODE_REF 並新增該連結但由於尚未記錄舊的父項因此不會移除 inode 的舊連結目錄 inode dir1。因此在我們觸發子磁碟區樹狀結構範圍緩衝區的回寫時記錄重播結束後樹狀結構檢查會偵測到我們有一個硬連結計數為 2 的目錄且會發生掛載失敗。dmesg/syslog 中報告的錯誤和堆疊追踪如下[ 3845.729764] BTRFS 資訊 (裝置 dm-0)啟動樹狀結構記錄重播 [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags
    0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] 原始
    017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino =257無效的 nlink具有 2 個但不超過 1 個用於 dir [ 3845.737786] BTRFS 資訊 (裝置 dm-0)分葉 30408704 產生 10 個總計 ptrs 17 可用空間 14881 擁有者 5 [ 3845.737789] BTRFS 資訊 (裝置 dm- 0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [3845.737803] 項目 1 金鑰 (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [3845.737807] item 2 的金鑰 (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] 位置金鑰 (257 1 0) 類型 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 k ey (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [3845.737816] 位置金鑰 (257 1 0) 類型 2 [ ---truncated--- (CVE-2025-68778)

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

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

  - 已解決 Linux 核心中的下列弱點：scsi: target: Reset t_task_cdb pointer in error case If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced in the 'err' path. In case of error, reset NULL t_task_cdb value to point at the default fixed-size buffer. Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-68782)

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

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

  - 已解決 Linux 核心中的下列弱點：tpm2-sessions: Fix out of range indexing in name_size 'name_size' does not have any range checks, and it just directly indexes with TPM_ALG_ID, which could lead into memory corruption at worst. Address the issue by only processing known values and returning -EINVAL for unrecognized values. Make also 'tpm_buf_append_name' and 'tpm_buf_fill_hmac_session' fallible so that errors are detected before causing any spurious TPM traffic.
    End also the authorization session on failure in both of the functions, as the session state would be then by definition corrupted. (CVE-2025-68792)

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

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

  - NFSDNFSv4 檔案建立作業忽略設定 ACL。在檔案建立期間以具名主體設定 ACL 的 NFSv4 用戶端之後可擷取 ACL然後發現這只是預設 ACL (根據模式位元)而非原本檔案建立期間已要求。這違反了 RFC 8881 區段 6.4.1.3ACL 屬性設定為指定狀態。此問題發生在 nfsd_create_setattr() 中進而呼叫 nfsd_attrs_valid() 來判斷是否要呼叫 nfsd_setattr()。不過nfsd_attrs_valid() 只會檢查 iattr 變更和安全性標籤而不會檢查 POSIX ACL。只有 ACL 存在時函式會傳回 false並略過 nfsd_setattr()且 POSIX ACL 從不套用至 inode。隨後當用戶端擷取 ACL 時伺服器在 inode 上找不到 POSIX ACL並傳回從檔案的模式位元產生的一個 POSIX ACL而非傳回原本指定的 ACL。 (CVE-2025-68803)

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

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

  - 已解決 Linux 核心中的下列弱點：xfs: fix a UAF problem in xattr repair The xchk_setup_xattr_buf function can allocate a new value buffer, which means that any reference to ab->value before the call could become a dangling pointer. Fix this by moving an assignment to after the buffer setup. (CVE-2025-68784)

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

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

  - ocfs2修正 ocfs2_find_victim_chain 中的核心錯誤 syzbot 報告 ocfs2_find_victim_chain() 中的一個核心錯誤這是因為配置鏈結清單 (鏈結清單中的下一個可用插槽) 的 `cl_next_free_rec` 欄位為 0進而觸發 BUG_ON(!cl->cl_next_free_rec) ocfs2_find_victim_chain() 中的情形並造成核心錯誤。為修正此問題在 ocfs2_claim_suballoc_bits() 中引入了一個 if 條件就在呼叫 ocfs2_find_victim_chain() (其中的程式碼區塊在下列任一條件為真時執行) 2. `cl_next_free_rec` 大於 `cl_count` (配置鏈清單中的鏈結總數)其中任一為真表示沒有剩餘鏈可供使用。
    此問題已使用 ocfs2_error() 解決其會列印錯誤記錄以供除錯之用而不會造成核心錯誤。 (CVE-2025-68771)

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

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

  - 已解決 Linux 核心中的下列弱點：spi: fsl-cpm: Check length parity before switching to 16 bit mode Commit fc96ec826bce (spi: fsl-cpm: Use 16 bit mode for large transfers with even size) failed to make sure that the size is really even before switching to 16 bit mode. Until recently the problem went unnoticed because kernfs uses a pre-allocated bounce buffer of size PAGE_SIZE for reading EEPROM. But commit 8ad6249c51d0 (eeprom: at25: convert to spi-mem API) introduced an additional dynamically allocated bounce buffer whose size is exactly the size of the transfer, leading to a buffer overrun in the fsl-cpm driver when that size is odd. Add the missing length parity verification and remain in 8 bit mode when the length is not even. (CVE-2025-68773)

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

ID	名稱	嚴重性
283657	Linux Distros 未修補的弱點：CVE-2025-68768	medium
283656	Linux Distros 未修補的弱點：CVE-2025-71085	medium
283655	Linux Distros 未修補的弱點：CVE-2025-68785	medium
283654	Linux Distros 未修補的弱點：CVE-2025-68770	medium
283653	Linux Distros 未修補的弱點：CVE-2025-68813	medium
283652	Linux Distros 未修補的弱點：CVE-2025-71090	medium
283651	Linux Distros 未修補的弱點：CVE-2025-68819	medium
283650	Linux Distros 未修補的弱點：CVE-2025-68801	high
283649	Linux Distros 未修補的弱點：CVE-2025-68777	medium
283648	Linux Distros 未修補的弱點：CVE-2025-68821	medium
283647	Linux Distros 未修補的弱點：CVE-2025-71066	medium
283646	Linux Distros 未修補的弱點：CVE-2025-68788	medium
283645	Linux Distros 未修補的弱點：CVE-2025-71092	high
283644	Linux Distros 未修補的弱點：CVE-2025-71101	high
283643	Linux Distros 未修補的弱點：CVE-2025-71067	high
283642	Linux Distros 未修補的弱點：CVE-2025-71069	medium
283641	Linux Distros 未修補的弱點：CVE-2025-68769	medium
283640	Linux Distros 未修補的弱點：CVE-2025-71072	medium
283638	Linux Distros 未修補的弱點：CVE-2025-71097	medium
283637	Linux Distros 未修補的弱點：CVE-2025-71086	high
283636	Linux Distros 未修補的弱點：CVE-2025-68809	medium
283635	Linux Distros 未修補的弱點：CVE-2025-68814	medium
283634	Linux Distros 未修補的弱點：CVE-2025-68822	medium
283633	Linux Distros 未修補的弱點：CVE-2025-68808	high
283632	Linux Distros 未修補的弱點：CVE-2025-68470	medium
283631	Linux Distros 未修補的弱點：CVE-2025-71094	medium
283630	Linux Distros 未修補的弱點：CVE-2025-71080	medium
283629	Linux Distros 未修補的弱點：CVE-2025-71073	high
283628	Linux Distros 未修補的弱點：CVE-2025-68793	medium
283627	Linux Distros 未修補的弱點：CVE-2025-68820	medium
283626	Linux Distros 未修補的弱點：CVE-2025-68797	medium
283625	Linux Distros 未修補的弱點：CVE-2025-71088	medium
283624	Linux Distros 未修補的弱點：CVE-2025-71089	high
283623	Linux Distros 未修補的弱點：CVE-2026-22772	medium
283622	Linux Distros 未修補的弱點：CVE-2025-71074	medium
283621	Linux Distros 未修補的弱點：CVE-2025-71087	medium
283620	Linux Distros 未修補的弱點：CVE-2025-71091	high
283619	Linux Distros 未修補的弱點：CVE-2025-71078	high
283618	Linux Distros 未修補的弱點：CVE-2025-71096	medium
283617	Linux Distros 未修補的弱點：CVE-2025-71071	high
283616	Linux Distros 未修補的弱點：CVE-2025-68786	high
283615	Linux Distros 未修補的弱點：CVE-2025-71098	medium
283614	Linux Distros 未修補的弱點：CVE-2025-68811	high
283613	Linux Distros 未修補的弱點：CVE-2025-68778	low
283612	Linux Distros 未修補的弱點：CVE-2025-68782	medium
283611	Linux Distros 未修補的弱點：CVE-2025-68792	high
283610	Linux Distros 未修補的弱點：CVE-2025-68803	medium
283609	Linux Distros 未修補的弱點：CVE-2025-68784	high
283608	Linux Distros 未修補的弱點：CVE-2025-68771	high
283607	Linux Distros 未修補的弱點：CVE-2025-68773	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

high

high

high

medium

medium

medium

medium

high

medium

medium

medium

high

medium

medium

medium

high

medium

medium

medium

medium

high

medium

medium

medium

high

high

medium

high

high

medium

high

low

medium

high

medium

high

high

medium