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

  - libceph重設 osd_fault() 中的 sparse-read 狀態發生錯誤時會捨棄連線並重新建立並重試任何擱置的作業。OSD 用戶端使用獨立的狀態機器追踪 sparse-read 回覆的進度該狀態機器基本上獨立於 messenger 的狀態。如果連線在負載中途遺失或疏鬆讀取狀態機器傳回錯誤則不會重設疏鬆讀取狀態。
    OSD 用戶端接著會將新回覆的開頭解譯為舊回覆的接續。如果這造成 sparse-read 機器進入失敗狀態它可能永遠無法復原進而產生類似以下的迴圈
    libceph[0] got 0 extents libcephdata len 142248331 != extent len 0 libcephosd0 (1)...:6801 通訊端讀取時發生錯誤 libcephdata len 142248331 != extent len 0 libcephosd0 (1)。 ..:6801 通訊端讀取錯誤。因此重設 osd_fault() 中的 sparse-read 狀態確保從乾淨的狀態開始重試。
    (CVE-2026-23136)

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

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

  - l2tp避免 l2tp_tunnel_del_work() 中發生資料爭用。我們應僅在處理核心通訊端時讀取 sk->sk_socket。 syzbot 報告下列資料爭用錯誤KCSAN透過 cpu 0 sk_set_socket include/net/sock.h:2092 [內嵌] sock_orphan include/net/ 在 l2tp_tunnel_del_work / sk_common_release 寫入 0xffff88811c182b20 (由 cpu 0 上的工作 5365 寫入 8 位元組之 0xffff88811c182b20) 中發生資料爭用sock.h:2118 [內嵌] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [內嵌] sock_close+0x6b/0x150 net/socket.c:1455
    __fput+0x29b/0x650 fs/file_table.c:468____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [內嵌]
    __exit_to_user_mode_loop kernel/entry/common.c:44 [內嵌] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [內嵌] syscall_exit_to_user_mode_prepare include/linux/irq -entry-common.h:256 [內嵌] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [內嵌] syscall_exit_to_user_mode include/linux/entry-common.h:194 [內嵌] do_syscall_64+0x1e1/0x2b0 arch/x86/ entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由 cpu 1 上的 827 工作讀取至 8 位元組的 0xffff88811c182b20
    l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread +0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 值已變更
    0xffff88811b818000 -> 0x0000000000000000 (CVE-2026-23120)

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

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

  - 藍牙MGMT修正 set_ssp_complete 中的記憶體洩漏修正 set_ssp_complete() 中的記憶體洩漏其中 mgmt_pending_cmd 結構從擱置清單中移除後並未釋放。提交 302a1f674c00 (藍牙MGMT修正可能的 UAF) 將 mgmt_pending_foreach() 呼叫取代為個別的命令處理但遺漏在 set_ssp_complete() 的錯誤和成功路徑中新增 mgmt_pending_free() 呼叫。set_le_complete() 等其他完成函式已在相同提交中正確修正。這會造成每個完成之 SSP 命令的 mgmt_pending_cmd 結構及其相關參數資料的記憶體洩漏。在兩個程式碼路徑中新增遺漏的 mgmt_pending_free(cmd) 呼叫以修正記憶體洩漏。也修正 set_advertising_complete() 中的相同問題。 (CVE-2026-23151)

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

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

  - 已解決 Linux 核心中的下列弱點：drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl() Since GEM bo handles are u32 in the uapi and the internal implementation uses idr_alloc() which uses int ranges, passing a new handle larger than INT_MAX trivially triggers a kernel warning: idr_alloc(): ... if (WARN_ON_ONCE(start < 0)) return -EINVAL; ... Fix it by rejecting new handles above INT_MAX and at the same time make the end limit calculation more obvious by moving into int domain. (CVE-2026-23149)

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

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

  - igc將 TSN TX 封包緩衝區從每個佇列的 7KB 減少至 5KB。先前每個佇列的 7KB 造成 TX 單元在時間戳記負載過重情況下懸置。減少至 5 KB 可避免這些懸置且符合 I225/I226 SW 使用者手冊第 7.5.4節中的 TSN 建議。此變更釋放的 8 KB 目前未使用。此減少預期不會影響傳輸率因為 i226 可處理小型 TSN 封包的 PCIe 限製而非 TX 緩衝區限制。 (CVE-2026-23122)

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

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

  - bpf、test_run從允許的詮釋資料大小中減去 xdp_frame 的大小。xdp_frame 結構佔用部分 XDP 框架空餘空間進而限制詮釋資料的大小。不過在 bpf_test_run 中我們並未將此納入考量這會讓使用者空間提供過大的詮釋資料大小 (佔用整個空餘空間)。如果使用者空間在即時封包模式下提供如此大的詮釋資料大小xdp_test_run_init_page() 呼叫中的 xdp_update_frame_from_buff() 呼叫將會失敗之後封包傳輸會使用未初始化的框架結構進而導致常見的 Bad Stuff。「修正」標籤中的提交修正了一個相關錯誤其中 xdp_update_frame_from_buff() 中的第二次檢查可能會失敗但並未針對詮釋資料大小新增任何額外的限制。新增詮釋資料大小的額外檢查以完成修正。稍微重新排列檢查以使邏輯更清楚並新增註解。
    (CVE-2026-23140)

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

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

  - mISDN註解 dev->work 的資料爭用 dev->work 可在 mISDN_read() 和 mISDN_poll() 中無鎖定地重新讀取。新增 READ_ONCE()/WRITE_ONCE() 註解。錯誤KCSANmISDN_ioctl / mISDN_read 中的資料爭用寫入作業 10864 在 cpu 1misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 寫入 0xffff88812d848280 (共 4 個位元組) 時發生資料爭用 [內嵌] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/ timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl.c:597 [內嵌] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c 583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [內嵌] vfs_0x3 讀取到 0xffff88812d848280 (共 4 個位元組) /0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [內嵌]
    __se_sys_readv fs/read_write.c:1162 [內嵌] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/ syscall_64.c:63 [內嵌] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f 值已變更0x00000000 -> 0x00000001 (CVE-2026-23121)

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

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

  - ipv6ndisc_router_discovery() 中的註解資料爭用 syzbot 發現 ndisc_router_discovery() 可以在不保留鎖定的情況下讀取和寫入 in6_dev->ra_mtu [1] 情況似乎沒有問題IFLA_INET6_RA_MTU 才是最佳作法。
    新增 READ_ONCE()/WRITE_ONCE() 以記錄爭用。請注意我們也可能拒絕未來修補程式中的非法 MTU 值 (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu)。 [1] BUG: KCSAN in ndisc_router_discovery / ndisc_router_discovery 中發生資料爭用由 cpu 1 上的工作 25817 讀取至 0xffff888119809c20 (共 4 個位元組) ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net// ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOKinclude/ linux/netfilter.h:318 [內嵌] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [內嵌] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... 在 cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3dd00x3dd00x3dd00x3dd00x3dd00.c:79 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c: 489 NF_HOOK include/linux/netfilter.h :318 [內嵌] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [內嵌] ip6_rcv_finish+0x336/ 0x340 net/ipv6/ip6_input.c:79 ... 值已變更
    0x00000000 -> 0xe5400659 (CVE-2026-23124)

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

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

  - flex_proportions使 fprop_new_period() hardirq 安全Bernd 報告彈性比例程式碼發生 lockdep 展開其主要是關於下列爭用情形 <timer fires> run_timer_softirq
    - 我們在 softirq 內容中 call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); <hardirq is raised> ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - 發現奇數序列因此無限迴圈。請注意只有在 bdi 已設定寫出輸送量的最大分數時才可能發生類似的鎖死情形這通常是非常罕見的情況但例如 FUSE bdis 之類的情況卻很常見。若要修正此問題我們必須確認序列計數器的寫入區段為 irqsafe。 (CVE-2026-23168)

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

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

  - drm/xe/nvm修正輔助新增失敗時的重複釋放在成功的輔助裝置_init() 之後aux_dev->dev.release (xe_nvm_release_dev()) 會負責 kfree(nvm)。auxiliary_device_add() 失敗時驅動程式將呼叫輔助裝置_uninit()而後者又呼叫 put_device()。因此將觸發 .release 回呼以釋放與輔助裝置相關聯的記憶體。將 kfree(nvm) 移至輔助裝置_init() 失敗路徑並移除 err goto 路徑以修正以下錯誤。
     [ 13.232905] ============================================== ==================== [ 13.232911] 錯誤KASAN
    xe_nvm_init+0x751/0xf10 中發生雙重釋放 [xe] [ 13.233112] systemd-udevd/273 工作從 addr ffff888120635000 中釋放 [ 13.233120] CPU8 UID0 PID 273 Commsystemd-udevd 未受污染的 6.19.0 -rc2-lgci-xe-kernel+ #225 PREEMPT(vulnerable) ... [ 13.233125] 呼叫追踪 [ 13.233126] <TASK> [ [ 13.233127] dump_stack_lvl+0x7f/0xc0 [ 13.233132] print_report+0xce/0x610 [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0 [ 13.233139] xe_nvm_init+0x751/0xf10 [xe] ... v2中斷 err goto 路徑。(Alexander) (從認可 a3187c0c2bbd947ffff97f90d077ac88f9c2a215) (CVE-2026-23162)

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

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

  - perfsched使用新的 is_user_task() 協助程式修正 perf 損毀。為了執行使用者空間堆疊追踪目前的工作必須是已在使用者空間中執行的使用者工作。過去可以簡單地檢查 task_struct mm 欄位來測試工作是否為使用者工作。若為非 NULL則為使用者工作反之為核心工作。但隨著時間的推移情況已經發生變化現在有些核心工作有自己的 mm 欄位。有想法改為測試 PF_KTHREAD並使用兩個函式包裝此檢查避免測試工作是否為使用者工作變得更為複雜[1]。但這遭到拒絕且 C 程式碼會直接檢查 PF_KTHREAD。後來發現並非所有核心執行緒都會設定 PF_KTHREAD。io-uring 協助程式會設定 PF_USER_WORKER此項目也必須加以新增。但是僅檢查旗標仍然不夠。工作結束時會在一個非常小的視窗中釋放其 mm 欄位並將其設回 NULL。如果此時觸發 perf旗標測試會判斷這是使用者空間工作但當 perf 讀取 mm 欄位時就會因 NULL 指標解除參照而當機。現在有一些旗標可用來測試工作是否正在結束但是這些旗標是在 perf 可能仍想要設定檔使用者空間工作 (以查看結束在何處) 的區域中設定。唯一真正的測試是同時檢查旗標和 mm 欄位。與其在每個位置進行此修改不如建立一個新的 is_user_task() helper 函式讓其執行所需的所有測試以了解讀取使用者空間記憶體是否安全。 [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/ (CVE-2026-23159)

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

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

  - efivarfs修正 efivar_entry_get() 中的錯誤傳播問題即使基礎 __efivar_entry_get() 失敗efivar_entry_get() 也會一律傳回成功以遮罩錯誤。這可能會導致將未初始化的堆積記憶體複製到 efivarfs_file_read() 路徑中的使用者空間。透過從 傳回錯誤來修正此問題
    __efivar_entry_get()。 (CVE-2026-23156)

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

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

  - procfs避免在保留 VMA 鎖定時擷取組建 ID。將 PROCMAP_QUERY 修正為只在卸除 mmap_lock 或 per-VMA 鎖定 (以鎖定有問題的 VMA 中所用者為準) 後擷取選用的組建 ID以避免 syzbot 報告的鎖死-> #1 (&mm ->mmap_lock){++++}-{4:4}: __might_fault+0xed/0x170
    _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&sb->s_type- >i_mutex_key#8){++++}-{4:4}:
    __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0
    __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us除錯此可能的不安全鎖定情況CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock);
    lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8); *** DEADLOCK
    ***這似乎因最近的
    777a8560fd29 (lib/buildid針對可睡眠的內容使用 __kernel_read()) 為確保安全我們必須在 VMA 仍處於鎖定狀態時擷取檔案參照計數但除此之外一切皆相當簡單。
    內部 build_id_parse() API 假設 VMA 已傳遞但它只需要基礎檔案參照因此只要新增預期直接傳遞 file 的另一個變體 build_id_parse_file()。 [akpm@linux-foundation.org修正 kerneldoc] (CVE-2026-23199)

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

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

  - ALSAusb-audio防止過多的框架數在此情況下使用者使用 maxpacksize 40 (速率 22050 / pps 1000) 和 packsize[0] 22 packsize[1] 23 建構參數。每個資料 URB 的緩衝區大小為 maxpacksize * packet在此範例中為 40 * 6 = 240當使用者執行寫入作業以將音訊資料傳送至 ALSA PCM 播放資料流時計算出的框架數為 packsize[0] * packet = 264這超出了配置的 URB 緩衝區大小進而觸發超出邊界 (OOB ) 問題由 syzbot [1] 報告。計算框架數目時新增單一資料 URB 框架數目的檢查以防止 [1]。 [1] 錯誤KASAN工作 syz.0.17/5506 在 copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 中寫入大小為 264 的位置 ffff88804337e800 呼叫追踪copy_to_urb+0x261/ 0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333 (CVE-2026-23208)

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

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

  - macvlan修正 macvlan_common_newlink() 中的錯誤復原提供了一個 nice 的 repro 以損毀核心
    ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add無效的% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 他也提供了非常詳細的分析 <quote valis> 問題會在建立新的 macvlan 連結時觸發在 MACVLAN_MODE_SOURCE 模式和 MACVLAN_MACADDR_ADD (或 MACVLAN_MACADDR_SET) 參數的情況下較低層裝置已擁有 macvlan 連接埠且從 macvlan_common_newlink() 呼叫的 register_netdevice() 會失敗 (例如因為無效的連結名稱)。在此情況下macvlan_hash_add_source 會從 macvlan_change_sources() 呼叫 / macvlan_common_newlink(): 這會將 vlan 的參照新增至使用 macvlan_source_entry 的連接埠 vlan_source_hash。 vlan 是指向建立中連結之 priv 資料的指標。register_netdevice() 失敗時會將錯誤從 macvlan_newlink() 傳回 rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out且會呼叫 free_netdev()在結構 net_device 上產生一個 kvfree()而該結構仍在連接至較低裝置 macvlan 連接埠的來源項目中參照。現在在 macvlan 連接埠上傳送且具有相符來源 mac 位址的所有封包都會在 macvlan_forward_source() 中觸發釋放後使用。</quote valis> 儘管如此我的修正方法是確保在每次 goto destroy_macvlan_port; 之後無論 @create 值為何我們都會呼叫 macvlan_flush_sources()路徑。
    非常感謝 valis 就此問題採取的後續行動。 (CVE-2026-23209)

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

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

  - pmdomainimx8m-blk-ctrl修正 imx8m_blk_ctrl_remove() 中 bc->domains 的超出範圍存取修正 bc->domains 超出範圍的存取。 (CVE-2026-23187)

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

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

  - netusbr8152修正繼續重設鎖死 rtl8152 可在重設期間觸發可能導致鎖死的裝置重設**** DPM 裝置在 10 秒後逾時15 秒後發生錯誤 **** 呼叫追踪 <TASK> schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470
    __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110 The problem is that rtl8152 resume calls reset under tp ->control mutex 而重設基本上會重新進入 rtl8152 並再次嘗試取得相同的 tp->control 鎖定。在 tp->control mutex 範圍外重設 INACCESSIBLE 裝置以避免遞回 mutex_lock() 鎖死。 (CVE-2026-23188)

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

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

  - smb/server修正當命令是重播作業且 parse_durable_handle_context() 中發生的 refcount 洩漏
    -ENOEXEC 傳回後則必須釋放 ksmbd_file 的 refcount。 (CVE-2025-71204)

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

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

  - netcpsw在工作佇列中執行 ndo_set_rx_mode 回呼。提交 1767bb2d47b7 (ipv6mcast不針對 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 保留 RTNL)已移除 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 作業的 RTNL 鎖定。但是此變更在我的 BeagleBone Black board 上觸發了下列呼叫追踪警告net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124 CPU#0rpcbind/481 RTNL
    net/8021q/vlan_core.c 的宣告失敗 (236) 連結的模組CPU0 UID997 PID481 Commrpcbind 未受污染的 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT 硬體名稱Generic AM33XX (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x28/0x2c show_stack from dump_stack_lvl+0x30/0x38 dump_stack_lvl from __warn+0xb8/0x11c __warn from warn_slowpath_fmt+0x130/0x194 warn_slowpath_fmt from vlan_for_each+0x120/0x124 vlan_for_each from cpsw_add_mc_addr+0x54 /0x98 cpsw_add_mc_addr 來自 __hw_addr_ref_sync_dev+0xc4/0xec __hw_addr_ref_sync_dev 來自 __dev_mc_add+0x78/0x88
    來自 igmp6_group_added+0x84/0xec 的 __dev_mc_add 來自 __ipv6_dev_mc_inc+0x1fc/0x2f0 的 igmp6_group_added
    __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4 __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168 do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8 ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c do_sock_setsockopt from __sys_setsockopt+0x84/0xac __sys_setsockopt from ret_fast_syscall+0x0/0x54 This trace occurs because vlan_for_each() is在 cpsw_ndo_set_rx_mode() 中呼叫其預期 RTNL 鎖定會遭到保留。由於修改 vlan_for_each() 以在沒有 RTNL 鎖定的情況下運作並不簡單而且因為在不同的程式碼路徑上有和沒有 RTNL 鎖定的情況下都會叫用 ndo_set_rx_mode()因此只在 cpsw_ndo_set_rx_mode() 中新增 rtnl_lock() 不是可行的解決方案。為解決此問題我們選擇依循 icssg-prueth 驅動程式所用的方法在工作佇列中執行實際處理。請注意若要重現此問題我已手動將提交 c477358e66a3 的變更還原為 am335x-bone-common.dtsi 的變更 (ARM: dtsam335x-bone切換至新的 cpsw 切換 drv)以便還原為舊版 cpsw 驅動程式。 (CVE-2026-23175)

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

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

  - net/schedcls_u32使用 skb_header_pointer_careful() skb_header_pointer() 並未完整驗證負的 @offset 值。改用 skb_header_pointer_careful()。GangMin Kim 提供了報告和重現偽造 u32_classify()錯誤KASANu32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221 中的 slab-out-of-bounds (CVE-2026-23204)

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

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

  - netcpsw_new工作佇列中執行 ndo_set_rx_mode 回呼。提交 1767bb2d47b7 (ipv6mcast不針對 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 保留 RTNL)已移除 IPV6_ADD_MEMBERSHIP 和 MCAST_JOIN_GROUP 作業的 RTNL 鎖定。但是此變更在我的 BeagleBone Black board 上觸發了下列呼叫追踪警告net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124 CPU#0rpcbind/496 RTNL
    net/8021q/vlan_core.c 的宣告失敗 (236) 連結的模組CPU0 UID997 PID496 Commrpcbind 未受污染的 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT 硬體名稱Generic AM33XX (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x28/0x2c show_stack from dump_stack_lvl+0x30/0x38 dump_stack_lvl from __warn+0xb8/0x11c __warn from warn_slowpath_fmt+0x130/0x194 warn_slowpath_fmt from vlan_for_each+0x120/0x124 vlan_for_each from cpsw_add_mc_addr+0x54 /0xd8 cpsw_add_mc_addr 來自 __hw_addr_ref_sync_dev+0xc4/0xec __hw_addr_ref_sync_dev 來自 __dev_mc_add+0x78/0x88
    來自 igmp6_group_added+0x84/0xec 的 __dev_mc_add 來自 __ipv6_dev_mc_inc+0x1fc/0x2f0 的 igmp6_group_added
    __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4 __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168 do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8 ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c do_sock_setsockopt from __sys_setsockopt+0x84/0xac __sys_setsockopt from ret_fast_syscall+0x0/0x5 This trace occurs because vlan_for_each() is在 cpsw_ndo_set_rx_mode() 中呼叫其預期 RTNL 鎖定會遭到保留。由於修改 vlan_for_each() 以在沒有 RTNL 鎖定的情況下運作並不簡單而且因為在不同的程式碼路徑上有和沒有 RTNL 鎖定的情況下都會叫用 ndo_set_rx_mode()因此只在 cpsw_ndo_set_rx_mode() 中新增 rtnl_lock() 不是可行的解決方案。為解決此問題我們選擇依循 icssg-prueth 驅動程式所用的方法在工作佇列中執行實際處理。 (CVE-2026-23203)

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

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

  - wifiiwlwifimld取消 mlo_scan_start_wk 中斷連線時未取消 mlo_scan_start_wk。事實上它不會在任何地方取消但在我們並非必須取消的重新啟動清理中除外。這可造成 init-after-queue 問題例如工作先排入佇列然後再執行 drv_change_interface。如果在釋放 vif 之後執行工作這也會造成釋放後使用錯誤。
    (CVE-2026-23185)

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

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

  - cgroup/dmem修正設定最大值時的 NULL 指標解除參照。已觸發的問題錯誤核心 NULL 指標解除參照位址0000000000000000 #PF在核心模式中進行監督讀取存取 #PF
    error_code(0x0000) - 不存在頁面 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 658 Comm: bash 受污染的 6.19.0-rc6-next-2026012 受污染的O]=OOT_MODULE 硬體名稱: QEMU Standard PC (i440FX + PIIX, 1996)、RIP: 0010:strcmp+0x10/0x30 RSP: 0018:ffffc900017f7dc0 EFLAGS: 00000246 RAX
    0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358 RDX: 0000000019f73907 RSI: ffffffff82cc381a RDI: 0000000000000000 RBP: ffff8881016bef0d R08: 000000006c0e7145 R09: 0000000056c0e714 R10:
     R110000000000000001  : ffff888107cd4358 R12: 0007ffffffffffff R13: ffff888101399200 R14: ffff888100fcb360 R15: 0007ffffffffffff CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3:
    0000000105c79000 CR400000000000006f0 呼叫追踪 <TASK> dmemcg_limit_write.constprop.0+0x16d/0x390
    __pfx_set_resource_max+0x10/0x10 kernfs_fop_write_iter+0x14e/0x200 vfs_write+0x367/0x510 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP
    0033:0x7f42697e1887 在無限制的情況下設定 max 時觸發該命令如下echo test/region0 > dmem.max。若要修正此問題請在剖析 region_name 後新增選項是否有效的檢查。 (CVE-2026-23183)

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

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

  - nvmet-tcp修正 nvmet_tcp_listen_data_ready() 中的懸置。當通訊端關閉且處於 TCP_LISTEN 中時系統會執行回呼以排清所有待處理的封包進而在保留 sk_callback_lock 的情況下呼叫 nvmet_tcp_listen_data_ready()。因此在嘗試取得 sk_callback_lock() 之前我們需要檢查我們是否處於 TCP_LISTEN 中以避免鎖死。 (CVE-2026-23179)

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

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

  - ceph修正 ceph_mds_auth_match() 中的 NULL 指標解除參照。CephFS 核心用戶端從 6.18-rc1 開始有回歸。if fs_name == NULL在 ceph_mds_auth_match() 中有問題const char fs_name = mdsc->fsc->mount_options->mds_namespace ... if (auth->match.fs_name && strcmp(auth->match.fs_name, fs_name)) { / fsname 不符, 請嘗試下一個 */ 傳回 0; Patrick Donnelly 的建議總而言之我們絕對應該從 MDSMap 開始解碼 `fs_name` 並對其進行嚴格的授權檢查。
    請注意`-o mds_namespace=foo` 只應用於選取要掛載的檔案系統而非其他項目。可能未指定 mds_namespace但核心會掛載唯一存在且名稱可能為 foo 的檔案系統。此修補程式可重新執行 ceph_mdsmap_decode() 和 namespace_equals()以支援建議的概念。現在 ceph_mdsmap 結構含有 m_fs_name 欄位該欄位會接收由 ceph_extract_encoded_string() 擷取的 FS 名稱副本。若是舊版 CephFS 檔案系統則會使用 cephfs 名稱。 [ idryomov將 ceph_mdsmap_decode() 中多餘的 %*pE 取代為 %s擺脫 ceph_namespace_match() 中的一系列 strlen() 呼叫中斷對 namespace_equals() 內文的變更以避免將空白的 mds_namespace 視為等同中斷對 ceph_mdsc_handle_fsmap 的變更()因為 namespace_equals() 在該處不是對等替代項] (CVE-2026-23189)

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

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

  - wifimac80211ocb未加入介面時略過 rx_no_sta ieee80211_ocb_rx_no_sta() 假設有效的通道內容僅存在於 JOIN_OCB 之後。RX 可在執行 JOIN_OCB 之前執行在此情況下OCB 介面無法運作。未加入介面時略過 RX 對等處理以避免 RX 路徑中出現警告。 (CVE-2025-71224)

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

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

  - smb/client修正 smb2_open_file() Reproducer 中的記憶體洩漏 1. 伺服器目錄以唯讀方式匯出 2. 用戶端mount -t cifs //${server_ip}/export /mnt 3. 用戶端 dd if=/ dev/zero of=/mnt/file bs=512 count=1000 oflag=direct 4. 用戶端umount /mnt 5. 用戶端sleep 1 6. 用戶端modprobe -r cifs 錯誤訊息如下===== ================================================== ====================== 錯誤 cifs_small_rq (未受污染)__kmem_cache_shutdown() 中的剩餘物件
    -------------------------------------------------- --------------------------- 物件 0x00000000d47521be @offset=14336... 警告在 __kmem_cache_shutdown+0x34e/0x440 的 mm/slub.c:1251、 CPU#0modprobe/1577 ...
    Call Trace: <TASK> kmem_cache_destroy+0x94/0x190 cifs_destroy_request_bufs+0x3e/0x50 [cifs] cleanup_module+0x4e/0x540 [cifs] __se_sys_delete_module+0x278/0x400 __x64_sys_delete_module+0x5f/0x70 x64_sys_call+0x2299/0x2ff0 do_syscall_64+0x89/0x350 entry_SYSCALL_64_after_hwframe+0x76/ 0x7e ...
    kmem_cache_destroy cifs_small_rq從 cifs_destroy_request_bufs+0x3e/0x50 呼叫時平台快取仍有物件 [cifs] 警告 kmem_cache_destroy+0x16b/0x190 的 mm/slab_common.c:532 CPU#0modprobe/1577 (CVE-2026-23205)

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

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

  - linkwatch在呼叫端中使用 __dev_put() 以防止 UAF 在 linkwatch_do_dev() 呼叫 __dev_put() 以釋放 linkwatch 參照之後裝置參照計數可能會降為 1。此時netdev_run_todo() 可以繼續進行 (因為 linkwatch_sync_dev() 會看到清空清單並傳回不封鎖)、等待 refcount 透過 netdev_wait_allrefs_any() 變成 1然後透過 kobject_put() 釋放裝置。當 __linkwatch_run_queue() 嘗試在已釋放的裝置上呼叫 netdev_unlock_ops() 時這會造成釋放後使用。
    請注意在 kobject_put() 之前在 netdev_run_todo() 中新增 netdev_lock_ops()/netdev_unlock_ops() 配對不會有作用因為 netdev_lock_ops() 是有條件的 - 它只會在 netdev_need_ops_lock() 傳回 true 時鎖定。如果裝置不需要 ops_lock則 linkwatch 不會保留任何鎖定且取得鎖定的 netdev_run_todo() 也不會提供同步處理。將 __dev_put() 從 linkwatch_do_dev() 移至其呼叫者以修正此問題。裝置參照會在邏輯上配對裝置取消列出因此執行取消列出的呼叫者將其釋放是合理的。這允許在完成所有裝置存取之後放置 __dev_put()進而防止 UAF。在 __linkwatch_run_queue() 的 linkwatch_do_dev() 之後新增 mdelay(2000)然後執行 ip tuntap add mode tun name tun_test ip link set tun_test up ip link set tun_test Carrier off ip link set tun_testcarrier on sleep 0.5 ip tuntap del mode tun name tun_test KASAN report ======================================== ========================== 錯誤KASANnetdev_need_ops_lock include/net/netdev_lock.h:33 中的釋放後使用 [內嵌] 錯誤KASANnetdev_unlock_ops include/net/netdev_lock.h:47 中的釋放後使用 [內嵌] 錯誤 KASAN 中的釋放後使用
    __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 kworker/u32:10/8123 CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 未受污染的 syzkaller 在 addr ffff88804de5c008 讀取大小為 8 的內容 #0 。 ] PREEMPT(完整) 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作佇列events_unbound linkwatch_event 呼叫追踪 <TASK> __dump_stack lib/dump_stack .c:94 [內嵌] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [內嵌] print_report+0x156/0x4c9 mm/kasan/report.c:482 kasan_report+0xdf/ 0x1a0 mm/kasan/report.c:595 netdev_need_ops_lock include/net/netdev_lock.h:33 [內嵌] netdev_unlock_ops include/net/netdev_lock.h:47 [內嵌] __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304 process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [內嵌] worker_thread+0x5da/0xe40 kernel/workqueue.c:3421 kthread +0x3b 3/0x730 kernel/kthread.c:463 ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> ====== ================================================== ========== (CVE-2026-23192)

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

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

  - ice修正 VSI 重建期間的 PTP NULL 指標解除參照。修正爭用情形 (在重建 VSI 時存取 NULL vsi->rx_rings) 執行 PTP 定期工作。序列為 1. ice_ptp_prepare_for_reset() 取消 PTP 工作 2. ice_ptp_rebuild() 立即將 PTP 工作排入佇列 3. VSI 重建發生在 ice_ptp_rebuild() 4. PTP 工作執行並存取 NULL vsi->rx_rings 修正後保持 PTP 工作在重建期間取消僅在 ice_rebuild() 中的 VSI 重建完成後將其排入佇列。新增 ice_ptp_queue_work() helper 函式可封裝 PTP 工作佇列的邏輯確保只有在支援 PTP 且狀態為 ICE_PTP_READY 時才會將其排入佇列。錯誤記錄[ 121.392544] ice 0000:60:00.1PTP 重設成功 [121.392692] 錯誤核心 NULL 指標解除參照位址0000000000000000 [ 121.392712] #PF核心模式中的監督讀取存取 [ 121.392720] #PF error_code(0x0000) - 不存在頁面 [ 121.392727] PGD 0 [121.392734] Oops: Oops: 0000 [#1] SMP NOPTI [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp- 0000:60 受污染 GS 6.19.0-rc6+ #4 PREEMPT(vulnerable) [ 121.392761] 受污染 [S]=CPU_OUT_OF_SPEC [ 121.392773] RIP 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice] [ 121.393042] 呼叫追踪[ 121.393047] <TASK> [121.393055] ice_ptp_periodic_work+0x69/0x180 [ice] [ 121.393202] kthread_worker_fn+0xa2/0x260 [121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice] [ 121.393359] ?
    __pfx_kthread_worker_fn+0x10/0x10 [ 121.393371] kthread+0x10d/0x230 [ 121.393382] ?
    __pfx_kthread+0x10/0x10 [ 121.393393] ret_from_fork+0x273/0x2b0 [ 121.393407] ? __pfx_kthread+0x10/0x10 [121.393417] ret_from_fork_asm+0x1a/0x30 [ 121.393432] </TASK> (CVE-2026-23210)

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

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

  - hwmon(acpi_power_meter) 修正與 acpi_power_meter_notify() 相關的鎖死。acpi_power_meter 驅動程式的 .notify() 回呼函式 (acpi_power_meter_notify()) 在要取消註冊之裝置的 sysfs 屬性中的回呼也會取得的鎖定下呼叫 hwmon_device_unregister()容易在 sysfs 存取和裝置移除之間鎖死。將 acpi_power_meter_notify() 中的 hwmon 裝置移除移至有問題的鎖定外部以解決此問題但請注意僅執行此操作並不足夠因為兩個並行 METER_NOTIFY_CONFIG 通知可能會嘗試同時移除相同裝置。為防止這種情況發生請在 acpi_power_meter_notify() 中新增序列化 switch () 陳述式執行的新鎖定。為簡單起見這是靜態 mutex從效能觀點來看不應是問題。新鎖定也允許在內部鎖定外部呼叫 acpi_power_meter_notify() 中的 hwmon_device_register_with_info()因為其可防止該函式處理的其他通知在註冊以該函式為基礎的 hwmon 裝置時操控資源物件。從 acpi_power_meter_notify() 傳送 ACPI netlink 訊息也會由新鎖定序列化這通常有助於確保處理韌體通知的順序與傳送通知相關 netlink 訊息的順序相同。此外請注意hwmon_device_register_with_info() 可能會失敗resource->hwmon_dev 會變成錯誤指標因此請在 acpi_power_meter_notify() 和 acpi_power_meter_remove() 中新增檢查以避免在此情況下嘗試取消註冊 hwmon 裝置指標。 (CVE-2026-23186)

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

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

  - HID: Intel-thc-hid: Intel-thc: 新增讀取 DMA 緩衝區的安全檢查。新增讀取 DMA 緩衝區前的 DMA 緩衝區就緒檢查以避免非預期的 NULL 指標存取。 (CVE-2026-23196)

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

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

  - wifiwlcore確保 skb_push 前的 skb 空餘空間這可避免 wl1271_tx_work 偶爾發生的 skb_under_panic Oops。在此情況下，空餘空間少於所需 (通常為 110 - 94 = 16 位元組)。
    (CVE-2025-71222)

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

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

  - ceph修正因 parse_longname() 中的無效 kfree() 指標而導致的 oops。修正讀取 ceph 快照目錄 (.snap) 時的核心 oops例如藉由執行 `ls /mnt/my_ceph/.snap`。變數 str 受到 __free(kfree) 保護但因略過快照名稱中的初始「_」而提前一。因此會以無效的指標呼叫 kfree()。此修補程式不需要將指標前移即可以正確的記憶體指標呼叫 kfree()。重現步驟 1. 在 cephfs 磁碟區上建立快照 (我的測試案例中有 63 個 snaps) 2. 新增 cephfs 掛載至 fstab $ echo samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/ test/stuff ceph acl,noatime,_netdev 0 0 >> /etc/fstab 3. 重新啟動系統 $ systemctl reboot 4. 檢查是否確實已掛載 $ mount | grep stuff 5. 列出快照 (我的系統上預期有 63 個快照) $ ls /mnt/test/stuff/.snap 現在 ls 會永遠懸置且核心記錄檔會顯示 oops。 (CVE-2026-23201)

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

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

  - smb/server在 create_smb2_pipe() 的錯誤路徑上呼叫 ksmbd_session_rpc_close()當 ksmbd_iov_pin_rsp() 失敗時我們應呼叫 ksmbd_session_rpc_close()。 (CVE-2025-71220)

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

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

  - dpaa2-switch新增 IRQ 處理常式中 if_id 的邊界檢查。IRQ 處理常式會從硬體狀態暫存器的大寫 16 位元擷取 if_id並在不進行驗證的情況下使用它來對 ethsw->ports[] 建立索引。由於 if_id 可以是任何 16 位元值 (0-65535)但只以 sw_attr.num_ifs 元素配置連接埠陣列因此這可能會導致超出邊界讀取。存取陣列前新增邊界檢查與 dpaa2_switch_rx() 中的現有驗證一致。 (CVE-2026-23180)

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

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

  - 已解決 Linux 核心中的下列弱點：rust_binder: correctly handle FDA objects of length zero Fix a bug where an empty FDA (fd array) object with 0 fds would cause an out-of-bounds error. The previous implementation used `skip == 0` to mean this is a pointer fixup, but 0 is also the correct skip length for an empty FDA. If the FDA is at the end of the buffer, then this results in an attempt to write 8-bytes out of bounds. This is caught and results in an EINVAL error being returned to userspace. The pattern of using `skip == 0` as a special value originates from the C-implementation of Binder. As part of fixing this bug, this pattern is replaced with a Rust enum. I considered the alternate option of not pushing a fixup when the length is zero, but I think it's cleaner to just get rid of the zero-is-special stuff. The root cause of this bug was diagnosed by Gemini CLI on first try. I used the following prompt: > There appears to be a bug in @drivers/android/binder/thread.rs where > the Fixups oob bug is triggered with 316 304 316 324. This implies > that we somehow ended up with a fixup where buffer A has a pointer to > buffer B, but the pointer is located at an index in buffer A that is > out of bounds.
    Please investigate the code to find the bug. You may > compare with @drivers/android/binder.c that implements this correctly. (CVE-2026-23194)

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

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

  - cgroup/dmem避免集區 UAF 觀察到一個 UAF 問題錯誤KASAN工作 insmod/527 在位址 ffff888106715440 寫入大小為 8 的 page_counter_uncharge+0x65/0x150 大小為 8 的 CPU 4 UID0 PID 527 Comminsmod 6.19.0-rc7-next-20260129+ #11 受污染[O]=OOT_MODULE 呼叫追踪 <TASK> dump_stack_lvl+0x82/0xd0 kasan_report+0xca/0x100 kasan_check_range+0x39/0x1c0 page_counter_uncharge+0x65/0x150mem_group_uncharge_group_uncharge +0x1f/0x260 由工作 527 分配 由工作 0 釋放
    錯誤的位址屬於 ffff888106715400 處的物件該物件屬於大小為 512 的快取 kmalloc-512。錯誤位址位於已釋放的 512 位元組區域內 64 位元組 [ffff888106715400, ffff888106715600) 錯誤位址屬於實體頁面記憶體狀態繞過錯誤的位址
    ffff888106715300fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715380fc fc fc fc fc fc fc fc fc >ffff888106715400fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb ^ ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb在取消註冊其相關記憶體區域後，呼叫端會保留 。即使使用者仍保留集區的參照 (例如在 uncharge 作業完成之前)目前的實作仍會釋放集區。此修補程式會為每個集區新增參照計數器確保只有在集區的參照計數降為零時才釋放集區。 (CVE-2026-23195)

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

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

  - nvme-pci處理變更的裝置 dma 對應需求 dma_needs_unmap 的初始狀態可能為 false但在對應資料迭代器時變更為 true。啟用 swiotlb 就是其中一個可能變更結果的情況。nvme 驅動程式需要儲存已對應的 dma 向量以便稍後取消對應因此在反覆運算期間視需要進行配置而非假設一開始就已配置。這可修正當裝置 dma 取消對應需求在反覆過程中變更時存取未初始化的 dma_vecs 所發生的 NULL 解除參照。 (CVE-2026-23174)

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

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

  - mm、shmem防止截斷爭用時發生無限迴圈。當截斷大型交換項目時當項目的索引因為查閱對齊而不符合指定索引時shmem_free_swap() 會傳回 0。失敗遞補路徑會檢查項目是否跨越結束邊界並在發生情況時中止因此截斷不會清除非預期的項目或範圍。但是有一個狀況遭到忽略。當 `index` 指向大型交換項目的中間且該大型交換項目並未跨越結束邊界時find_get_entries() 會將該大型交換項目做為具有 `indices[0] 的批次中的第一個項目傳回` 等於 `index`。項目的基底索引將小於 `indices[0]`因此 shmem_free_swap() 會因為基底 < 索引檢查而失敗並傳回 0。程式碼接著會呼叫 shmem_confirm_swap()、取得順序、檢查其是否跨越 END 邊界 (但不會)並以相同索引重試。下一次重複使用相同索引時會在相同索引處再次尋找相同項目進而導致無限迴圈。透過向下取整索引重試來修正此問題若索引小於截斷範圍則中止。 (CVE-2026-23177)

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

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

  - platform/x86toshiba_haps修正新增/移除常式中的記憶體洩漏問題 toshiba_haps_add() 會在成功配置物件後傳回錯誤的情況下泄漏其所配置的 haps 物件。
    toshiba_haps_remove() 不會在清除 toshiba_haps 所指向的指標之前釋放該物件因此其變成無法存取的已配置記憶體。透過使用 devm_kzalloc() 配置有問題的記憶體解決這些記憶體洩漏問題。 (CVE-2026-23176)

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

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

  - smb/server修正 smb2_open() 中的 refcount 洩漏。ksmbd_vfs_getattr() 失敗時必須釋放 ksmbd_file 的參照計數。 (CVE-2025-71223)

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

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

  - riscv在推測情況下清理系統呼叫表格索引 系統呼叫編號是使用者控制的值用來對系統呼叫表格進行索引。邊界檢查後使用 array_index_nospec() 限制此值以防止推測超出邊界存取和後續的資料透過快取端通道洩漏。
    (CVE-2025-71203)

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

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

  - 已解決 Linux 核心中的下列弱點：binder: fix UAF in binder_netlink_report() Oneway transactions sent to frozen targets via binder_proc_transaction() return a BR_TRANSACTION_PENDING_FROZEN error but they are still treated as successful since the target is expected to thaw at some point. It is then not safe to access 't' after BR_TRANSACTION_PENDING_FROZEN errors as the transaction could have been consumed by the now thawed target. This is the case for binder_netlink_report() which derreferences 't' after a pending frozen error, as pointed out by the following KASAN report: ================================================================== BUG: KASAN:
    slab-use-after-free in binder_netlink_report.isra.0+0x694/0x6c8 Read of size 8 at addr ffff00000f98ba38 by task binder-util/522 CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_netlink_report.isra.0+0x694/0x6c8 binder_transaction+0x66e4/0x79b8 binder_thread_write+0xab4/0x4440 binder_ioctl+0x1fd4/0x2940 [...] Allocated by task 522: __kmalloc_cache_noprof+0x17c/0x50c binder_transaction+0x584/0x79b8 binder_thread_write+0xab4/0x4440 binder_ioctl+0x1fd4/0x2940 [...] Freed by task 488: kfree+0x1d0/0x420 binder_free_transaction+0x150/0x234 binder_thread_read+0x2d08/0x3ce4 binder_ioctl+0x488/0x2940 [...] ================================================================== Instead, make a transaction copy so the data can be safely accessed by binder_netlink_report() after a pending frozen error. While here, add a comment about not using t->buffer in binder_netlink_report(). (CVE-2026-23184)

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

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

  - i2cimx保留區塊資料長度處置程式中的錯誤狀態。區塊讀取傳回無效的長度零或 >I2C_SMBUS_BLOCK_MAX 時長度處置程式會將狀態設為 IMX_I2C_STATE_FAILED。不過i2c_imx_master_isr() 會無條件以 IMX_I2C_STATE_READ_CONTINUE 覆寫此項目造成無限讀取迴圈進而使緩衝區滿溢並造成系統當機。保護狀態轉換以保留長度處置程式設定的錯誤狀態。 (CVE-2026-23197)

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

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

  - spitegra210-quad保護 tegra_qspi_combined_seq_xfer 中的 curr_xfer curr_xfer 欄位是由 IRQ 處置程式在未保留以檢查傳輸是否進行中的鎖定的情況下讀取。清除合併序列傳輸迴圈中的 curr_xfer 時使用執行緒同步鎖定加以保護以防與中斷處理常式發生爭用。使用執行緒同步鎖定保護 tegra_qspi_combined_seq_xfer() 結束路徑的 curr_xfer 清除避免與讀取此欄位的中斷處理常式發生爭用情形。若無此保護機制IRQ 處置程式可能會讀取部分更新的 curr_xfer 值進而導致 NULL 指標解除參照或釋放後使用。 (CVE-2026-23202)

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

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

  - scsi目標iscsi修正 iscsit_dec_session_usage_count() 中的釋放後使用錯誤。在 iscsit_dec_session_usage_count() 中函式在保留 sess->session_usage_lock 時會呼叫 complete()。與連線使用量計數邏輯類似由 complete() 發出訊號的等候者 (例如工作階段釋放路徑中) 可立即喚醒並釋放 iscsit_session 結構。這會造成爭用情形目前執行緒可能嘗試在已解除配置的工作階段結構上執行 spin_unlock_bh()進而導致 KASAN slab-use-after-free。若要解決此問題請先釋放 session_usage_lock然後再呼叫 complete()以確保 sess 指標的所有解除參照在允許等候者繼續解除配置前完成。 (CVE-2026-23193)

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

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

  - HID: i2c-hid修正 i2c_hid_get_report() 中潛在的緩衝區溢位「i2c_hid_xfer」用來將資料的「recv_len + sizeof(__le16)」位元組讀入「ihid->rawbuf」。前者可來自 hidraw 驅動程式中的使用者空間且依預設僅以 HID_MAX_BUFFER_SIZE(16384) 為邊界 (除非我們也設定 `struct hid_ll_driver` 的 `max_buffer_size` 欄位而我們並未這樣做)。後者的大小在運行時間由您可在任何特定裝置上接收的不同報告類型的大小上限所決定而且可以是小很多的值。透過將 `recv_len` 截斷為 `ihid->bufsize - sizeof(__le16)` 來修正此問題。影響較小因為存取 hidraw 裝置需要 root 權限。 (CVE-2026-23178)

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

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

  - dpaa2-switch防止 num_ifs 為零時發生 ZERO_SIZE_PTR 解除參照。驅動程式會使用 kcalloc()將 ethsw->sw_attr.num_ifs 作為元素計數來為連接埠、FDB 和篩選器區塊配置陣列。當裝置報告零介面 (可能是因為硬體組態或韌體問題) 時kcalloc(0, ...) 會傳回 ZERO_SIZE_PTR (0x10) 而非 NULL。之後在 dpaa2_switch_probe() 中NAPI 初始化會無條件地存取 ethsw->ports[0]->netdev進而嘗試解除參照 ZERO_SIZE_PTR (位址 0x10)進而導致核心錯誤。新增檢查以確保擷取裝置屬性後num_ifs 大於零。如此可防止零大小配置及後續的無效指標解除參照。
    (CVE-2026-23206)

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

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

  - spitegra210-quad保護 IRQ 處置程式中的 curr_xfer 檢查。現在所有其他 curr_xfer 的存取作業皆已在鎖定下完成請使用執行緒同步鎖定保護 tegra_qspi_isr_thread() 中的 curr_xfer NULL 檢查。
    若無此保護可能會發生下列爭用CPU0 (ISR 執行緒) CPU1 (逾時路徑)
    ---------------- -------------------------------- if (!tqspi->curr_xfer) // 看到非 NULL spin_lock () tqspi->curr_xfer = NULL spin_unlock() handle_*_xfer() spin_lock() t = tqspi->curr_xfer // NULL ... t->len ... // NULL 解除參照透過此修補程式現在所有 curr_xfer 存取都會正確同步。雖然所有對 curr_xfer 的存取都是在鎖定下完成但在 tegra_qspi_isr_thread() 中它會檢查 NULL、 釋放鎖定並稍後在 handle_cpu_based_xfer()/handle_dma_based_xfer() 中重新取得。其間可能有更新其可造成 NULL 指標解除參照。若要處理此問題請在取得鎖定之後在處置程式內新增 NULL 檢查。這可確保在逾時路徑已清除 curr_xfer 的情況下處理常式會安全傳回而不會解除參照 NULL 指標。 (CVE-2026-23207)

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

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

  - ipv6當新增 IPv6 路由時清除 RTF_ADDRCONF syzbot 報告 fib6_add_rt2node() 中有核心錯誤時修正 ECMP 同級計數不符問題。 [0] 提交 f72514b3c569 (ipv6新增靜態路由時清除 RA 旗標) 引入了邏輯以在新增具有相同 nexthop 的靜態路由時清除現有路由中的 RTF_ADDRCONF。但是當現有路由具有閘道時這會造成問題。當從具有閘道的路由中清除 RTF_ADDRCONF 時該路由便符合 ECMP 條件即
    rt6_qualify_for_ecmp() 傳回 true。問題在於此路由從未新增至 fib6_siblings 清單。這會導致下列計數不相符- 透過反覆 fib6_next 鏈結計算的同胞計數其中包含新的符合 ECMP 資格的路由 - fib6_siblings 清單中的實際同胞其中不包含該路由 當新增後續的 ECMP 路由時fib6_add_rt2node() 因計數不符而命中 BUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings)。透過在現有路由沒有閘道時只清除 RTF_ADDRCONF 來修正此問題。沒有閘道的路由無論如何都不符合 ECMP 的條件 (rt6_qualify_for_ecmp() 需要 fib_nh_gw_family)因此清除其上的 RTF_ADDRCONF 是安全的且符合提交的原始意圖。 [0]net/ipv6/ip6_fib.c:1217! 的核心錯誤Oops無效 opcode0000 [#1] SMP KASAN PTI CPU0 UID0 PID6010 Commsyz.0.17 未受污染的 syzkaller #0 PREEMPT(完整) 硬體名稱 Google Google Compute Engine/Google Compute Engine、BIOS Google 2025 年 10 月 25 日 RIP 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217 [...] 呼叫追踪 <TASK> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532 __ip6_ins_rt net/ ipv6/route.c:1351 [內嵌] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946 ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571 inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c :577 sock_do_ioctl+0xdc/0x300 net/socket.c:1245 sock_ioctl+0x576/0x790 net/socket.c:1366 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl.c:597 [內嵌] __se_sys_ioctl+ 0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [內嵌] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2026-23200)

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

ID	名稱	嚴重性
299175	Linux Distros 未修補的弱點：CVE-2026-23136	medium
299174	Linux Distros 未修補的弱點：CVE-2026-23120	medium
299173	Linux Distros 未修補的弱點：CVE-2026-23151	medium
299172	Linux Distros 未修補的弱點：CVE-2026-23149	medium
299171	Linux Distros 未修補的弱點：CVE-2026-23122	medium
299170	Linux Distros 未修補的弱點：CVE-2026-23140	medium
299169	Linux Distros 未修補的弱點：CVE-2026-23121	medium
299168	Linux Distros 未修補的弱點：CVE-2026-23124	medium
299167	Linux Distros 未修補的弱點：CVE-2026-23168	medium
299152	Linux Distros 未修補的弱點：CVE-2026-23162	high
299151	Linux Distros 未修補的弱點：CVE-2026-23159	medium
299150	Linux Distros 未修補的弱點：CVE-2026-23156	high
299123	Linux Distros 未修補的弱點：CVE-2026-23199	medium
299122	Linux Distros 未修補的弱點：CVE-2026-23208	high
299121	Linux Distros 未修補的弱點：CVE-2026-23209	high
299120	Linux Distros 未修補的弱點：CVE-2026-23187	high
299119	Linux Distros 未修補的弱點：CVE-2026-23188	medium
299118	Linux Distros 未修補的弱點：CVE-2025-71204	medium
299117	Linux Distros 未修補的弱點：CVE-2026-23175	high
299116	Linux Distros 未修補的弱點：CVE-2026-23204	high
299115	Linux Distros 未修補的弱點：CVE-2026-23203	medium
299114	Linux Distros 未修補的弱點：CVE-2026-23185	high
299113	Linux Distros 未修補的弱點：CVE-2026-23183	medium
299112	Linux Distros 未修補的弱點：CVE-2026-23179	medium
299111	Linux Distros 未修補的弱點：CVE-2026-23189	medium
299110	Linux Distros 未修補的弱點：CVE-2025-71224	high
299109	Linux Distros 未修補的弱點：CVE-2026-23205	medium
299108	Linux Distros 未修補的弱點：CVE-2026-23192	high
299107	Linux Distros 未修補的弱點：CVE-2026-23210	medium
299106	Linux Distros 未修補的弱點：CVE-2026-23186	medium
299105	Linux Distros 未修補的弱點：CVE-2026-23196	medium
299104	Linux Distros 未修補的弱點：CVE-2025-71222	medium
299103	Linux Distros 未修補的弱點：CVE-2026-23201	medium
299102	Linux Distros 未修補的弱點：CVE-2025-71220	high
299101	Linux Distros 未修補的弱點：CVE-2026-23180	high
299100	Linux Distros 未修補的弱點：CVE-2026-23194	high
299099	Linux Distros 未修補的弱點：CVE-2026-23195	high
299098	Linux Distros 未修補的弱點：CVE-2026-23174	high
299097	Linux Distros 未修補的弱點：CVE-2026-23177	medium
299096	Linux Distros 未修補的弱點：CVE-2026-23176	medium
299095	Linux Distros 未修補的弱點：CVE-2025-71223	medium
299094	Linux Distros 未修補的弱點：CVE-2025-71203	high
299093	Linux Distros 未修補的弱點：CVE-2026-23184	high
299092	Linux Distros 未修補的弱點：CVE-2026-23197	medium
299091	Linux Distros 未修補的弱點：CVE-2026-23202	medium
299090	Linux Distros 未修補的弱點：CVE-2026-23193	high
299089	Linux Distros 未修補的弱點：CVE-2026-23178	high
299088	Linux Distros 未修補的弱點：CVE-2026-23206	medium
299087	Linux Distros 未修補的弱點：CVE-2026-23207	medium
299086	Linux Distros 未修補的弱點：CVE-2026-23200	medium

偵測

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

high

high

medium

medium

high

high

medium

high

medium

medium

medium

high

medium

high

medium

medium

medium

medium

medium

high

high

high

high

high

medium

medium

medium

high

high

medium

medium

high

high

medium

medium

medium