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

  - xdp：修正零拷貝框架佈局 xdp_convert_zc_to_xdp_frame（） 將 XSK 封包複製到 order-0 頁面中，並將PAGE_SIZE通告為其框架大小。它允許複製的框架佔據skb_shared_info所需的頁尾，即使元數據將幀標頭與數據包數據分開，也記錄零空間。
    因此，透過 cpumap 重新導向的AF_XDP零拷貝封包可能會使 skb 重疊skb_shared_info或將其放置在分配的頁面之外。將複製的版面配置限制為 SKB_WITH_OVERHEAD（PAGE_SIZE），並將中繼資料長度包含在框架餘量中。重新導向呼叫端已處理 NULL 轉換結果。錯誤：
    KASAN：任務 cpumap/1/map：1/146 在 addr ffff88800cf37004 處寫入大小為 4 的 KASAN：slab-out-of-bound skb_gro_receive s 呼叫追蹤：skb_gro_receive （net/core/gro.c：174） udp_gro_receive （net/ipv4/udp_offload.c：812） inet_gro_receive （net/ipv4/af_inet.c：1539） dev_gro_receive （net/core/gro.c：515） gro_receive_skb （net/core/gro.c：633） cpu_map_kthread_run （kernel/bpf/cpumap.c：395） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：164） ret_from_fork_asm （arch/x86/entry/entry_64.S：255） 核心錯誤 - 未同步： KASAN：panic_on_warn設定...（CVE-2026-81002）

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

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

  - platform/x86/amd/pmc：傳播 SMU 錯誤並驗證 S2D 位址 amd_stb_s2d_init（） 捨棄數個 S2D SMU 命令的傳回值。當 SMU 拒絕命令時 （例如 SMU cmd failed. err： 0xff），系統只會間接注意到失敗 （如果有的話），並報告為 -EIO，以掩蓋真正的錯誤。更嚴重的是，S2D_PHYS_ADDR_LOW/HIGH 傳回值被忽略，因此在失敗時 phys_addr_low/hi 保持未初始化狀態，並將組裝的位址直接傳遞給 devm_ioremap（）。當 SMU 將它們保留為零時，這會對應實體位址 0 並觸發 ioremap-on-RAM 警告：amd_pmc AMDI000B：00：SMU cmd 失敗。錯誤：0x0000000000000000 處的 RAM 上0xff ioremap - 0x0000000000ffffff 警告：arch/x86/mm/ioremap.c 處的 CPU：13 PID：4592：... 檢查每個 SMU 命令的傳回值並傳播它，並在呼叫 devm_ioremap（） 之前拒絕零實體位址。（CVE-2026-81016）

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

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

  - slip：修正 sl_sync（） 中的釋放後使用 slip_devs[] 儲存裸net_device指標，並且不參照它們。sl_sync（） 和 sl_alloc（） 會從 rtnl_lock（） 下的 slip_open（） 遍歷該表，而 sl_free_netdev（） 會刪除一個項目，sl_setup而 （） 會以 dev->priv_destructor 的形式安裝。priv_destructor 是從 netdev_run_todo（） 調用的，它故意在釋放 RTNL 信號燈的情況下運行，以便它可以在等待設備參照計數刪除時進入休眠狀態： /* 快照列表，允許以後的請求 */ list_replace_init（&net_todo_list， &list）;__rtnl_unlock（）;...如果 （dev->priv_destructor） dev->priv_destructor（dev）;/* slip_devs[i] = NULL */ if （dev->needs_free_netdev） free_netdev（dev）;... /* 免費網路裝置 */ kobject_put（&dev->dev.kobj）;因此，rtnl_lock（） 根本不會針對拆卸序列化 slip_open（）。sl_sync（） 可以在項目仍在發佈時載入 slip_devs[i]，並在 netdev_run_todo（） 執行析構函式並釋放裝置後取消參照它： CPU0 （slip_open） CPU1 （slip_close） unregister_netdev（） rtnl_unlock（） netdev_run_todo（） __rtnl_unlock（） rtnl_lock（） sl_sync（） dev = slip_devs[i] priv_destructor（dev） slip_devs[i] = NULL kobject_put（&dev->dev.kobj） /* 釋放 dev */ sl = netdev_priv（dev） if （sl->tty || sl->leased） /*釋放後使用 */ 錯誤： KASAN：sl_sync drivers/net/slip/slip.c：730 中的釋放後使用 [內聯] 錯誤：KASAN：slip_open+0xef4/0x1210 drivers/net/slip/slip.c：806 在 addr ffff8880712dac71 中讀取大小 1 由任務 syz-executor.2/6506 CPU：2 PID：6506 通訊：syz-executor.2 未受污染 6.1.134-syzkaller-00260-g0c8fc3469765 #0 硬體名稱：QEMU 標準 PC （i440FX + PIIX，1996），BIOS 1.12.0-1 04/01/2014 呼叫追蹤：sl_sync drivers/net/slip/slip.c：730 [內聯] slip_open+0xef4/0x1210 drivers/net/slip/slip.c：806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c：433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c：564 tiocsetd drivers/tty/tty_io.c：2428 [內聯] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c：2712 由任務 6502 分配： alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c：10719 sl_alloc drivers/net/slip/slip.c：756 [內嵌] slip_open+0x36d/0x1210 drivers/net/slip/slip.c：817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c：433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c：564 由任務 6497 釋放： device_release+0xa2/0x240 drivers/base/core.c：2507 kobject_put+0x179/0x280 lib/kobject.c：729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c：10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c：906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c：456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c：614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c：782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c：1860 提交 e58c19124189 （slip：
    修正釋放後使用 Read in slip_open） 修正了過時項目的不同來源 - slip_open（） 在註冊錯誤路徑上釋放它後留下的 slip_devs[] 裝置 - 並且沒有解決此爭用，這就是報告倖存下來的原因。請改為從 ndo_uninit 刪除項目。unregister_netdevice（） 呼叫ndo_uninit在 RTNL 下，在裝置排入 netdev_run_todo（） 佇列之前，因此 sl_sync（） 在保留 RTNL 時仍可以看到的項目屬於在刪除 RTNL 之前無法釋放的裝置。
    sl_free_netdev（） 僅保留 slip_open（） 錯誤路徑，其中 register_netdevice（） 可能在ndo_init之前失敗，然後也不會呼叫 ndo_uninit。為同一設備運行兩者都是無害的：
    這 ---truncated--- （CVE-2026-81001）

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

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

  - fbdev： omapfb： panel-dsi-cm： 註冊前初始化鎖定 display dsicm_probe（） 會在初始化 ddata->lock 之前註冊顯示。一旦 omapdss_register_display（） 發佈顯示，另一個消費者就可以到達 dsicm 回呼，該回呼會在該互斥尚未初始化時採用該互斥。在註冊顯示之前初始化互斥，讓已發佈的回呼一律看到有效的鎖定。（CVE-2026-89599）

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

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

  - lib/ucs2_string.c：修正 ucs2_strnlen（） 修補程式系列中的越界讀取 lib/ucs2_string.c：修正 ucs2_strnlen（） v2 中的越界讀取。本系列修正 ucs2_strnlen（） 中的差一越界讀取。
    第一個補丁是真正的修復，第二個補丁作為獎勵提供並修復了代碼縮排。此修補程式 （共 2 個）：ucs2_strnlen（） 會先檢查目前字元，然後再檢查呼叫端提供的長度上限。如果輸入在該範圍內未以 NUL 終止，則迴圈可以讀取超過限制一ucs2_char_t。在取消參照之前測試長度，以防止差一越界讀取。（CVE-2026-89726）

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

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

  - sunrpc：路由至 svc_pool_for_cpu（） 中的填入集區 svc_set_num_threads（） 會將要求的執行緒平均分散到服務的集區 （base = nrservs / sv_nrpools）。當服務執行的執行緒少於集區時 （例如，設定的執行緒少於主機在 pernode 或 percpu 模式下執行時具有 NUMA 節點的 nfsd），尾端集區將完全沒有執行緒。svc_xprt_enqueue（） 會從提供傳輸服務的 CPU 中選取集區、將傳輸排入該集區sp_xprts上的佇列，而且只會喚醒相同集區中的執行緒。每個執行緒都獨佔地服務自己的集區，因此登陸無執行緒集區的傳輸會在sp_xprts上排入佇列，而且永遠不會被挑選：連線無限期地停擺。
    讓 svc_pool_for_cpu（） 跳過目前沒有執行緒的集區，回退到下一個填入的集區。這會以 NUMA 位置換取工作實際得到服務的保證。sp_nrthreads僅在服務互斥下更新;此處的無鎖定讀取是盡力而為的路由提示，因此請使用 data_race（） 進行註釋。（CVE-2026-89549）

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

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

  - ocfs2： cluster：在 o2hb_region_pin（） 修補程式系列中按住 o2hb_live_lock 時不要休眠 ocfs2：
    叢集：o2hb_region_pin（） 修正，v2。本系列修正了 o2hb_region_pin（） 中的三個相關問題，所有問題都來自提交中的原始實作：58a3158a5d17 （ocfs2/cluster： Pin/unpin o2hb 區域）： 1） 它在持有 o2hb_live_lock （spinlock） 的情況下調用，但底層 configfs_depend_item（） 休眠（採用 inode rwsem 並固定檔案系統）。這會在CONFIG_DEBUG_ATOMIC_SLEEP下觸發 BUG。2） 當從 configfs drop_item回呼呼叫時，它會建立鎖定順序反轉：父inode_lock -> configfs 根inode_lock，這可能會與以 root -> 父級為目的的子系統取消註冊路徑鎖死。
    3） 如果固定在 o2hb_region_inc_user（） 中途失敗，則o2hb_dependent_users計數器會洩漏，並且部分固定區域永遠不會釋放，從而使活動訊號區域在後續掛載中不受保護。
    補丁 1 重新設計了 o2hb_region_pin（），以在每個休眠的 configfs_depend_item（） 調用中刪除o2hb_live_lock，並使用config_item引用來保持該區域在解鎖時保持活動狀態。修補程式 2 新增了一個 from_callback 參數，用於在從 configfs 上下文呼叫時選擇 configfs_depend_item_unlocked（），從而避免inode_lock巢狀結構。修補程式 3 修正了 o2hb_region_inc_user（） 中的錯誤路徑，以在失敗時取消固定和遞減計數器。此修補程式 （共 3 個）：o2hb_region_pin（） 一律會在保留o2hb_live_lock微調鎖定的情況下呼叫 （從 o2hb_region_inc_user（） 和 o2hb_heartbeat_group_drop_item（）），但它會呼叫 o2nm_depend_item（）
    -> configfs_depend_item（），它休眠：它固定 configfs 檔案系統並獲取 configfs 根 inode rwsem。在CONFIG_DEBUG_ATOMIC_SLEEP下，這會觸發： 錯誤：從 kernel/locking/rwsem.c 的無效上下文呼叫休眠函數 in_atomic（）： 1， ...名稱：mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ...
    ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super 重製 o2hb_region_pin（） 以一次釘選一個區域，並在睡眠通話中丟棄鎖定：在o2hb_live_lock下找到下一個符合條件的區域並進行config_item參考以使其保持活動狀態，放下鎖定，調用 o2nm_depend_item（），然後重新鎖定並記錄密碼。config_item_put（） 也會在釋放鎖定的情況下完成，因為 o2hb_region_release（） 也會獲得o2hb_live_lock並且可以休眠。解鎖時區域清單可能會變更，因此掃描會在每個圖釘之後從頂部重新開始。本機活動訊號仍僅釘選相符的區域;全域活動訊號會釘選所有符合資格的區域。取消釘選路徑不受影響：configfs_undepend_item（） 僅採用微調鎖，不會休眠。（CVE-2026-89491）

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

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

  - platform/chrome： sensorhub：繫結 EC 報告的感應器編號 每個 EC FIFO 事件都帶有一個 8 位元感應器編號 （>sensor_num內）。cros_ec_sensorhub_ring_handler（） 驗證 FIFO 事件計數、每次讀取計數和環界，但不驗證感測器編號，然後 cros_ec_sensor_ring_process_event（） 使用未選中來索引 sensorhub->batch_state[] - 僅分配 sensorhub->sensor_num 項目。sensor_num 或更大的感應器編號是 的 batch_state[]越界讀取和寫入。驗證環形處理常式中的感應器編號，其中每個事件都是從 EC 讀取，並在使用之前刪除格式錯誤的事件。（CVE-2026-81017）

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

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

  - HID：sony：修正驅動程式解除綁定時 ghl_poke_timer/ghl_urb 的 UAF 對於 GHL （Guitar Hero Live） 加密狗，sony_probe（） 會啟用定期計時器：ghl_magic_poke（） （計時器回呼） 提交 sc->ghl_urb，而 URB 完成 ghl_magic_poke_cb（） 會使用 mod_timer（） 重新設定計時器。sony_remove（） 使用 timer_delete_sync（） 耗盡計時器，然後使用 usb_free_urb（） 釋放 URB：timer_delete_sync（&sc->ghl_poke_timer）;
    usb_free_urb（sc->ghl_urb）;timer_delete_sync（） 不會封鎖重新布防，而且當 URB 在飛行中時，計時器不會擱置，因此同步處理刪除是無作業。刪除之後執行的 URB 完成會重新武裝計時器，而 usb_free_urb（） 只會卸除參考，它不會終止進行中的 URB。sc 使用 devm_kzalloc（） 分配，並在 sony_remove（） 返回時釋放，因此重新武裝的ghl_poke_timer（嵌入在 sc 中）然後在釋放的記憶體上觸發，這是計時器 softirq 的釋放後使用。這是斷開連接/rmmod 爭用。先毒害 URB，然後關閉計時器，然後釋放 URB。
    usb_poison_urb（） 會終止任何進行中的 URB 並永久拒絕進一步的提交，因此仍在擱置中的戳計時器無法在 timer_shutdown_sync（） 執行之前從視窗中的 ghl_magic_poke（） 重新提交 URB。usb_kill_urb（） 是不夠的：它只會取消正在進行的 URB，並在傳回後使其保持可提交狀態，因此擱置中的計時器可以重新提交它，並將新的 URB 置於釋放的 sc 上。
    然後，timer_shutdown_sync（） 會耗盡任何最後的回呼並阻止重新布防。探查錯誤路徑不受影響：只有在計時器布防之前才能到達。在 next-20260710 下透過 GHL PS4 加密狗的 dummy_hcd + 原始小工具模擬複製 （VID 0x1430 / PID 0x07bb）：hid-sony 綁定並布防戳計時器，戳 URB 在飛行中保持，驅動程式解除綁定（釋放 sc），然後釋放 URB。完成後會重新武裝釋放的 sc 上的計時器，重新武裝的計時器會在 ~8 秒後觸發： 錯誤：
    KASAN：ghl_magic_poke+0x98/0xb0 中的 slab-use-after-free 由任務 swapper/0/0 在 addr ffff88810b02fd50 讀取大小 8 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0 run_timer_softirq+0x173/0x2a0 由任務 169 分配：sony_probe 由任務 338 釋放：devres_release_group <- hid_device_remove （sony_remove） 在 0 秒前找到 （https://0sec.ai） 使用自動化來源分析。
    (CVE-2026-89625)

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

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

  - ecryptfs：將封包設定緩衝區大小傳遞至剖析器 ecryptfs_parse_packet_set（） 會收到檔案標頭的指標，但它會計算 PAGE_SIZE - 8 的剩餘封包緩衝區大小。針對版本 1 標頭，封包集會在標頭稍後開始，因此這可能會誇大可用的緩衝區。傳遞呼叫端的實際封包集緩衝區長度，並從該緩衝區中的剩餘位元組計算每個封包限制。在剖析下列標籤 11 封包之前，先重新計算取用標籤 3 封包後的剩餘長度。（CVE-2026-89608）

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

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

  - SUNRPC：等待正在進行的用戶端TLS交握回呼 xs_tls_handshake_sync（） 在提交交握要求之前，為 xs_tls_handshake_done（） 提供對較低傳輸的參照。在逾時或發出訊號時，同步服務程式會在呼叫 tls_handshake_cancel（） 之後捨棄該參照。
    當 handshake_req_cancel（） 已將請求標記為完成時，handshake_complete（） 傳回 false。在這種情況下，完成回呼仍然可以運行，因此在服務員中刪除回呼擁有的參照可以在 xs_tls_handshake_done（） 儲存xprt_err或丟棄自己的參照之前釋放較低的傳輸。如果取消無法完成，請等到 xs_tls_handshake_done（） 發出handshake_done信號，然後讓回呼釋放其參照。這會鏡像伺服器端交握存留期處理，並維持逾時或訊號傳回值不變。（CVE-2026-89536）

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

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

  - ipv6： rpl：修正 ipv6_rpl_srh_rcv（） 中 idev 的 NULL 解除參照 ipv6_rpl_srh_rcv（） 將 idev 從
    __in6_dev_get（） 讀取 idev->cnf.rpl_seg_enabled 時沒有 NULL 檢查。當裝置的 MTU 低於 IPV6_MIN_MTU 時，addrconf_ifdown（） 會透過 RCU_INIT_POINTER（） 清除 dev->ip6_ptr。然後，在 ip6_rcv_core（） 中通過 idev 檢查的封包可以到達 dev->ip6_ptr 已為 NULL 的 ipv6_rpl_srh_rcv（）。
    透過使用 ping6 流量淹沒接收介面，同時在 1500 到 1200 之間抖動其 MTU： 錯誤： KASAN：ipv6_rpl_srh_rcv+0xb3/0x1070 中的 null-ptr-deref 透過任務 ping6/394 在 addr 000000000000006b4 讀取大小 4 CPU：2 UID：0 PID：394 通訊：ping6 未受污染 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT（full） 呼叫追蹤： <IRQ> kasan_report+0xc6/0x100 ipv6_rpl_srh_rcv+0xb3/0x1070 ip6_protocol_deliver_rcu+0x759/0x9a0 ip6_input_finish+0xa8/0x1b0 ip6_input+0xe1/0x490 ipv6_rcv+0x33d/0x460 __netif_receive_skb_one_core+0xd6/0x130 process_backlog+0x2cc/0xa00 __napi_poll.constprop.0+0x56/0x270 net_rx_action+0x327/0x730 handle_softirqs+0x11e/0x630 do_softirq+0xb3/0xf0 </IRQ> ipv6_rpl_srh_rcv（） 和 ipv6_srh_rcv（） 都僅從 ipv6_rthdr_rcv（） 呼叫， 其中已經有 idev 查詢。在 RPL 路徑呼叫任一函式之前，先檢查 ipv6_rthdr_rcv（） 中的 idev，以修正 RPL 路徑上的空取消參照。被呼叫者將 idev 作為引數，不再呼叫 __in6_dev_get（），因此封包現在會丟棄在一個地方，兩條路徑上都有SKB_DROP_REASON_IPV6DISABLED。（CVE-2026-89561）

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

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

  - NFSD：修正 nfsd4_alloc_layout_stateid 中關於 Racing 委派撤銷的BUG_ON當父 stateID 是委派時，讀取 FP->fi_deleg_file 而不保留nfsd4_alloc_layout_stateid fi_lock 透過自助洗衣店撤銷並行委派可以清除fi_lock下的fi_deleg_file，導致 nfsd_file_get（） 傳回 NULL 並觸發BUG_ON。此爭用是用戶端可連線的：兩個 NFS 用戶端可以透過讓一個用戶端保留委派，而另一個用戶端開啟相同的檔案以強制召回來觸發它。當第一個客戶沒有回應召回時，自助洗衣店會撤銷它。來自任何使用委派 stateid 的用戶端的並行 LAYOUTGET 會命中爭用視窗。修正此問題時，請對SC_TYPE_DELEG路徑中讀取的fi_deleg_file進行fi_lock，比對 find_any_file（） 臂的鎖定紀律，並將BUG_ON取代為清除部分初始化版面配置 stateid 的正常錯誤傳回。（CVE-2026-89686）

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

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

  - forcedeth：修正儲存/還原非 PCI 組態空間時的差一錯誤 nv_suspend（） 和 nv_resume（） 使用 for （i = 0; i <= np->register_size/sizeof（u32）; i++） 遍歷非 PCI 組態空間，執行一次迭代次數過多。saved_config_space宣告為 u32 saved_config_space[NV_PCI_REGSZ_MAX/4];並且NV_PCI_REGSZ_VER3等於 NV_PCI_REGSZ_MAX （0x604），因此在 VER3 設備上，register_size/sizeof（u32） 正好是陣列長度，最後一次迭代尋址一個元素。它所在的元素是 np->name_rx[0..3]： saved_config_space[] 緊接著是 char name_rx[IFNAMSIZ + 3]，並且 char 不需要填充。任何可觀察的東西都不會因此而損壞，因為 nv_request_irq（） 在將 sprintf（） 傳遞給 request_irq（） 之前會用 sprintf（） 重寫name_rx。錯誤是越界存取本身，UBSAN 會報告該越界存取，並且 CONFIG_UBSAN_TRAP=y 會變成中止執行核心程式碼的陷阱，加上 MMIO 讀取，並在恢復時將 MMIO writel（） 寫入 base + 0x604，超出驅動程式映射的範圍一個 dword：np->base = ioremap（addr， np->register_size）;VER1 和 VER2 設備保留在陣列內，但它們也會獲得雜散讀取和雜散寫入一個 dword 通過自己的窗口。在深度 S3 週期中被 UBSAN 在 Apple Macmini3,1 （MCP79） 上捕獲。以下 splat 已修剪：檔案名稱中的構建路徑、CPU 和污點行、工作佇列行、？提示幀，device_suspend下面的幀都被剪掉了。內核被污染了，帶有一種新樹和CPU_OUT_OF_SPEC;forcedeth 本身就是庫存模塊。UBSAN： array-index-out-of-bounds 在 drivers/net/ethernet/nvidia/forcedeth.c：6225：25 中，索引 385 超出類型「u32 [385]」的範圍 呼叫追蹤：dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b
    __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... 兩個循環都被擊中。
    UBSAN 每次模組載入 （__ubsan_handle_out_of_bounds（） 呼叫 suppress_report（） 只會報告每個來源位置一次，這會在結構source_location上執行 test_and_set_bit（REPORTED_BIT， ...），因此兩個 splat 會在模組載入後的第一個 S3 週期中落地，並且後面的週期是靜默的，即使每次存取仍然從末端執行。在第一個週期中，第 6225 行從 pci_pm_suspend 報告，第 6240 行從 pci_pm_resume 報告。2012 年，透過提交 ba9aa134287f （forcedeth：修正緩衝區溢位） 在 nv_get_regs（） 中修正了相同的差一錯誤;這兩個循環被遺漏了。Marc Weber 於 2013 年 9 月在 LKML 上報告了暫停和恢復方面，具有相同的分析和相同的單字元修復，但補丁是附加的而不是內聯發送的，並且線程到此結束。使用 < 而不是 <=，這會儲存和還原 register_size 個位元組。（CVE-2026-89596）

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

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

  - mfd： qnap-mcu：在命令逾時後保持回覆緩衝區處於活動狀態 qnap_mcu_exec（） 會將堆疊上緩衝區發佈至接收路徑：unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];...回覆 >data = rx;reply->length = 長度;並且 qnap_mcu_receive_buf（） 從 serdev 接收路徑寫入其中，該路徑耗盡了 flush_to_ldisc（），並且根本不會針對 qnap_mcu_exec（） 進行序列化。bus_lock無法覆蓋它，因為 qnap_mcu_exec（） 跨 wait_for_completion_timeout（） 保留該互斥體。逾時時，qnap_mcu_exec（） 傳回 reply->data 仍指向自己的框架。然後，遲到的回覆或來自 MCU 的主動訊息會寫入已留下的堆疊框架中，從而損壞該堆疊上接下來執行的任何內容。當 qnap_mcu_write（） 失敗時，這同樣適用，因為該路徑返回時也不會觸及回覆狀態。將接收緩衝區移至結構qnap_mcu。它是 37 位元組，結構是 devm_kzalloc（）ed，因此它的存續時間與驅動程式一樣長，並且延遲寫入仍然有效的記憶體中，並由下一個命令重新初始化。bus_lock防止命令共用它。這會刻意不清除逾時路徑上的 reply->data 或 reply->length。這樣做會與 qnap_mcu_receive_buf（） 爭用，後者在其 if （！reply->length） 傳回大小之後讀取兩者;檢查：清除 reply->data 會提供 NULL 解除參照，而僅清除 reply->length 會移除 reply->received == reply->length 結束條件，因此複製迴圈會一直執行，直到 UART 區塊被消耗並溢出緩衝區為止。保留這兩個集合會使寫入受 reply->length 的限制，qnap_mcu_exec（） 已經根據 sizeof（mcu->rx） 檢查了該長度。
    (CVE-2026-80975)

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

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

  - PCI：plda：修正拆卸期間事件 IRQ 的釋放後使用 plda_pcie_irq_domain_deinit（） 透過 irq_domain_remove（） 移除 pcie->event_domain，但使用 plda_init_interrupts（） 中的 devm_request_irq（） 要求從該網域對應的每個事件 IRQ。devm 管理的 IRQ 的實際 free_irq（） 會由 devres 延遲，直到呼叫的 probe（）/remove（） 函式傳回之後。這表示 irq_domain_remove（） 可以在仍對應到網域的 IRQ 的延遲 free_irq（） 執行之前釋放網域的內部資料。當 devres 稍後處理延遲清除時，它最終可能會取消參照已釋放的網域。在移除網域之前，請使用 devm_free_irq（） 明確釋放每個事件 IRQ。這會立即觸發釋放，並從 devres 追蹤清單中移除 IRQ，因此 devres 稍後不會嘗試第二次釋放它。在移除事件、INTx 和 MSI IRQ 對應之前，請先將其與 irq_dispose_mapping（） 對應。最後，保護 pcie->irq、pcie->msi_irq 和 pcie->intx_irq 對 irq_set_chained_handler_and_data（） 的呼叫，以便它們僅在這些欄位保留有效 （>0） IRQ 編號時執行。這是一個預先存在的問題，在處理與此驅動程式不相關的早期修補程式期間，由自動檢閱標記。在 StarFive VisionFive v1.2A 板上進行構建測試和啟動測試 （CVE-2026-89455）

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

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

  - platform/x86/amd/pmc：修正 STB init 失敗時的 LPS0 和 debugfs 洩漏 amd_pmc_probe（） 向 acpi_register_lps0_dev（） 註冊 LPS0 s2idle 處理常式，並在呼叫 amd_stb_s2d_init（） 之前建立驅動程式的 debugfs 目錄，這是探測中可能失敗的最後一步。當 amd_stb_s2d_init（） 失敗時 （例如，無法在長時間執行的系統上對應 S2D 遙測區域，或 SMU 拒絕 S2D 設定），錯誤路徑只會呼叫 pci_dev_put（） 並傳回。這會將amd_pmc_s2idle_dev_ops留在全域lps0_s2idle_devops_head清單中，並洩漏 debugfs 目錄，同時支援處理常式的 devm 管理資源會被拆除。然後重新載入模組會在 acpi_register_lps0_dev（） 中遍歷損毀清單並點擊：list_add corruption。next->prev 應該是 prev，但為 NULL。lib/list_debug.c：29 的核心錯誤！acpi_register_lps0_dev+0x44/0x80 amd_pmc_probe+0x224/0x380 [amd_pmc] platform_probe+0x67/0x90 即使沒有重新載入，過時的註冊也意味著下一個 s2idle 轉換呼叫進入拆解的驅動程式狀態。還原 debugfs 目錄和 amd_stb_s2d_init（） 錯誤路徑上的 LPS0 註冊。在這裡無條件調用 acpi_unregister_lps0_dev（） 是安全的：它受到與 acpi_register_lps0_dev（） 相同的條件保護，這正是 amd_pmc_remove（） 已經依賴的。（CVE-2026-81015）

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

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

  - ocfs2：一律在寫入時複製完成時執行解除分配 本 6.12.94 機模糊測試發現下列記憶體洩漏是由在同一檔案系統內執行 'copy_file_range（）' 所造成： 未參照的物件0xffff88812192c980 （大小 32）： comm syz.0.49， pid 12095， jiffies 4294964143 hex dump （前 32 個位元組）： 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...！............回溯 （CRC 7068D63F）：kmemleak_alloc_recursive include/linux/kmemleak.h：42 [內聯] slab_post_alloc_hook mm/slub.c：4152 [內聯] slab_alloc_node mm/slub.c：4197 [內聯]
    __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c：4358 kmalloc_noprof include/linux/slab.h：878 [內嵌] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c：6618 [內嵌] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c：6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c：6819 [內嵌] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c：2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c：2779 [內嵌] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c：2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c：3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c：3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c：5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c：3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c：3131 [內嵌] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c：3255 [內嵌] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c：3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c：3427 [內嵌] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c：3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c：2340 [內嵌] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c：2451 iter_file_splice_write+0x890/0xf60 fs/splice.c：743 do_splice_from fs/splice.c：944 [內嵌] direct_splice_actor+0x232/0x480 fs/splice.c：1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c：1111 do_splice_direct_actor fs/splice.c：1210 [內嵌] do_splice_direct+0x10f/0x1c0 fs/splice.c：1236 do_sendfile+0x430/0xbf0 fs/read_write.c：1388 未參照的物件0xffff88812192c5c0（大小 32）：comm syz.0.49、pid 12095、jiffies 4294964143十六進位轉儲（前 32 個位元組）：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 00 ）頁..............回溯 （crc afec850f）： kmemleak_alloc_recursive include/linux/kmemleak.h：42 [內聯] slab_post_alloc_hook mm/slub.c：4152 [內聯] slab_alloc_node mm/slub.c：4197 [內聯] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c：4358 kmalloc_noprof include/linux/slab.h：878 [內聯] kzalloc_noprof include/linux/slab.h：1014 [內聯] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c：6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c：6819 [內聯] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c：2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c：2779 [內嵌] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c：2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c：3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c：3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c：5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c：3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c：3131 [內嵌] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c：3255 [內嵌] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c：3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c：3427 [內嵌] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c：3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c：2340 [內嵌] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c：2451 iter_file_splice_write+0x890/0xf60 fs/splice.c：743 do_splice_from fs/splice.c：9 ---truncated--- （CVE-2026-89496）

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

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

  - platform/x86： ISST：驗證效能遮罩 ioctls 中的層級 isst_if_get_perf_level_mask（） 和 isst_if_get_base_freq_mask（） 使用使用者提供的層級作為 via 的 perf_levels[] 索引
    _read_pp_level_info（） 和 _read_bf_level_info（），但這兩個協助程式都不會先驗證它。相鄰的層級資訊協助程式會在讀取相同的每個層級暫存器區塊之前，拒絕高於 max_level 的層級。將相同的邊界檢查新增至遮罩協助程式，並拒絕 isst_if_get_perf_level_mask（） 中停用的 SST-PP 層級以符合 isst_if_get_perf_level_info（）。這可防止在無效 ioctl 輸入上從每個層級位移資料表進行越界讀取。（CVE-2026-89443）

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

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

  - ALSA： aloop：在探測時檢查卡片索引有效性，aloop 驅動程式會盲目地信任指定的 devptr->id 值在探測時正確的卡片索引範圍內。驅動程式本身在模組探查時建立的裝置沒問題，但如果裝置是透過 sysfs 介面手動繫結，則可能是 -1 為無，這會導致 index[] 和其他參數的 OOB 存取。新增卡片索引的健全性檢查，並在值超出範圍時警告/更正。（CVE-2026-80972）

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

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

  - ring-buffer：修正 subbuf 與 ring_buffer_alloc_read_page（） 的大小爭用 ring_buffer_alloc_read_page（） 與 ring_buffer_subbuf_order_set 不合時宜，它可以配置具有過時順序的閱讀器頁面。這不是一個大問題，用戶仍然可以重新分配一個新的讀者頁面並重試。然而，更成問題的是，如果 subbuf_order 的值在 ring_buffer_alloc_read_page（） 中間發生變化。在此情況下， bpage->order 可能與實際配置的記憶體不符。針對分配使用 bpage->order 來防止此爭用。（CVE-2026-89503）

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

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

  - net/smc：修正 smc_rx_pipe_buf_release（） 中的釋放後使用 smc_rx_splice（） 將 RMB 頁面交給管道，並為每個條目獲取一個通訊端引用，以便 smc_sock 保持活動狀態，直到閱讀器完成。連線不會：並行關閉會執行 smc_conn_free（），這會將接收緩衝區釋放回連結群組集區。smc_rx_pipe_buf_release（） 測試sk_state，然後再進行通訊端鎖定。狀態可以在測試和鎖定之間更改，然後 smc_rx_update_cons（） 取消參照 conn->rmb_desc 並遍歷 conn->lgr，這是 smc_conn_free（） 已經發布的。在is_reg_err路徑上，smcr_buf_unuse（） 會直接釋放描述元，因此這是釋放後使用。先使用通訊端鎖定，然後改為測試 conn->freed。
    smc_conn_free（） 在釋放任何內容之前設定該標誌，並且每個呼叫者都持有通訊端鎖定。這兩個路徑會相互排除：管道版本會先執行且所有內容都有效，要麼看到旗標並略過更新。（CVE-2026-80982）

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

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

  - ecryptfs：傳送失敗時釋放訊息內容 ecryptfs_send_message_locked（） 會在將要求傳送至使用者空間精靈之前，將訊息內容從可用清單移至已分配清單。如果 ecryptfs_send_miscdev（） 失敗，上下文將保留在分配的清單中，無法重複使用。失敗時將其移回可用清單，並清除呼叫者的指標。（CVE-2026-89605）

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

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

  - NFSv4.1：修正 pnfs_layout_process（） 忘記路徑上的版面配置區段洩漏 當伺服器傳回新的版面配置 stateid 而有效的版面配置 stateid 仍保留時，pnfs_layout_process（） 會呼叫堆疊上 free_me 清單上的 pnfs_mark_matching_lsegs_return（） 並跳至out_forget。參照計數降至零的區段會從 lo->plh_segs 取消連結，並由 mark_lseg_invalid（） 移至 free_me;
    對於閒置的快取區段，版面配置標頭會保留唯一的參照，因此這會在第一次遞減時發生。out_forget絕不會耗盡free_me，只有成功路徑會呼叫 pnfs_free_lseg_list（）。提交 814b84971388 （pNFS/NFSv4：修正 pnfs_layout_process（）） 中的佈局區段洩漏，新增了 drain;提交 08bd8dbe8882 （pNFS/NFSv4：嘗試在 pnfs_layout_process（）） 中傳回無效的配置，在將目的地切換為 lo->plh_return_segs 時將其移除，該配置會在其他地方清空。提交 fb700ef02676 （NFSv4.1：簡化 pnfs_layout_process（） 中的配置返回） 已將目的地切換回 free_me，而不還原排空。還原 pnfs_free_lseg_list（） 呼叫。（CVE-2026-89710）

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

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

  - dm raid1：為 build_constructor_string（） 中的 NUL-terminator 保留空間 在長 long 值的最大 20 位十進制數字之後為終止 NUL 保留空間，以避免 sprintf（） 中的緩衝區溢位。
    (CVE-2026-89575)

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

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

  - SUNRPC：修正gssx_dec_option_array錯誤路徑錯誤 gssx XDR 選項陣列解碼器中的四個耦合缺陷使錯誤路徑變得不安全：調用方中的 NULL 解除參照、解碼group_info上的參照計數洩漏，以及洩漏修復原本會暴露的潛在釋放後使用。gssx_dec_option_array（） 在配置 oa->data 之前設定 oa->count = 1。如果該配置失敗，則會傳回 -ENOMEM，並帶有 oa->count == 1 和 oa->data == NULL。所有其他錯誤路徑都會跳至 free_oa：這會釋放 oa->data 並將其設為 NULL，但也會留下 oa->count == 1。調用方信任計數：gssp_accept_sec_context_upcall（） gssx_dec_accept_sec_context（） gssx_dec_option_array（） /* 失敗，count=1 data=NULL */ data = res.options.data[0].value /* NULL 解除參照 */ 獨立地，free_creds：釋放具有裸 kfree（creds） 的部分解碼svc_cred。gssx_dec_linux_creds（） 將 groups_alloc（） 結果安裝到 creds->cr_group_info;該物件由 kvmalloc 支援並被引用計數，並且只有 put_group_info（） 到達 kvfree（）。普通 kfree（creds） 會丟棄包裝器並洩露group_info分配。洩漏的自然修復方法是在 kfree（creds） 之前呼叫 free_svc_cred（creds），但 free_svc_cred（） 會在非 NULL 時無條件叫用 creds->cr_group_info 上的 put_group_info（）。gssx_dec_linux_creds（） 中現有的 out_free_groups： 路徑已經在該指標上呼叫了 groups_free（），但沒有清除它，因此一旦 free_svc_cred（） 被連接，後續的 put_group_info（） 將觸及釋放的記憶體。一起修正這四個：- 將 oa->count = 1 指派移至 oa->data 配置下方，以便在 oa->data 為 NULL 時永遠不會設定它。- free_oa時將 oa->count 重設為 0：因此計數和資料會保持一致，且呼叫端會看到空白的選項陣列。- 在 free_creds 處呼叫 kfree（creds） 之前呼叫 free_svc_cred（creds）：這樣就會釋放參照計數的cr_group_info。free_svc_cred（） 要麼明確地對每個欄位進行 NULL 保護（cr_group_info 有一個 if（） 檢查），要麼委派給一個本身是 NULL 安全的協助程式（字串欄位為 kfree，gss_mech_put（） 在 gss_mech_switch.c：342 使用 if（gm） 進行保護），因此調用部分解碼的svc_cred是安全的，其中僅寫入了 cr_uid/cr_gid/cr_group_info，而其他所有內容都來自 kzalloc 為零。- 在 gssx_dec_linux_creds（） 的 out_free_groups： 路徑中，使用 put_group_info（） 而不是 groups_free（） 釋放cr_group_info，以便拆卸符合 free_svc_cred（） 的 refcount-aware 路徑，並清除指標，以便相同 creds 上的後續 free_svc_cred（） 不會第二次釋放它。（CVE-2026-89544）

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

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

  - ipmi： si：修正註冊失敗後的 NULL 指標解除參照 try_smi_init（） 配置 new_smi->si_sm 和隨後的呼叫 ipmi_register_smi_mod（），對應至 ipmi_add_smi（）。在 ipmi_add_smi（） 期間，上層 IPMI 訊息處理常式會透過 __bmc_get_device_id（） 取得初始 BMC 裝置資訊。如果 BMC 未傳回對「取得裝置識別碼」命令的成功回應，則此操作可能會失敗。當 BMC 傳回非零完成碼時，device-id 協助程式會重試指令，如果仍無法擷取裝置 ID，則最終會傳回 -EIO。在此失敗路徑上，ipmi_add_smi（） 記錄無法取得裝置識別碼，並移至out_err_started，叫用較低驅動程式的關機回呼。然後try_smi_init（） 會記錄傳回的註冊失敗： ipmi_si IPI0001：00： IPMI 訊息處理常式： 無法取得裝置 ID： -5 ipmi_si IPI0001：00： 無法註冊裝置： 錯誤 -5 針對 ipmi_si，關機回呼為 shutdown_smi（），它會清理 SI 狀態機器資料、釋放 smi_info->si_sm，並將 smi_info->si_sm 和 smi_info->intf 設定為 NULL。但是，在此註冊失敗復原路徑上並未設定 intf->in_shutdown。因此，非同步 redo_bmc_reg 工作專案在較低驅動程式已清除其 SI 狀態機器資料之後，仍可重試 BMC 裝置識別碼探查。在觀察到的案例中，該重試路徑會到達 start_next_msg（），其將 NULL smi_info->si_sm 指標傳遞至選取的 KCS 狀態機器處理常式：
    錯誤：無法處理 0000000000000000000 處的核心 NULL 指標解除參照 工作佇列：事件redo_bmc_reg [ipmi_msghandler] RIP：start_kcs_transaction+0x2c/0x190 [ipmi_si] 呼叫追蹤：start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler]
    __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 在叫用較低驅動程式的關機回呼之前，在out_err_started路徑上設定 intf->in_shutdown。這可防止以後的redo_bmc_reg重試使用已清除較低驅動程式狀態的介面，並將相同的關機狀態也套用至其他 IPMI 介面。
    (CVE-2026-81005)

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

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

  - dm-pcache：綁定持久化尾部位置偏移 cache_pos_decode（） 從快取裝置獲取持久化的key_tail和dirty_tail seg_off，並使用它位址區段內。位於或經過區段data_size的seg_off可由提供裝置 （CAP_SYS_ADMIN） 的人員控制，讀取區段資料。拒絕不低於區段data_size的解碼seg_off。（CVE-2026-80959）

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

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

  - net：skbuff：不要觸碰 skb_tx_error（） 中的共用 ZeroCopy 狀態 skb_tx_error（） 會完成 ZeroCopy UAR 並清除 SKBFL_ALL_ZEROCOPY，而 skb_zcopy_downgrade_managed（） 會清除SKBFL_MANAGED_FRAG_REFS。兩者都位於 skb_shinfo（） 中，每個複製都共用該 ，而調用方僅擁有它即將刪除的參照。通過克隆，它告訴製作者它的頁面是免費的，並SKBFL_SHARED_FRAG為仍在飛行的 skb 丟棄。Open vSwitch 以非最後OVS_ACTION_ATTR_RECIRC達到此目的：clone_execute（） 將 skb_clone（） 發送到 ovs_dp_process_packet（），而 do_execute_actions（） 繼續轉發原始片段，並且 skb_clone（） 不會將此處的片段私有化 -- skb_orphan_frags（） 會在SKBFL_DONT_ORPHAN早期返回。然後，克隆上的流錯失會從仍在轉發的資料包中剝離標記，稍後的本地 ESP 傳遞會就地解密它不私有的片段。對於克隆的 skb，請跳過它。不會遺失任何內容：一旦共用資料的最後一次參照結束，skb_release_data（） 就會清除零複製狀態。（CVE-2026-80977）

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

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

  - platform/x86： hp-bioscfg：修正空密碼寫入時的堆積 OOB 讀取 validate_password_input（） 計算長度 = strlen（buf），然後檢查 buf[length - 1] 以去除尾端換行符，而不先檢查長度是否為非零。將空字串 （裸 '\n'） 寫入 current_password 或 new_password 會給出 length == 0，而 buf[length - 1] 會讀取 buf[-1]，這是保存複製輸入的堆積分配之前的一個位元組。KASAN 直接確認了這一點： 錯誤：KASAN：store_password_instance.constprop.0+0x223/0x2a0 中的 slab-out-of-bounds [hp_bioscfg] 任務 sh/13740 在 addr ffff88811bd8da9f 讀取大小 1 ...store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] current_password_store+0x14/0x20 [hp_bioscfg] ... 有錯誤的位址位於已分配的 8 位元組區域右側 23 位元組 [ffff88811bd8da80， ffff88811bd8da88） 透過 new_password_store 以相同方式複製。執行會在錯誤讀取之後繼續執行 （垃圾位元組只會影響長度是否遞減 1），因此寫入完成並傳回成功;這是通過緩衝區讀取的純資訊，而不是崩潰，但它仍然是 KASAN 正確標記的越界存取。透過在長度非零時僅檢查 buf[length - 1] 來修正。（CVE-2026-81013）

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

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

  - RDMA/ionic：在rdma_counter配置中內嵌計數器驅動程式資料 提交 7e53b31acc7f （RDMA/core：使用 rdma_zalloc_drv_obj（） 建立和銷毀rdma_counter） 需要實作計數器操作的驅動程式將結構rdma_counter內嵌在驅動程式特定的結構中、透過INIT_RDMA_OBJ_SIZE註冊其大小，並提供counter_init回呼。在沒有此調整的情況下合併了 ionic 驅動程式，導致 alloc_and_bind（） 中出現 NULL 指標解除參照，因為 rdma_zalloc_drv_obj（） 在未設定 size_rdma_counter 時會配置零位元組。將結構ionic_counter合併到嵌入結構rdma_counter的新結構ionic_rdma_counter中，將 xarray 替換為用於 ID 分配的輕量型 ida，並新增所需的 counter_init 和 INIT_RDMA_OBJ_SIZE 宣告。（CVE-2026-89509）

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

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

  - power： supply： lp8727：修正 lp8727_release_irq（） 中的釋放後使用 lp8727_isr_func（） 是執行緒 IRQ 處理常式，是唯一透過 schedule_delayed_work（） 啟用 pchg->work 的呼叫端。lp8727_release_irq（） 目前會在釋放 IRQ 之前取消工作，因此中間傳遞的 IRQ 可以透過執行緒處理常式重新武裝工作。傳回 .remove 後，devm 層會釋放 pchg，而 lp8727_delayed_func（） 仍可能運行並取消參照它。先釋放 IRQ，讓執行緒處理常式靜止，且無法再將工作排入佇列，然後取消延遲的工作以清空最後一代。此問題是由內部靜態分析工具發現的。（CVE-2026-89469）

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

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

  - power： supply： bq256xx：釋放充電器前排空 usb_work USB-PHY 通知程式會將 usb_work 排入佇列，其處理常式會呼叫 power_supply_changed（bq->charger）。重設 devm 動作只會取消註冊通知程式，且是在電源供應器之前註冊，因此 devm 會在動作執行前解除處理時釋放 bq->charger;
    然後，仍在佇列的usb_work可以取消參照它。在電源供應器之後註冊重設動作，以便在釋放電源供應器之前取消註冊通知程式並耗盡usb_work。在註冊通知程式之前，先初始化usb_work並取得 PHY 參照，因此背景工作程式無法在供應器存在之前執行。透過靜態分析找到。（CVE-2026-89474）

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

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

  - smack：修正 smack_file_send_sigiotask（） 中的 cred UAF 檢查另一個任務的憑證時，必須始終使用目標憑證 （->real_cred，透過 __task_cred（）） 存取。除非正在建立或銷毀該任務，否則禁止在非目前任務上存取 ->cred;允許任務在不同步的情況下更改自己的 ->cred 指標，並且更改 ->cred 應該只會影響當前的 syscall。smack_file_send_sigiotask（） 正在存取兩組憑證：首先是 tsk->cred，然後是
    __task_cred（嘖嘖）。修復它，始終在此處訪問客觀憑據。我已經測試過，此錯誤可能會導致 KASAN 報告的 smack_file_send_sigiotask（） 中結構信用的 UAF，並且此修復可以防止爭用。（CVE-2026-80928）

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

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

  - NFSD：在管理員狀態撤銷期間防止用戶端釋放後使用 stateid 僅包含指向其nfs4_client的裸指標;stateid 參照不會釘選它。用戶端之所以能夠存續，只是因為 __destroy_client（） 會在 free_client（） 執行之前耗盡其 stateid。nfsd4_revoke_states（） 會刪除 revoke_one_stid（） 中的 nn->client_lock，這會取消參照用戶端以撤銷 stateid 並讀取 clp->cl_minorversion。對掉落的鎖進行拆卸可以先釋放用戶端。將cl_rpc_users釘選在client_lock下會阻止DESTROY_CLIENTID和EXCHANGE_ID拆卸，當cl_rpc_users為非零時，拆卸會拒絕。
    force_expire_client（） 會忽略它：一旦等待 cl_rpc_users 達到零，後面的 PIN 就會被忽視。在 client_lock 下，跳過cl_time已經為零的用戶端 -- force_expire_client（） 在等待之前將其清除 -- 否則在刪除鎖定之前固定cl_rpc_users。然後，遍歷要么看到到期並跳過，要么及時釘選等待以涵蓋撤銷。（CVE-2026-89660）

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

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

  - media：staging/ipu7：修正探測錯誤路徑上的非同步通知程式 UAF isys_register_devices（） 透過 isys_notifier_init（） 註冊 V4L2 非同步通知程式。如果後續探查步驟 （例如 isys_fw_log_init（） 失敗，isys_probe（） 會跳轉至僅呼叫 isys_unregister_devices（） 的out_cleanup標籤。該協助程式會拆除視訊裝置、子裝置、V4L2 裝置和媒體裝置，但絕不會取消註冊或清理非同步通知程式。因此，通知程式在全域notifier_list中保持鏈結狀態，而封閉的結構ipu7_isys被 devres 釋放，導致清單損毀和下次遍歷清單時釋放後使用。移除路徑已經透過在 isys_unregister_devices（） 之前呼叫 isys_notifier_cleanup（） 來執行正確的操作。將其鏡像到探查錯誤路徑上，以便在拆除裝置之前取消註冊並清理通知程式。（CVE-2026-89522）

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

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

  - sunrpc：修正 __rpc_clnt_handle_event 和 __rpc_clnt_remove_pipedir 中的釋放後使用 正常的用戶端建立會透過 rpc_setup_pipedir（），其中會記錄 clnt->pipefs_sb，但
    __rpc_clnt_handle_event（） 直接呼叫 rpc_setup_pipedir_sb（），並且永遠不會重新整理該欄位。卸載路徑也會移除目錄，而不清除 clnt->pipefs_sb。在延遲 pipefs 掛載或任何重新掛載之後，rpc_clnt_remove_pipedir（） 會將目前的超級區塊與過時的 pipefs_sb 指標進行比較並跳過清理，留下 pipefs dentry 的 inode 私有資料仍指向釋放的 rpc_clnt，從而導致在後續 rpc_info_open（） 或 rpc_show_info（） 呼叫期間可能發生釋放後使用。請在裝載事件時正確更新 clnt->pipefs_sb，並在卸載或失敗路徑期間清除它，以修正此問題。
    (CVE-2026-89543)

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

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

  - erofs：調整大小時跳過足夠大的全域緩衝區z_erofs_gbuf_nrpages只有在每個全域緩衝區都增長後才會前進。如果在某些緩衝區擴大之後調整大小失敗，則重試會重新造訪那些擴大的緩衝區。重試相同大小會傳回 -ENOMEM，因為 alloc_pages_bulk（） 沒有要新增的頁面，且未變更的傳回值會被視為失敗。重試中間大小會配置一個小於 gbuf->nrpages 的臨時指標陣列，並複製比陣列可以容納的更多現有指標。略過已滿足要求的緩衝區。一旦所有剩餘的緩衝區都趕上，前進z_erofs_gbuf_nrpages會再次描述整個集區的保證最小大小。
    (CVE-2026-89602)

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

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

  - bpf：當計算的點陣圖達到U32_MAX後援案例時，32 位元核心 bloom_map_alloc（） 上的強化布隆篩選大小調整和索引有兩個 32 位特定問題。首先，使用 32 位算術評估 BITS_TO_BYTES（U32_MAX）。DIV_ROUND_UP 執行的新增會換行，因此對應只會配置固定大小的 bloom 篩選物件，同時保留 bitset_mask == U32_MAX。然後，後續更新可以寫入已分配的物件。其次，僅固定分配大小是不夠的。布隆哈希是 u32，但 set_bit（） 採用帶正負號的長位數，x86 test_bit（） 最終將索引饋送給 variable_test_bit（long， ...）。因此，在 32 位元核心上，[0x80000000， U32_MAX] 中的雜湊會變成負位元位移。具有記憶體運算元的 x86 BT/BTS 會解譯這些相對於提供的基數的偏移量，因此具有 bitset_mask == U32_MAX 的對應可以在 bloom->bitset 之前讀取或寫入，即使在配置完整的 512 MiB 點陣圖之後也是如此。保留U32_MAX後援，但在調用 test_bit（） 或 set_bit（） 之前，將每個哈希拆分為字指標和字內位號。然後，bitops 引數一律位於 [0， BITS_PER_LONG - 1] 中，而 BIT_WORD（h） 仍會在完整點陣圖中選取預期的單字。從 （u64）bitset_mask + 1 計算位集大小，然後再將最終大小傳遞給 bpf_map_area_alloc（）。這會修正原始配置不足的問題，並使配置的儲存體與可定址位元集保持一致。利用說明：
    在 32 位元 x86 核心上，使用具有 CAP_BPF 的二進位檔中的配置不足錯誤，可能會發生本機權限提升。（CVE-2026-89579）

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

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

  - ipmi：註冊失敗時移除所有 sysfs 檔案 ipmi_add_smi（） 會在嘗試建立 maintenance_mode 檔案之前建立nr_users和nr_msgs檔案。如果上次建立失敗，錯誤路徑只會移除 nr_users，然後再捨棄介面的最終參照。同時移除nr_msgs，以便內嵌在釋放介面中的 sysfs 屬性不會保持註冊狀態。（CVE-2026-81006）

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

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

  - 之前 29.0.3在 OpenStack Keystone 中發現問題。透過委派的驗證方法 （EC2 憑證、應用程式憑證、OAuth1 存取權杖和信任） 取得的權杖不會被封鎖，無法透過 /v3/credentials API 建立、修改或刪除憑證。EC2 衍生的權杖還可以讀取憑證 blob，從而公開 TOTP MFA 種子和其他密碼。此外，PATCH /v3/credentials 不會驗證要求的更新後project_id，因此允許任何委派的權杖將憑證移至未經授權的專案。所有使用委派驗證的Keystone部署都會受到影響。
    (CVE-2026-90460)

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

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

  - net/smc：修正 smc_switch_conns（） 中的通訊端參照計數洩漏 smc_switch_conns（） 在丟棄 lgr->conns_lock 之前對 SMC 通訊端進行參照，因此在擷取 CDC 插槽時連線保持活動狀態：
    sock_hold（&smc->sk）;read_unlock_bh（&lgr->conns_lock）;/* send_lock 之外的預先擷取緩衝區，可能會休眠 */ rc = smc_cdc_get_free_slot（conn， to_lnk， &wr_buf， NULL， &pend）;if （rc） 轉至err_out;err_out標籤只會刪除wr_tx連結參照，因此此提前退出會傳回，而不會產生相符的 sock_put（）。第二個錯誤結束程式不受影響，因為此時 sock_put（） 已執行。洩漏的sk_refcnt意味著smc_sock永遠不會被破壞。其傳送和接收緩衝區會保持配置狀態，而且針對使用者通訊端，永遠不會釋放網路命名空間上保留的參照，因此無法再拆除 netns。
    當目標鏈路關閉或交換器進行時連線被終止時，smc_cdc_get_free_slot（） 會失敗。在此功能實作的連結容錯移轉期間，兩者皆可連線，因此洩漏是由最初執行 smc_switch_conns（） 的相同硬體事件觸發的。
    重組，以便有一個 sock_put（） 涵蓋這兩個結果，而不是將第二個結果新增至錯誤路徑。(CVE-2026-80983)

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

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

  - nfsd：在所有 nfsd_dispatch（） 退出路徑上將rq_status_counter還原為偶數 nfsd_dispatch（） 在要求被解碼後rq_status_counter為奇數值，並在完全處理後返回為偶數值，從而形成類似 seq-lock 的協議，與 nfsd_nl_rpc_status_get_dumpit（） 中的無鎖讀取器。只有完全成功的路徑才能將計數器恢復為偶數。快取命中 （RC_REPLY）、刪除 （RC_DROPIT / RQ_DROPME） 和編碼錯誤路徑都在奇數值儲存區之後返回，而不會使計數器恢復偶數。一旦採用其中一條路徑，rq_status_counter就會保持奇數：下一個請求的解碼 OR 為 1（仍然是奇數），只有後續成功的編碼才會恢復偶數。當停滯在奇數時，dumpit 讀取器會將 rqstp 欄位視為穩定，且其重試檢查會與相同的不變奇數值進行比較，因此永遠不會偵測並行突變。這會將主動變異的欄位（例如，複合解碼和釋放期間的 args->ops / args->opcnt）暴露給無鎖定讀取器，該讀取器可以讀取超過 8 元素內嵌操作陣列的末尾。新增協助程式，將計數器推進至下一個偶數值，並在奇數值存放區之後的每個傳回路徑上呼叫它。解碼錯誤路徑在計數器設定為奇數之前到達時保持不變。（CVE-2026-89705）

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

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

  - accel/rocket：修正 rocket_job_push（） 中的 NULL 解除參照和整數溢位 rocket_job_push（） 配置一個臨時陣列來保存所有輸入和輸出 GEM 物件指標：bos = kvmalloc_array（job->in_bo_count + job->out_bo_count， sizeof（void *）， GFP_KERNEL）;memcpy（bos， job->in_bos， job->in_bo_count * sizeof（void
    *));memcpy（&bos[job->in_bo_count]， job->out_bos， ...）;存在兩個錯誤：1.缺少NULL檢查：如果kvmalloc_array（）失敗，則bos為NULL，後續的memcpy（）對其進行解除參照，導致核心NULL指標解除參照。2. 整數溢位：in_bo_count 和 out_bo_count 都是 u32，直接從使用者空間提供的 in_bo_handle_count 中設定，並且out_bo_handle_count，無需事先驗證。它們的總和以 u32 算術計算，可以換行為較小的值，導致傳遞給 kvmalloc_array（） 的分配計數小於預期。後續使用在複製和鎖定物件時仍會對原始計數進行操作，這可能會導致臨時陣列的越界存取。透過在配置之前使用 check_add_overflow（） 偵測計數溢位，並在配置結果上新增 NULL 檢查來修正。（CVE-2026-89592）

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

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

  - i3c：瑞薩電子：在存取傳輸之前檢查傳輸是否有效 瑞薩電子 I3C 驅動程式使用非同步模型來傳輸資料。它會準備一個結構renesas_i3c_xfer，將其排入佇列，然後等待完成。中斷處理常式會將傳輸出列、更新/使用傳輸，並向等候執行緒發出訊號。
    如果完成逾時，等候執行緒會將傳輸出列並釋放它。如果在此之後觸發中斷，處理常式可能會存取釋放的記憶體，進而導致損毀。在中斷處理常式中存取傳輸之前，請先檢查傳輸是否仍然有效。有了它，可以清除所有狀態標誌並停用所有中斷，以避免再次觸發相同的中斷。（CVE-2026-80950）

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

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

  - ring-buffer：使用 subbuf_order 釋放 cpu_buffer：：free_page 當子緩衝區使用大於 0 的階數時，會配置 cpu_buffer->free_page 並搭配 subbuf_order。對cpu_buffer>free_page使用正確的順序。
    (CVE-2026-89502)

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

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

  - HID： universal-pidff：當強制回饋初始化失敗時停止裝置 universal_pidff_probe（） 會使用 hid_hw_start（） 啟動裝置，然後，如果強制回饋初始化失敗，則透過僅傳回錯誤的標籤傳回錯誤。裝置保持啟動狀態。HID 核心不會代表駕駛員展開。__hid_device_probe（） 釋放 devres 群組、關閉報告並清除 hdev->driver： if （ret） { devres_release_group（&hdev->dev， hdev->devres_group_id）; hid_close_report（hdev）;
    hdev->driver = 空;} 透過 hid_connect（） 註冊的 hid_hw_start（） 的 hidraw 字元裝置是使用 kzalloc（） 分配的，並使用 cdev_device_add（） 新增，因此它不是 devres 管理並繼續存在。
    當 hdev->driver 為 NULL 時，hid_device_remove（） 也會略過 hid_hw_stop（），因為它只會在驅動程式仍附加時展開。因此，註冊的壽命比兩條路徑上的裝置都長。開啟倖存的 /dev/hidrawX 會寫入釋放的記憶體。KASAN 報告來自 hidraw_open（） 的釋放後使用寫入
    -> hid_hw_open（） ->傳輸的開啟回呼，該回呼在釋放的物件內採用微調鎖定。帶有 PID 使用頁面且沒有輸入報告的描述符就足夠了：hidraw 聲明設備，因此 hid_hw_start（） 成功，而 hid->inputs 保持空白，因此強制反饋 init 失敗。其他失敗會在 hid_pidff_init_with_quirks（） 中傳回 - 無輸出報告、分配失敗、pidff_init_fields（）、pidff_check_autocenter（）、無法使用的效果計數、input_ff_create（） - 都到達相同的標籤。停止該路徑上的裝置。hid-dr.c 和 hid-emsff.c 已執行此動作，它們會以相同的 HID_CONNECT_DEFAULT &; ~HID_CONNECT_FF遮罩啟動裝置。前面的兩個 goto 必須在沒有 hid_hw_stop（） 的情況下繼續返回，因為兩者都沒有啟動的裝置，因此請為啟動後失敗的路徑提供自己的標籤。由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-89624）

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

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

  - 計時：檢查 __do_adjtimex（） 中 tk_get_aux_ts64 的傳回值 如果在 tk_get_aux_ts64（） 期間停用了輔助時鐘，但在檢查 tks->clock_valid 之前啟用了輔助時鐘，則計算中將使用未初始化的堆疊資料，並間接洩漏到使用者空間。在此更改之後，核心計時員也存在相同的比賽窗口。但在這些情況下，唯一的影響是不正確的調整，這是用戶空間的責任來避免這種情況。（CVE-2026-80927）

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

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

  - nfsd：在 nfsd_proc_setattr（） 中為提前驗證的 SETATTR 新增 fh_want_write（） BOTH_TIME_SET 分支會提前呼叫 fh_verify（），以便 setattr_prepare（） 可以檢查 dentry。這會導致 nfsd_setattr（） 跳過 fh_want_write（），因此 notify_change（） 在沒有掛載寫入參照的情況下運行。在早期 fh_verify（） 之後新增缺少的 fh_want_write（） 呼叫。（CVE-2026-89697）

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

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

  - 跟蹤/user_events：在分支複製之前清除複製的跟蹤狀態 dup_task_struct（） 將user_event_mm從父項複製到子項，而不獲取對它的引用。user_event_mm_dup（） 應該取代它，但如果 user_event_mm_alloc（） 失敗，它會保持複製的指標不修改。當子項退出時，user_event_mm_remove（） 會遞減子項從未擁有的參照，最終釋放user_event_mm，而父項仍作為該參照的過時指標。這會建立一個 UAF，KASAN 報告為： 錯誤：KASAN：current_user_event_mm+0x51/0x1d0 中的 slab-use-after-free 透過任務 init/44 在 addr ffff888005010d30 寫入大小 4 呼叫追蹤： <TASK> kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 current_user_event_mm+0x51/0x1d0 user_events_ioctl+0x82e/0x15c0 __x64_sys_ioctl+0x139/0x1c0 do_syscall_64+0xce/0x450 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由任務 44 分配：
    __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x180/0x3a0 user_event_mm_alloc+0x3c/0x1f0 current_user_event_mm+0x88/0x1d0 由工作 42 釋放：__kasan_slab_free+0x43/0x70 kfree+0x13a/0x390 process_one_work+0x696/0xf90 worker_thread+0x420/0xba0 此修正只會在任何可能的失敗之前清除複製的指標。如果失敗了，孩子就沒有什麼可以釋放的。（CVE-2026-89750）

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

ID	名稱	嚴重性
345226	Linux Distros 未修補弱點：CVE-2026-81002	critical
345225	Linux Distros 未修補弱點：CVE-2026-81016	high
345224	Linux Distros 未修補弱點：CVE-2026-81001	high
345223	Linux Distros 未修補弱點：CVE-2026-89599	high
345222	Linux Distros 未修補弱點：CVE-2026-89726	high
345221	Linux Distros 未修補弱點：CVE-2026-89549	high
345220	Linux Distros 未修補弱點：CVE-2026-89491	medium
345219	Linux Distros 未修補弱點：CVE-2026-81017	high
345218	Linux Distros 未修補弱點：CVE-2026-89625	high
345217	Linux Distros 未修補弱點：CVE-2026-89608	high
345216	Linux Distros 未修補弱點：CVE-2026-89536	critical
345215	Linux Distros 未修補弱點：CVE-2026-89561	high
345214	Linux Distros 未修補弱點：CVE-2026-89686	critical
345213	Linux Distros 未修補弱點：CVE-2026-89596	high
345212	Linux Distros 未修補弱點：CVE-2026-80975	high
345211	Linux Distros 未修補弱點：CVE-2026-89455	high
345210	Linux Distros 未修補弱點：CVE-2026-81015	high
345209	Linux Distros 未修補弱點：CVE-2026-89496	high
345208	Linux Distros 未修補弱點：CVE-2026-89443	high
345207	Linux Distros 未修補弱點：CVE-2026-80972	high
345206	Linux Distros 未修補弱點：CVE-2026-89503	high
345205	Linux Distros 未修補弱點：CVE-2026-80982	high
345204	Linux Distros 未修補弱點：CVE-2026-89605	high
345203	Linux Distros 未修補弱點：CVE-2026-89710	medium
345202	Linux Distros 未修補弱點：CVE-2026-89575	medium
345201	Linux Distros 未修補弱點：CVE-2026-89544	high
345200	Linux Distros 未修補弱點：CVE-2026-81005	medium
345199	Linux Distros 未修補弱點：CVE-2026-80959	high
345198	Linux Distros 未修補弱點：CVE-2026-80977	high
345197	Linux Distros 未修補弱點：CVE-2026-81013	high
345196	Linux Distros 未修補弱點：CVE-2026-89509	medium
345195	Linux Distros 未修補弱點：CVE-2026-89469	high
345194	Linux Distros 未修補弱點：CVE-2026-89474	medium
345193	Linux Distros 未修補弱點：CVE-2026-80928	high
345192	Linux Distros 未修補弱點：CVE-2026-89660	critical
345191	Linux Distros 未修補弱點：CVE-2026-89522	high
345190	Linux Distros 未修補弱點：CVE-2026-89543	high
345189	Linux Distros 未修補弱點：CVE-2026-89602	high
345188	Linux Distros 未修補弱點：CVE-2026-89579	high
345187	Linux Distros 未修補弱點：CVE-2026-81006	high
345186	Linux Distros 未修補弱點：CVE-2026-90460	high
345185	Linux Distros 未修補弱點：CVE-2026-80983	medium
345184	Linux Distros 未修補弱點：CVE-2026-89705	high
345183	Linux Distros 未修補弱點：CVE-2026-89592	medium
345182	Linux Distros 未修補弱點：CVE-2026-80950	high
345181	Linux Distros 未修補弱點：CVE-2026-89502	high
345180	Linux Distros 未修補弱點：CVE-2026-89624	high
345179	Linux Distros 未修補弱點：CVE-2026-80927	medium
345178	Linux Distros 未修補弱點：CVE-2026-89697	critical
345177	Linux Distros 未修補弱點：CVE-2026-89750	high

偵測

Nessus 的 Misc. 系列

critical

high

high

high

high

high

medium

high

high

high

critical

high

critical

high

high

high

high

high

high

high

high

high

high

medium

medium

high

medium

high

high

high

medium

high

medium

high

critical

high

high

high

high

high

high

medium

high

medium

high

high

high

medium

critical

high