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

  - ip：在多點傳送轉送 IPv4 和 IPv6 輸入之前，孤立的預先擷取 skb 會保留 bpf_sk_assign（） 安裝的 skb->sk 關聯，以便本機傳送可以使用 RCU 下選取的通訊端。這兩個位址系列也可以預先擷取 UDP 早期解復用程式中的通訊端。在這兩個路徑 （BPF 和 UDP 早期解復用） 中，不保證在通訊端上保留參照。當組播封包無法在本機傳遞時，IPv6 會將原始 skb 交給 ip6_mr_input（）。IPv4 的 ip_mr_input（） 在不需要本機傳送時，同樣會保留原始 skb。任一路徑都可以將skb放在未解析的組播路由佇列上，或在接收端RCU部分結束後轉發。預先擷取的通訊端被破壞後，稍後的 skb 釋放會叫用 sock_pfree（） 並取消參照過時的 skb->sk。在每個非本機多點傳播轉送路徑之前孤立 skb。本地交付保留原始skb;現有的 skb_clone（） 呼叫會以無通訊端複製的方式提供多點傳播轉送。（CVE-2026-89564）

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

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

  - svcrdma：在 rdma_destroy_id svc_rdma_free（） 在拆卸之前快取 rdma->sc_cm_id->device 之前重新排序rpcrdma_rn_unregister，然後呼叫 rdma_destroy_id（sc_cm_id） 以釋放cm_id。
    rpcrdma_rn_unregister（） 接著，但在這兩個呼叫之間，傳輸的sc_rn項目仍安裝在裝置的rd_xa中。並行ib_unregister_device遍歷可以針對現在釋放的sc_cm_id分派 svc_rdma_xprt_done（）。將 rpcrdma_rn_unregister（） 移動到 rdma_destroy_id（） 之前，以便在它引用的cm_id被破壞之前從 xarray 中刪除傳輸的通知項目。也請使用 NULL 檢查來保護sc_cm_id解除參照：下列修補程式引入了以 sc_cm_id == NULL （接聽程式建立失敗，ADDR_CHANGE取代失敗） 到達 svc_rdma_free（） 的路徑。（CVE-2026-89535）

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

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

  - HID： roccat：破壞裝置 roccat_report_event（） 時釋放緩衝報告會使用 kmemdup（） 複製每個報告，並將分配儲存在循環緩衝區插槽中。只有在重複使用該插槽時，才會釋放分配。裝置銷毀路徑會釋放結構roccat_device，而不會釋放仍儲存在 cbuf[] 中的報告。這使得這些分配無法連線，並且每個裝置最多會洩漏 ROCCAT_CBUF_SIZE 個報告緩衝區。新增小型析構函式，在釋放裝置之前釋放每個緩衝報表，並在可損毀已註冊裝置的兩個路徑中使用它。（CVE-2026-89627）

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

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

  - ext2：修正 IS_SYNC inode ext2_setsize（） 和 ext2_xattr_set2（） 的遺失 inode 更新，其結構如下：
    if （IS_SYNC（inode）） { sync_inode_metadata（inode， 1）; } else { mark_inode_dirty（inode）; } 這會導致丟失 IS_SYNC inode 的 inode 更新，因為 sync_inode_metadata（） 僅在 inode 已經是髒的時才會執行任何操作，因此 inode 更新可能會丟失。透過無條件地將 inode 標記為髒並*然後*呼叫 sync_inode_metadata（） 來解決問題。（CVE-2026-89601）

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

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

  - 跟蹤：修正簡單環形緩衝區讀取器交換 simple_ring_buffer_swap_reader_page（） 中的重試耗盡，重試次數設定為 8 開始，只有在連結更換失敗後才遞減。在最後一次嘗試中，成功的替換會使重試為零，而失敗的替換會使重試為 -1。目前的 ！retry 測試會反轉這兩個結果。它在成功最終替換後傳回錯誤，使連結更新完成，但讀者簿記未完成。在最終更換失敗之後，它會掉落並更新頭部和讀取器指標，就像更換成功一樣，這可能會損毀環。僅將負計數器視為耗盡，並傳回記錄的 -EBUSY 錯誤。
    (CVE-2026-89748)

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

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

  - w1： ds28e17：拒絕 I2C 區塊上的超大長度讀取 w1_f19_i2c_master_transfer（） 是 DS28E17 1-Wire 轉 I2C 橋接器的master_xfer。在讀取I2C_M_RECV_LEN時，它會從裝置取得長度。下游從屬在 buf[0] 中放置一個長度位元組。然後驅動程式使用 w1_f19_i2c_read（） 將該數量的位元組讀取到 buf[1] 中。BUF[0] 由裝置控制，可以是 0 到 255。w1_f19_i2c_read（） 僅拒絕零計數。呼叫端緩衝區為 I2C_SMBUS_BLOCK_MAX + 2，因此為 34 位元組。長度高於 32 會使讀取超出它，最多約 222 位元組越界。SMBus 核心確實會檢查 buf[0] 與 I2C_SMBUS_BLOCK_MAX。該檢查會在master_xfer傳回後執行。到那時寫入已經完成。
    i2c-algo-bit 會在複製之前拒絕過大的長度，並傳回 -EPROTO。在兩個RECV_LEN位點拒絕高於 I2C_SMBUS_BLOCK_MAX 的長度，就像 i2c-algo-bit 一樣。（CVE-2026-80931）

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

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

  - net/smc：綁定 SMC-Rv2 LLC 訊息中的對等 rkey 計數 在裝置具有 max_recv_sge == 1 的鏈路上，沒有共用 v2 接收緩衝區，並且 smc_llc_save_add_link_rkeys（） 從佇列項目內嵌訊息開頭的 44 位元組開始獲取 v2 副檔名：ext = （struct smc_llc_msg_add_link_v2_ext
    *）（llc_msg + SMC_WR_TX_SIZE）;項目是 72 位元組的分配，延伸模組從位移 68 開始，因此位移 94 處的 ext->num_rkeys 已經過去了它。無論對等體傳送什麼，每次新增 SMC-Rv2 連結時都會發生這種情況： [ 2.490065] 錯誤：KASAN：smc_llc_save_add_link_rkeys+0x333/0x350 中的 slab-out-of-bounds [2.490431] 任務 smctest/106 在 addr ffff8880056406de 讀取大小 2 [ 2.490709] [ 2.490792] CPU：0 UID：
    0 PID： 106 Comm： smctest 未受污染 7.2.0-rc5-p1-g77a5d9d9c99f #32 PREEMPT（lazy） [ 2.490795] 硬體名稱：QEMU Ubuntu 24.04 PC v2 （i440FX + PIIX， arch_caps fix， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.490798] 呼叫追蹤： [ 2.490803] <TASK> [ 2.490805] dump_stack_lvl+0x53/0x70 [ 2.490810] print_report+0xd0/0x630 [ 2.490828] ？ __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.490832] ？ smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490834] kasan_report+0xce/0x100 [ 2.490836] ?smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490837] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490839] ？ smcr_buf_map_lgr+0x1bf/0x2b0 [ 2.490844] smc_llc_cli_add_link+0xca7/0x1e80 [ 2.490848] ？ smc_llc_wait+0x355/0x810 [ 2.490850] ？ __pfx_smc_llc_wait+0x10/0x10 [ 2.490851] ？
    __pfx_smc_llc_cli_add_link+0x10/0x10 [ 2.490853] ？ __pfx_autoremove_wake_function+0x10/0x10 [ 2.490863]
    __smc_connect+0x3f5c/0x4980 [ 2.490873] ？ __pfx_kernel_connect+0x10/0x10 [ 2.490888] ？
    __pfx___smc_connect+0x10/0x10 [ 2.490891] ？ release_sock+0x148/0x1d0 [ 2.490894] smc_connect+0x42c/0x580 [2.490896] __sys_connect+0xfc/0x130 [ 2.490898] ？ __pfx___sys_connect+0x10/0x10 [ 2.490900] ？ handle_mm_fault+0x1a1/0x430 [ 2.490908] __x64_sys_connect+0x6d/0xb0 [ 2.490909] ？ fpregs_assert_state_consistent+0x56/0xe0 [ 2.490917] do_syscall_64+0xf9/0x540 [ 2.490921] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.490924] RIP：0033：0x421bb4 [ 2.490927] 代碼：ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d ad 34 09 00 00 74 13 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 55 [ 2.490929] RSP：
    002b：00007ffd473b01a8 EFLAGS：00000202 ORIG_RAX：000000000000002a [ 2.490935] RAX：ffffffffffffffda RBX：
    00000000000000000 RCX：00000000000421bb4 [ 2.490936] RDX：0000000000000010 RSI：00007ffd473b01d0 RDI：
    0000000000000003 [ 2.490937] RBP： 0000000000003930 R08： 0000000000000004 R09： 00000000000000000 [ 2.490938] R10： 00007ffd473b0f98 R11： 0000000000000202 R12： 0000000000000006 [ 2.490939] R13： 00007ffd473b0f87 R14：
    0000000000000003 ： 00007ffd473b0f90 [ 2.490940] [ 2.4995452.490941] </TASK> [ ] 由作業 44 分配： [2.499693] kasan_save_stack+0x33/0x60 [ 2.499860] kasan_save_track+0x14/0x30 [ 2.500026]R15
    __kasan_kmalloc+0x8f/0xa0 [ 2.500190] __kmalloc_cache_noprof+0x158/0x370 [ 2.500393] smc_llc_enqueue+0x72/0x560 [ 2.500559] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.500747] tasklet_action_common+0x20f/0x8a0 [ 2.500945] handle_softirqs+0x18e/0x590 [ 2.501115] do_softirq+0x3b/0x60 [ 2.501266] __local_bh_enable_ip+0x61/0x70 [ 2.501446] __alloc_skb+0x732/0x890 [ 2.501604] rxe_init_packet+0x16b/0x4f0 [ 2.501783] prepare_ack_packet+0xb8/0x830 [ 2.501962] rxe_receiver+0x495/0x96e0 [ 2.502125] do_work+0x144/0x470 [ 2.502269] process_one_work+0x633/0x1030 [2.502450] worker_thread+0x45b/0xd10 [ 2.50261 ---truncated--- （CVE-2026-80986）

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

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

  - fuse：透過堆疊緩衝區複製要求標頭以進行 io-uring fuse-io-uring 傳輸將 req->in.h 複製到 fuse_uring_copy_to_ring（） 中的環，並將 req->out.h 複製回 fuse_uring_commit（） 中的環。這兩個標頭都位於 fuse_request slab 物件中，其快取 （fuse_req_cachep） 是在沒有使用者複製白名單的情況下建立的，因此將它們直接複製到使用者空間/從使用者空間複製會CONFIG_HARDENED_USERCOPY和恐慌： usercopy：
    從 SLUB 物件「fuse_request」（位移 56，大小 40）偵測到核心記憶體暴露嘗試！mm/usercopy.c：102 的核心錯誤！哎呀：無效的操作碼：0000 [#1] SMP KASAN NOPTI RIP：0010：usercopy_abort （mm/usercopy.c：90） 呼叫追蹤：__check_heap_object （mm/slub.c：8268） __check_object_size （mm/usercopy.c：197 mm/usercopy.c：258 mm/usercopy.c：223） copy_header_to_ring （fs/fuse/dev_uring.c：618） fuse_uring_prepare_send （fs/fuse/dev_uring.c：776 fs/fuse/dev_uring.c：785） fuse_uring_send_in_task （fs/fuse/dev_uring.c：1306） tctx_task_work_run （io_uring/tw.c：96）task_work_run （kernel/task_work.c：233） io_run_task_work （io_uring/tw.h：84） io_cqring_wait （io_uring/wait.c：278） __do_sys_io_uring_enter （io_uring/io_uring.c：2685） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） 透過堆疊上複製將兩個標頭退回，以便使用者複製接觸堆疊記憶體， 而不是樓板物件。（CVE-2026-80946）

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

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

  - fsnotify：在並行標記更新之後修正過時的物件遮罩 當標記取得新的事件位時，如果快取的彙總已包含該位，fanotify 和 inotify 可能會避免重新計算物件遮罩。
    這是由相同聯結器上另一個標記的並行更新所觸發的重新計算。
    並行掃描可以在新增位元之前讀取標記，而更新程式會在掃描發佈結果之前讀取舊的彙總。然後，更新程式會跳過重新計算，掃描會發佈不含位元的遮罩，在兩次更新完成後，物件遮罩仍會過時。這可以透過兩個 fanotify 群組監視同一個 inode 來重現：一個執行緒從一個現有標記中刪除FAN_MODIFY，而另一個執行緒將FAN_MODIFY新增至另一個標記。在兩個 fanotify_mark（） 呼叫傳回之後，寫入可能無法為其標記現在包含位元的群組產生FAN_MODIFY。這是在未修改的 v6.12.95 核心上重現的。等效的 inotify 交錯會遺失IN_MODIFY事件。
    對於正常的 fanotify 新增，請在原始標記遮罩變更時重新計算。一般遮罩不會以非同步方式清除，因此未變更的新增不會引入遺漏的興趣。始終重新計算忽略遮罩更新，因為FS_MODIFY處理可能會清除忽略遮罩而不進行標記>鎖定，從而使快照比較不可靠。更新現有的 inotify 手錶後，請務必重新計算。其取代路徑會暫時將標記>遮罩設定為零，因此即使舊遮罩和最終遮罩相等，並行掃描也可以觀察到零。直接指派替換遮罩可以避免暫時零，但現有的監視更新並不頻繁，因此無條件重新計算會更簡單。（CVE-2026-89595）

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

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

  - RDMA/uverbs：在沒有method_elm的情況下保護舊版軟體組 舊版 write（） 路徑透過uverbs_api_write_method分派，但傳遞給提供者程式碼的uverbs_attr_bundle沒有 ioctl 方法元素。如果格式錯誤的提供者輸入導致常見的 uverbs 驗證程式碼發出錯誤訊息，則 uverbs_get_handler_fn（） 會取消參照未初始化的method_elm指標。明確初始化舊版套件組合的method_elm，並在沒有 ioctl 方法時使 uverbs_get_handler_fn（） 傳回 NULL。舊版分派器會繼續使用其本機寫入方法，而 ioctl 路徑會繼續使用已註冊的 ioctl 處理常式。（CVE-2026-89505）

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

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

  - power： supply： charger-manager：在公開 sysfs 之前註冊穩壓器 charger_manager_remove（） 和 err_reg_extcon 探測錯誤路徑 在拆除 power_supply sysfs 項目 （power_supply_unregister（）） 之前，使用 regulator_put（） 釋放每個充電器穩壓器。charger_manager_remove（） 也會在 regulator_put（） 迴圈之後呼叫 try_charger_enable（cm， false）。對位於 regulator_put（） 和 power_supply_unregister（） 之間的充電器externally_control sysfs 屬性的並行寫入可以執行 charger_externally_control_store（） 並調用 try_charger_enable（），當啟用充電時，會取消參照已釋放的消費者控制碼。啟用收費時，.remove（） 中的 try_charger_enable（cm， false） 也會直接解除參照釋放的控點。兩者都留下了釋放後使用窗口。對稱地，probe 會在取得調節器 （regulator_get，在 charger_manager_register_extcon 內） 之前註冊 sysfs 項目 （power_supply_register），因此使用者空間可以在調節器可用之前到達externally_control。在同步/非同步邊界上分割 charger_manager_register_extcon（）：
    charger_manager_get_regulators（） （僅限 regulator_get，沒有非同步生產者） 現在在 power_supply_register（） 之前運行，因此 sysfs 在監管機構可用之前不會上線，並且 charger_manager_register_extcon（） 僅保留 extcon 通知程式/工作設置，仍在 power_supply_register（） 之後，因此 power_supply_register（） 故障無法到達 extcon 設置。這可讓 sysfs 設定/拆卸順序保持對稱，而不會在先前的探查錯誤路徑上引入非同步生產者。在兩個拆卸路徑上，將 power_supply_unregister（） 和 try_charger_enable（cm， false） 移動到 regulator_put（） 迴圈前面，並調整err_reg_extcon （power_supply_unregister（） 然後對 regulator_put（） 進行 err_regulator，get_regulators會在自身失敗時自行復原）。這不會解決相同控點的個別 extcon-notifier 驅動解除參照問題，這需要自己的同步設計。由內部靜態分析工具發現。（CVE-2026-89472）

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

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

  - 還原媒體：v4l2-dev：修正 __video_register_device（） 中的錯誤處理 這會還原提交 2a934fdb01db6458288fc9386d3d8ceba6dd551a。該補丁的意圖是好的，但它不起作用。這個想法是，如果device_register失敗，您必須執行put_device，讓 ref 計數器釋放資源。但是，V4L2 API 表示，如果 video_register_device（） 失敗，則您必須調用 video_device_release（），它會對 video_device 結構進行 kfree（）。但 put_device（） 已經釋放了結構，因此您最終會陷入雙重釋放的場景中。如果不將 video_register_device（） 分成兩部分，一部分初始化所有內容，另一部分執行實際device_register，然後將所有 V4L2 驅動程式轉換為這個新模型，就沒有一個好方法來解決這個問題。這是一項艱鉅的工作，device_register失敗的可能性很小。因此，與其最終陷入雙重釋放的情況，不如恢復此補丁，在這種情況下，我們將出現少量記憶體洩漏。這要強大得多。（CVE-2026-89741）

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

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

  - wifi：rtw88：修正 rtw_txq_push_skb（） 中潛在的記憶體洩漏 當函數失敗時，傳遞給 rtw_hci_tx_write（） 的 skb 預計會被釋放，但 rtw_txq_push_skb（） 中的錯誤路徑不會在返回之前釋放 skb。這可能會導致 rtw_txq_push（） 中出現記憶體洩漏，其中出佇的 skb 會傳遞給 rtw_txq_push_skb（）。（CVE-2026-80941）

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

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

  - power： supply： bq24257：修正 remove 時的釋放後使用 STAT-pin 中斷是由 devm 管理，因此它會保持布防狀態，直到 remove（） 之後執行的 devm 清理作業傳回為止。remove（） 取消 bq->iilimit_setup_work，而執行緒處理常式仍可觸發;該處理常式會重新排程工作並取消參照 bq，因此一旦 devm 釋放 bq，工作就會針對釋放的記憶體執行。使用 devm_delayed_work_autocancel（） 將延遲的工作設為裝置管理，並在中斷要求之前註冊。然後，devm 清理會先釋放中斷，因此處理常式無法再重新排程工作，並在釋放 bq 之前取消工作。不再需要 remove（） 中的明確 cancel_delayed_work_sync（），並且會被刪除。透過靜態分析找到。（CVE-2026-89475）

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

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

  - mm/mempolicy：將對開本排入佇列時，略過不存在的 PMD 修補程式系列 mm：處理遍歷回呼中的裝置私有 PMD，v3。由於提交 368076f52ebe （mm/huge_memory：將裝置私有 THP 支援新增至 PMD 作業），每當 HMM 型 GPU 驅動程式透過 migrate_vma_pages（） 將匿名 THP 對開本移轉至裝置記憶體時，PMD 可能會保留裝置私有交換項目。這類 PMD 的 pmd_trans_huge_lock（） 會成功 （pmd_is_huge（） 針對任何不存在、非無大型 PMD 傳回 true），因此過去假設存在 THP 或移轉項目的數個 MM 遍歷回呼現在可以使用裝置專用 PMD 來存取。結果範圍從偵錯核心上的 VM_BUG_ON（） 觸發，到虛假 vmemmap 解除參照的哎呀，再到在別名情況下無訊息地從 LRU 隔離不相關的即時作品集。此修補程式 （共 3 個）：queue_folios_pmd（） 在 pmd_trans_huge_lock（） 下調用，其 pmd_is_huge（） 檢查會針對任何不存在、非無 PMD 軟葉傳回 true。將這樣的 PMD 傳遞給 pmd_folio（） 會將軟葉編碼視為硬體 PFN，並可以傳回虛假的對開指標。鏡像 queue_folios_pte_range（）：在查詢對開本之前處理不存在的項目。將移轉項目計為失敗，但略過其他不存在的 PMD，例如裝置私有項目。潛在觸發程序：以 HMM 為基礎的 GPU 驅動程式會透過 migrate_vma_pages（） 將匿名 THP 作品集移轉至裝置記憶體，留下裝置私有 PMD。然後，使用者空間會在該範圍內呼叫 mbind（）、migrate_pages（） 或 set_mempolicy_home_node（）。（CVE-2026-89758）

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

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

  - sched_ext：不要在 process_deferred_reenq_users scx_bpf_dsq_reenq（） 佇列中BUG_ON已銷毀的 DSQ，而是從 run_deferred（） 而不是 ops.dispatch（） 執行的延遲 reenq （dru）。如果 DSQ 在 dru 執行之前遭到破壞，則 process_deferred_reenq_users（） 會看到 dsq->id == SCX_DSQ_INVALID 並命中BUG_ON。
    destroy_dsq（） 不會排清擱置的 drus，所以直接跳過。tj：使用 READ_ONCE（） 讀取 dsq->id 一次。在 INVALID 檢查和 BUG_ON 中單獨讀取它會留下一個窗口，其中 destroy_dsq（） 可以使兩次讀取之間的 ID 無效，但仍會觸發BUG_ON。CVE-2026-89516

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

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

  - iommu/msm：註冊失敗時的還原探查狀態 msm_iommu_probe（） 會在新增 IOMMU sysfs 裝置並向 IOMMU 核心註冊之前，將其 devm 管理的 IOMMU 物件新增至 qcom_iommu_devices。如果 iommu_device_sysfs_add（） 失敗，探查會傳回物件仍處於qcom_iommu_devices狀態。然後，驅動程式核心會釋放 devm 配置，留下一個懸空的清單項目，稍後的清單遍歷可能會取消參照。如果 iommu_device_register（） 失敗，則會保留相同的懸置清單項目，並且 sysfs 裝置也會保持註冊狀態。在對應的失敗路徑上，以反向設定順序展開 sysfs 裝置和全域清單項目。（CVE-2026-89452）

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

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

  - md/raid10：修正 raid10_sync_request（） 中反轉的still_degraded提交 fe6a19d40ceb （md/md-bitmap：
    將 md_bitmap_start_sync（） 合併到 bitmap_operations） 將 still_degraded 從 int 轉換為 bool，但反轉了迴圈中的賦值，該迴圈檢查陣列在恢復當前設備後是否仍會降級：still_degraded = 1 變為 still_degraded = false。因此，在另一個鏡像仍遺失時復原裝置會呼叫具有 degraded == false 的 md_bitmap_start_sync（），這會清除仍然遺失的裝置所需的點陣圖位元。重新新增該設備時，其基於點陣圖的恢復會找到已清除的位，並跳過陣列降級時寫入的每個區域，因此在保存過時數據時將其標記為In_sync：無訊息損毀。Reproducer （raid10 near=2， 4 個磁碟， 內部點陣圖）： - 失敗並移除每個鏡像配對的一個磁碟 - 寫入降級陣列 - 重新新增兩個磁碟並讓復原完成 - 檢查報告 mismatch_cnt=262272 在 256 MiB 降級寫入後，檔案內容不同;第二個磁碟的復原會在毫秒內完成，因為所有內容都被跳過了 raid1 中的相同轉換正確了 （still_degraded = true）。還原正確的值。
    (CVE-2026-89558)

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

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

  - power： supply： qcom_battmgr：修正 PMIC GLINK 服務啟動時enable_work釋放後使用 qcom_battmgr_pdr_notify（） 佇列，worker 透過 container_of（） 還原 battmgr 以發出韌體請求。
    PMIC GLINK 用戶端會保留在用戶端清單上，直到其 devres 釋放動作執行為止，因此 PDR 通知可以繼續將工作排入佇列，且擱置中或執行中的背景工作者可以在 devres 釋放 battmgr 之後存取它。使用 devm_work_autocancel（） 使enable_work裝置管理，在配置 PMIC GLINK 用戶端之前註冊。然後，devres 清除會先釋放用戶端，因此沒有進一步的通知可以將工作排入佇列，並在釋放 battmgr 之前取消工作。此問題是由內部靜態分析工具發現的。（CVE-2026-89467）

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

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

  - nilfs2：修正截斷後 nilfs_direct_propagate 中的 slab-out-of-bounds Shuangpeng Bai 報告 KASAN 在測試期間偵測到 nilfs_direct_propagate（） 中的 slab-out-of-bounds 錯誤。分析顯示，截斷檔案後，B樹根正下方的節點區塊並未被刪除。相反，它以髒狀態保留在 B 樹節點快取中。記錄寫入器隨後偵測到此區塊，並在其上錯誤地叫用了 nilfs_direct_propagate（），其設計目的是僅處理直接對應中的資料區塊。快取中的 B 樹節點由虛擬區塊編號管理，其邏輯金鑰通常超出直接映射預期的範圍。因此，將此類節點處理為直接對應項目會觸發 slab-out-of-bounds 存取。根本原因是，當 B 樹映射在截斷過程中折疊成直接映射時，根節點指向的中間節點區塊會被當作垃圾留下，而不是被明確刪除。這會透過新增 nilfs_btree_discard（） 作業來在轉換期間刪除剩餘的中間節點區塊來解決問題。「變形」旗標會新增至bop_delete介面，以明確表示刪除是對應轉換的一部分。
    這可讓 B 樹狀結構對應實作對剩餘節點結構執行必要的清除和捨棄，否則這些結構在轉換後會變成孤立。（CVE-2026-89723）

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

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

  - ceph：在解鎖期間釋放的工作階段上修正 check_new_map（） 中的 UAF check_new_map（） 會反覆運算 mdsc->sessions[]，並針對每個作用中工作階段捨棄 mdsc->mutex 以執行每個工作階段作業。強制關閉路徑 （從映射中移除的排名） 在釋放 mdsc->mutex 之前，會透過 ceph_get_mds_session（） 正確地對 s 進行參照，但其他三個路徑則不然： 路徑 A （位址變更）： mutex_unlock mutex_lock（&s->s_mutex） 路徑 B （重新連接）： mutex_unlock send_mds_reconnect（mdsc， s） 路徑 C （主動轉換）： mutex_unlock mutex_lock（&s->s_mutex） 如果沒有額外的參照， 另一個線程可以在解鎖窗口期間獲取 mdsc->mutex，調用 __unregister_session（） 刪除 S 上的最後一個引用，並釋放它。然後原始執行緒透過 s->s_mutex 存取釋放的記憶體。透過在每個mutex_unlock之前新增 ceph_get_mds_session，在對應的mutex_lock之後新增 ceph_put_mds_session，以符合強制關閉路徑中已使用的模式來修正。爭用時間軸 （路徑 A）：執行緒 A （check_new_map） 執行緒 B （另一個映射更新包含 mdsc->互斥或工作階段拆卸）
    -------------------------- -------------------------- s = mdsc->sessions[i] （refcount == 1，僅由 sessions[] 陣列持有） mutex_unlock（&mdsc->mutex） ---> 取得 mdsc->mutex __unregister_session（mdsc， s） sessions[i] = NULL ceph_put_mds_session（s） refcount： 1 -> 0 kfree（s） <---釋放！mutex_lock（&s->s_mutex） 釋放的 s->s_mutex 上的 UAF （CVE-2026-89654）

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

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

  - cpufreq： apple-soc：修正 OPP 表格清除 apple_soc_cpufreq_init（） 會從韌體新增 OPP 表格，但某些失敗路徑不會移除它們。驅動程式也會使用 dev_pm_opp_remove_all_dynamic（），這不是從韌體載入的 OPP 資料表的正確清除協助程式。在填入原則 CPU 遮罩之後，使用 cpumask OPP 協助程式。將其與故障路徑和 apple_soc_cpufreq_exit（） 中匹配的 cpumask remove 協助程式配對。這也會移除個別的 dev_pm_opp_set_sharing_cpus（） 呼叫，因為 cpumask 協助程式會載入原則中所有 CPU 的 DT OPP 表格。（CVE-2026-89572）

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

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

  - dm-pcache：在重播期間偵測 last-kset 鏈結中的循環 cache_replay（） 會遵循媒體上的 last-kset 鏈結，next_cache_seg_id沒有 cond_resched（）。一條鍛造的鏈指向它已經訪問過的片段，使重播循環永遠跟隨它。在 cache->n_segs 處限制最後一個 kset 躍點;有效的鏈結最多會造訪每個區段一次。（CVE-2026-80957）

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

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

  - USB：小工具：uvc：修正 uvc_function_bind（） 和 uvc_function_unbind（） 中的懸空指標 在 uvc_function_bind（） 錯誤路徑中，我們使用 usb_ep_free_request，它使用 uvc->control_req，但之後不會將其設定為 NULL。因此，uvc->control_req 是一個懸空指標，導致 UAF。此外，我們不會在釋放 uvc->control_buf 指標後將其設定為 NULL，這是另一個懸空指標。透過在執行 usb_ep_free_request（） 後將 uvc->control_req 設定為 NULL，在 kfree 之後將 uvc->control_buf 設定為 NULL 來修正它。對 uvc_function_unbind（） 執行相同的操作。（CVE-2026-89733）

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

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

  - SUNRPC： xdr_buf_trim：clamp buf->len 以避免下溢 xdr_buf_trim（） 透過遍歷尾部、頁面和頭部 iovec 從xdr_buf尾部修剪 'len' 位元組。每個每節步驟都使用 min_t（），因此它永遠不會刪除超過該節所包含的位元組，但fix_len標籤的最終會計會從 buf->len 中減去實際消耗的總位元組，而無需任何限制：fix_len：buf->len -= （len - trim）;當調用方將 buf->len 設定為小於iov_lens總和的值時，（len - trim） 可以超過 buf->len，並且無符號減法換行到接近 UINT_MAX。gss_krb5_unwrap_v2（） 在該狀態下到達 xdr_buf_trim（）：buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip;buf->len = len - （GSS_KRB5_TOK_HDR_LEN + headskip）;xdr_buf_trim（buf， ec + GSS_KRB5_TOK_HDR_LEN + 尾跳）;buf->len 是一個小的有線派生值，而 iov_lens 是頁面規模，因此每個部分的循環合法地消耗的位元組比 buf->len 記錄多得多。然後，包裝的 buf->len 會作為權威資料流傳播到每個下游 XDR 解碼器中。透過限制遞減來修復，使 buf->len 在零處觸底：buf->len -= min_t（unsigned int， buf->len， len - trim）;在 buf->len 的iov_lens總和的正常路徑上，（len - trim） 始終為 <= buf->len，結果與之前相同。不會有呼叫者變更反向溢位案例之外的行為。（CVE-2026-89551）

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

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

  - net： bnxt：當 SW USO 提前退出時按門鈴 當突發封包傳遞給驅動程式時，驅動程式會透過設定 txr->kick_pending = 1 來將門鈴推遲到最後。一般 TX 路徑會處理此問題，但如果提前傳回，SW USO 路徑可能會遺漏它。如果 bnxt_sw_udp_gso_xmit 執行，但提前返回 NETDEV_TX_BUSY，且 txr->kick_pending 先前設定為 1，則 TX 佇列可能會停止，因為驅動程式寫入了一些 BD，但從未寫入門鈴。裝置不會知道要執行 TX，這會產生完成，以喚醒佇列。簡化bnxt_sw_udp_gso_xmit以在其成功案例中設定 txr->kick_pending，並在傳回時檢查旗標。bnxt_sw_udp_gso_xmit傳回後新增的檢查可確保寫入任何擱置的門鈴，同時處理成功的 USO 和任何提前傳回，這可防止上述 TX 佇列停頓。在生產系統上觀察到此 TX 佇列停頓，其中 netdev TX 監控程式會通知佇列停頓。（CVE-2026-80998）

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

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

  - ceph：在解鎖期間釋放的 cf 項目上修正 __kick_flushing_caps（） 中的 UAF list_for_each_entry（） 會反覆運算 ci->i_cap_flush_list，但會丟棄傳送上限訊息的 i_ceph_lock。在解鎖窗口期間，handle_cap_flush_ack（） 可以獲取i_ceph_lock，從列表中分離具有 tid <= flush_tid 的 cf 項目，釋放i_ceph_lock，並通過任何鎖之外的 ceph_free_cap_flush（） 釋放它們。當原始執行緒重新取得i_ceph_lock並且 for 迴圈巨集透過 cf = list_next_entry（cf， i_list） 前進時，它會在釋放的記憶體上取消參照 cf->i_list.next。爭用時間軸： __kick_flushing_caps（） handle_cap_flush_ack（） ----------------------- -----------------------保留i_ceph_lock <---迭代到 cf （tid=10） 準備 FLUSH 訊息丟棄 i_ceph_lock <--- __send_cap（） FLUSH（tid=10） MDS 傳送 FLUSH_ACK（tid=10） --->取得 i_ceph_lock cf->tid（10） <= flush_tid（10），將 cf 從 i_cap_flush_list 刪除 i_ceph_lock ceph_free_cap_flush（cf） <- 釋放它！取得 i_ceph_lock <--- for 迴圈前進： cf = list_next_entry（cf， i_list） -- 釋放的 cf->i_list.next 上的 UAF 剛剛由
    透過 __send_cap（） 自行__kick_flushing_caps。MDS 可能會以足夠快的速度回應 FLUSH_ACK，以至於 handle_cap_flush_ack（） 在__kick_flushing_caps完成反覆運算之前釋放 cf。透過轉換為手動 while 迴圈來修復：在刪除之前將下一個指標保存在 i_ceph_lock 下，然後在重新獲取後使用已儲存的指標，這樣就永遠不會再存取潛在釋放的 cf。（CVE-2026-89655）

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

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

  - wifi： rtlwifi： rtl8192du：在索引 TID 之前檢查 QoS TID rtl92du_tx_fill_desc（） 使用 ieee80211_get_tid（） 從標頭讀取 802.11 QoS TID，然後將其用作 sta_entry->tids[] 的索引。 ieee80211_get_tid（） 傳回較低的 4 位 QoS TID 值，因此結果可能在 0..15 範圍內。 rtlwifi 僅為 sta_entry->tids[] 分配MAX_TID_COUNT條目， MAX_TID_COUNT是 9。因此，大於 8 的 QoS TID 會索引超過聚合狀態陣列。保留超出範圍 TID 的預設RTL_AGG_STOP狀態，與 rtl92cu_tx_fill_desc（） 相符。此問題由我們的靜態分析工具偵測到，並透過手動稽核確認。相同錯誤型樣的 UBSAN 驗證會報告 array-index-out-of-bounds 類型「rtl_tid_data [9]」的索引為 10 的存取。（CVE-2026-80943）

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

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

  - sched_ext：修正核心排程下的 rq->core_pick 損毀 核心排程的 pick_next_task（） 會在共用核心範圍的 rq 鎖定下，在單一傳遞中選擇要在核心的每個 SMT 同級上執行的內容。只有在連續持有鎖定時，選擇狀態才一致，因此 ->pick_task（） 原本無法釋放它。但是，由於 4c95380701f5 （sched/ext：將 balance_scx（） 折疊成 pick_task_scx（）），sched_ext從拾取和分派內部執行分派可能會刪除 rq 鎖定。為了支援這一點，pick_next_task（） 已更新，以便在釋放鎖定後，當揀選返回RETRY_TASK時重新啟動整個選擇。當同一核心上的選擇透過丟棄的鎖定交錯時，它們會破壞彼此的狀態：一個清除另一個的 rq->core_pick 導致 NULL 解除參照，或使其保留上一個任務決策失效，使出隊任務繼續執行，這會使下一次喚醒鎖死並匹配報告的硬懸置。SMT 機器上的 cookie 乒乓加載會使交錯頻繁，並在幾秒鐘內殺死核心。透過在分派釋放 rq 鎖定時使選擇返回RETRY_TASK來修正它，以便選擇僅提交在持續保留鎖定下進行的選擇。上一個修補程式的 rq->scx.lock_drop_seq 會計算版本。未觸及任何內容的分派永遠不會釋放鎖定，其判定（包括任何要執行的內容）都有效：重試是有限制的，每次重試都遵循實際執行某些動作的分派，並且閒置的 CPU 不會迴圈。如果另一個分派已經在 rq 上進行中，請跳過分派並從本機已排入佇列的內容中挑選 - 正在進行的分派已釋放鎖定，因此它自己的選擇將重試並重新挑選此 rq，而在此處返回RETRY_TASK只會在分派需要完成的鎖定上旋轉。平衡回呼必須在將其排入佇列的內容中執行，因此它們只能在 CPU 自己的 rq 上排入佇列。針對另一個 rq 分派時，請改為直接執行延遲的工作 - 該 rq 可能會透過核心排程快速路徑耗用其所有選擇，並且永遠不會將回呼本身排入佇列。關於可執行任務被遺忘的 put_prev_task_scx（） 警告假設分派作為正在切換的選擇的一部分運行。現在它只適用於非核心路徑，因此請將其門控並從其條件中刪除 cookie-match 測試，該測試在沒有核心調度的情況下始終為真。
    (CVE-2026-89517)

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

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

  - ZoneMinder 是一款免費的開源閉路電視軟件應用程序。、 1.38.4之前的版本，1.36.39並1.39.11允許具有粗略「Events=View」和/或「Snapshots=View」權限的經過驗證的低權限使用者直接擷取屬於他們不允許存取的監視器事件的媒體。一般 UI 會正確隱藏受限制的監視器及其事件，但直接事件媒體檢視會接受任意「eid」，並從事件路徑串流媒體，而不會強制執行事件/監視器層級 ACL。這暴露了跨監視器邊界的私人監控錄像。版本 1.36.39、 1.38.4和 1.39.11 並修正問題。（CVE-2026-54258）

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

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

  - sched/core：讓核心排程翻轉等候未進行的選取項目 Core 排程的 pick_next_task（） 會在一次取得共用核心範圍鎖定的情況下，在所有同級 rq 上運作。釋放 rq 鎖的 ->pick_task（） 會讓每個同級__lock暫時釋放，讓 __sched_core_flip（false） 完成中間選擇並在其下重新綁定 rq_lockp（）。在分割鎖上恢復選擇，接觸它不再保護的同級狀態，並且 __schedule（） 最終釋放了一個從未被佔用的鎖，同時洩露了曾經被佔用的鎖。在領導者的 rq->core_pick_in_flight 中計算正在進行的核心範圍選擇，並使 __sched_core_flip（） 等待計數耗盡。計數只會在共用鎖定下變更，翻轉會在取樣時保留該鎖定，因此不需要其他排序。當選取項目重疊時，等候可以重複，但樣本之間的翻轉和翻轉是罕見的 cookie 存留期事件。
    sched_core_cpu_deactivate（） 將計數移動到新的領導者 - 如果該 CPU 稍後返回為自己的領導者，則留下的過時副本將永遠偏向它。（CVE-2026-89520）

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

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

  - Ceph：ceph_parse_deleg_inos（） 中的 CAP 委派 inode 計數 ceph_parse_deleg_inos（） 從 MDS 使用委派建立回覆中解碼委派 inode 編號的間隔集。對於每個集合，它會讀取一個 64 位元開始和一個帶有 ceph_decode_64_safe（） 的 64 位元 len，這僅驗證訊息中是否存在八個位元組，而不是值，然後在將條目插入 s_delegated_inos 時循環 len。Len 完全由攻擊者控制。惡意或遭入侵的 MDS 可以傳送一個巨大的間隔、一個回覆中的多個間隔、重複的間隔或重複的回覆，這些回覆會在同一工作階段上累積委派的 inode。
    原始程式碼沒有限制這些，並且可以無限制地旋轉插入迴圈或增長 xarray。
    使用單一強制點綁定兩個維度。在不可部分完成計數器中追蹤每個 MDS 工作階段所持有的委派 inode 數量，並僅在 ceph_insert_deleg_ino（） 中增加它，該 （） 使用 atomic_add_unless（） 拒絕將計數推送超過 CEPH_MAX_DELEG_INOS。因為該協助程式是計數器成長的唯一位置，所以每個會話的母體永遠不會超過上限，因此不需要個別的每個會話預先檢查。當非同步建立耗用委派的 inode 或插入失敗時，計數器會遞減，在還原委派的 inode 時遞增，使用工作階段 xarray 初始化，並在重新連接破壞 xarray 時重設。僅每個會話上限仍然允許一個回覆在重複的範圍內旋轉插入迴圈，而不會增加計數器，因此也限制從單一回覆接受的聚合間隔長度。這些一起綁定了每個回覆的迴圈行程計數和跨回覆的 xarray 母體。上限是固定的、用戶端選擇的常數，而不是從 MDS 衍生的值。
    mds_client_prealloc_inos 是使用者空間 MDS 組態選項;它永遠不會在網路上傳送至核心用戶端，而且在任何情況下都無法信任伺服器提供的界限來進行防禦限制。常數設定得遠高於該選項記錄的預設值 1000 （一個很大的倍數），因此合法的重新填充行為不受影響，而格式錯誤的委派資料流可能消耗的 CPU 和 xarray 記憶體則保持有限。影響：惡意或遭入侵的 Ceph MDS 無法再讓用戶端透過不受限制的委派 inode 間隔旋轉，或無限制地增加一個工作階段的委派 inode xarray。（CVE-2026-89648）

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

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

  - sunrpc：將 rq_argp 和 rq_resp 釋放推遲到 RCU 寬限期 svc_rqst_free（） 之後，透過 kfree（） 同步釋放 rqstp->rq_argp 和 rqstp->rq_resp，但透過 kfree_rcu（） 延遲釋放 rqstp 結構。在 svc_exit_thread（） 呼叫 list_del_rcu（） 和 svc_rqst_free（） 之後，有一個視窗，在 list_del_rcu（） 之前啟動的 RCU 讀取器仍然可以遍歷執行緒清單並找到 rqstp。這些讀者 （例如
    nfsd_nl_rpc_status_get_dumpit（）） 解除參照 rqstp->rq_argp，它已經釋放了釋放後使用。透過將 rq_argp 和 rq_resp 的 kfree 與結構 free 一起移動到明確的 call_rcu（） 回呼中來解決此問題。RCU 讀取器未存取的資源 （bvec、緩衝區頁面、暫存對開本auth_data） 會保持同步釋放。（CVE-2026-89545）

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

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

  - iommufd：在 xa_store（） 失敗時釋放目前的 IOAS，iommufd_take_all_iova_rwsem（） 在將 IOAS 儲存在暫存ioas_list xarray 之前，先採用物件參照和iova_rwsem寫入鎖定。如果 xa_store（） 失敗，則目前的 IOAS 尚未插入ioas_list。
    iommufd_release_all_iova_rwsem（） 只會展開該 xarray 中已經存在的 IOAS 物件，因此無法釋放目前的 IOAS。在回復先前儲存的項目之前，釋放現行 IOAS rwsem 和物件參照。（CVE-2026-89446）

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

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

  - fs：修正巢狀備份檔的使用者路徑 backing_file_open（） 會從 user_file->f_path 派生要儲存在新備份檔中的路徑。當 user_file 本身是備份檔案時，這是不正確的，這是嵌套堆疊檔案系統的情況，例如 overlayfs 掛載，其中一個 overlayfs 的下限目錄是另一個 overlayfs 的合併目錄。由於提交 def3ae83da02 （fs：在後備檔案中儲存真實路徑而不是假路徑 f_path），因此後備檔案的f_path保留中間層的真實路徑，而不是使用者開啟的路徑。提交 924577e4f6ca （ovl：修正巢狀備份檔案路徑） 透過從 ovl_open_realfile（） 傳遞 file_user_path（） 來修正此類配置的此問題。不過，請提交 6af36aeb147a （lsm：
    新增 backing_file LSM 鉤子）將 backing_file_open（） 的第一個引數從使用者路徑改回使用者檔案，並再次從 user_file->f_path 派生路徑，靜默地重新引入問題。因此，透過巢狀 overlayfs 對應的檔案會在 /proc/<pid>/maps 和 perf/ftrace mmap 記錄中顯示錯誤的路徑。例如，使用兩個巢狀 overlayfs 掛載： mkdir -p /ovl/{lower，upper，work，merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower，upperdir=/ovl/upper，workdir=/ovl/work \ /ovl/merged # 當 upperdir 不存在時，至少需要兩個 lowerdir mount -t overlay overlay \ -o lowerdir=/ovl/merged：/ovl/lower /ovl/nested mapping /ovl/nested/foo 顯示中斷連線的路徑，而不是使用者路徑： # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo 虛假路徑源自中間備份檔的f_path，其掛載是 d_path（） 無法解析的私有複製。使用 file_user_path（） 修正此問題，該路徑會傳回備份檔案的最外層使用者可見路徑，並針對一般檔案回歸 &user_file->f_path。這還原了 overlayfs 的提交 924577e4f6ca （ovl： 修正巢狀備份檔案路徑） 的行為，也修正了其他 backing_file_open（） 呼叫端、fuse passthrough 和 erofs ishare 的相同問題，當其使用者檔案本身是備份檔案時。backing_tmpfile_open（） 具有相同的模式，但不受影響：
    它僅由上層的 ovl_create_tmpfile（） 調用，而另一個 overlayfs 被 ovl_mount_dir_check（） 中的DCACHE_OP_REAL檢查作為上層拒絕，因此其user_file永遠不能是備份檔。（CVE-2026-89768）

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

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

  - SMB： client：以 cifsacl/modefromsid/posix 副檔名寫入時清除 setuid/setgid 位元 當檔案設定了 setuid 或 setgid 位元並被寫入時，VFS 會剝離這些位元，並發出帶有 ATTR_KILL_SUID/ATTR_KILL_SGID 的 setattr 以及帶有已清除模式的ATTR_MODE。在這種情況下，cifs_setattr_unix（） 和 cifs_setattr_nounix（） 都會無條件地丟棄ATTR_MODE： /* 跳過模式更改 （如果只是為了清除 setuid/setgid */ if （attrs->ia_valid &; （ATTR_KILL_SUID|ATTR_KILL_SGID）） attrs->ia_valid &= ~ATTR_MODE;這對於預設掛載來說很好，其中模式僅透過 DOS 唯讀屬性進行模擬，並且無論如何都無法表示 setuid/setgid 位元。但是，使用 cifsacl 或 modefromsid 掛載選項時，模式會透過 ACL （id_mode_to_cifs_acl（）） 儲存在伺服器上，使用 SMB3.1.1 POSIX 延伸模組時，模式會直接傳送至伺服器，而使用 SMB1 Unix 延伸模組 （cifs_setattr_unix） 時，模式會透過 CIFSSMBUnixSetPathInfo（） 傳送。在所有這些情況下，丟棄ATTR_MODE意味著清除的模式永遠不會推送到伺服器，因此 setuid/setgid 位元在寫入過程中仍然存在。這是一個安全性問題：在本機檔案系統上，當寫入檔案時，setuid 位元會被剝離，但透過這些 cifs.ko 掛載，該位元會持續存在於伺服器上，可能會允許在後續執行時意外的權限提升。在兩個地方修正此問題： 1. cifs_setattr_nounix（）：僅當透過 DOS 唯讀屬性模擬模式時（即 cifsacl/modefromsid 和 SMB3.1.1 POSIX 延伸模組均無效），才採用跳過模式變更捷徑，以便在 ACL / POSIX 情況下將清除的模式傳播到伺服器。2、cifs_setattr_unix（）：只有在Unix擴充有效時才調用此函數，因此模式始終儲存在伺服器上。完全移除捷徑，以便一律按下清除模式。（CVE-2026-89638）

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

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

  - ALSA： FCP：不要複製出未初始化的 init 回應 fcp_ioctl_init（） 使用 kmalloc（） 分配其回應緩衝區，並將整個緩衝區複製回使用者空間：buf_size = init.step0_resp_size + init.step2_resp_size;void *resp __free（kfree） = kmalloc（buf_size， GFP_KERNEL）;...if （copy_to_user（arg->resp， resp， buf_size）） return -EFAULT;沒有任何內容會清除緩衝區，其前導 step0_resp_size 位元組的唯一寫入器是 step-0 控制傳輸： err = snd_usb_ctl_msg（dev， usb_rcvctrlpipe（dev， 0）， FCP_USB_REQ_STEP0， USB_RECIP_INTERFACE |USB_TYPE_CLASS |USB_DIR_IN， 0， private->bInterfaceNumber， step0_resp， private->step0_resp_size）;if （err < 0） 傳回 err;
    usb_fill_control_urb（） 不會設定URB_SHORT_NOT_OK，因此短或零長度資料階段會以狀態 0 完成，且 snd_usb_ctl_msg（） 會傳回小actual_length。唯一的檢查是錯誤< 0，因此短傳輸會被視為成功。snd_usb_ctl_msg（） 無條件地複製回完整大小：buf = kmemdup（data， size， GFP_KERNEL）;...memcpy（data， buf， size）;因此，裝置從未寫入的位元組會原封不動地還原為 resp 並複製到使用者空間。step0_resp_size 和 step2_resp_size 分別僅驗證為 1..255，因此呼叫端也會挑選 slab 快取，從 kmalloc-8 到 kmalloc-512。在 7.2.0-rc5 （arm64） 上，裝置以零長度資料階段應答步驟 0，s0 = s2 = 255：# init_on_alloc關閉，無噴霧步驟 0 視窗 [0,255）：nonzero=94/255 000：00 80 60 06 00 00 ff ff 18 00 00 00 57 01 EA 01 010：08 78 22 13 00 00 ff ff ff a8 c4 5f 80 00 80 ff ff # 相同的核心， KMALLOC-512 預先植入 8 位元組標籤 step0 視窗 [0,255）： nonzero=219/255 tagbytes=232 # 相同的執行，init_on_alloc=1 step0 視窗 [0,255）： nonzero=0/255 tagbytes=0 # 所有三次執行 step2 視窗 [255,510）： 裝置字 matched=62/62 a8 c4 5f 80 00 80 ff ff 是 little-endian 核心文字位址 ffff8000805fc4a8。步驟 2 視窗不受影響，因此揭露恰好是步驟 0 區域。將緩衝區歸零，並要求步驟 0 傳輸以傳遞完整的 step0_resp_size 位元組，以便將短資料階段報告為錯誤。
    由 XBOW 發現，由 Baul Lee <baul.lee@xbow.com> 分類 （CVE-2026-80970）

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

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

  - ring-buffer：調整 subbuf 大小時按住 cpu_buffer：：lock 因為 ring_buffer_subbuf_order_set（） 可以清除 cpu_buffer->free_page，請按住 cpu_buffer->lock 以防止與 ring_buffer_alloc_read_page（） 和 ring_buffer_free_read_page（） 爭用。（CVE-2026-89501）

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

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

  - 電源：供應：RT9455：拆卸前靜止延遲工作 執行緒 IRQ 處理常式可以將 pwr_rdy_work、max_charging_time_work 和 batt_presence_work排入佇列。pwr_rdy_work和batt_presence_work也可以將max_charging_time_work排入佇列，而batt_presence_work可以自行重新排入佇列。rt9455_remove（） 會在batt_presence_work之前取消max_charging_time_work。因此，後者可以在取消之後將max_charging_time_work排入佇列：rt9455_remove（） 工作佇列取消pwr_rdy_work取消max_charging_time_work batt_presence_work佇列max_charging_time_work取消batt_presence_work傳回 devres 釋放rt9455_info max_charging_time_work取消參照 rt9455_info IRQ 也會保持註冊狀態，直到 devres 清理為止，並且可以在任何取消呼叫之後將更多工作排入佇列。如果在要求 IRQ 之後 rt9455_hw_init（） 失敗，則探查會傳回，而不會取消可能已排入佇列的工作。擱置回呼在釋放後即可存取rt9455_info。在 devm_power_supply_register（） 之後立即註冊 rt9455_cancel_all_delayed_works（） 到 devm_add_action_or_reset（）。devres 會在釋放受管理的 IRQ 之後和釋放 rt9455_info之前，以反向註冊順序呼叫動作，因此延遲的工作會在 rt9455_remove（） 和探查錯誤路徑中清空。取消pwr_rdy_work並在max_charging_time_work之前batt_presence_work，因為兩者都可以將後者排入佇列。此問題是由內部靜態分析工具發現的。（CVE-2026-89465）

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

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

  - mm/migrate_device：釋放 swapcache 後清除過時的對應 __migrate_device_pages（） 會在呼叫 folio_free_swap（） 之前讀取對開本對應。當 folio_free_swap（） 成功時，對開本會從交換快取中移除，但儲存的對應仍指向swap_space。將過時的對應傳遞給 folio_migrate_mapping（） 會使其對不再在交換快取中的對開本使用對應對開本路徑。然後，它可以在具有無效參照統計的 swap_space.i_pages 上運行，最終觸發對開本參照計數 BUG。成功拆分後，nr 仍包含原始大對開本中的頁數，儘管每個產生的頁面現在都是單獨的 order-0 對開本。將 nr 重設為 1，以便個別處理每個分割對開本，包括其自己的交換快取移除和對應查詢。在 folio_free_swap（） 之後重新整理已儲存的對應，以便在移轉期間使用目前的對開本狀態。（CVE-2026-89755）

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

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

  - HID： mcp2221：在 devm 清理回呼 mcp2221_hid_unregister（） 開始時，在hid_hw_stop靜止裝置 IO 之前停止裝置 IO，以便傳入的 HID 報告在探查失敗或裝置移除期間不會與硬體拆卸爭用，從而解決潛在的釋放後使用問題。使用 io_started 保護對 hid_device_io_stop（） 的呼叫。在正常移除中，hid_device_remove（） 在釋放 devres 群組之前就已經清除了 io_started，因此無條件呼叫會命中 ！io_started 路徑，並在每次移除時發出虛假的 io 已停止警告。防護會保留探查失敗平衡，其中 io_started 仍會在 hid_device_io_start（） 之後設定，同時在正常移除路徑上保持靜音。（CVE-2026-89623）

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

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

  - eprosima Fast DDS 是 OMG（物件管理群組）的 DDS（資料分發服務）標準的 C++ 實作。、 3.3.12.14.63.2.4之前3.4.2的版本，2.6.12在處理 RTPS 「DATA_FRAG」子訊息時具有可遠端觸發的越界讀取。攻擊者可以製作具有較大「sampleSize」但實際負載較小的「DATA_FRAG」，並設定「fragmentsInSubmessage」，以便接收者將封包視為最後一個片段**。在此 LAST-fragment 路徑中，Fast-DDS 根據 'sampleSize' 計算 'incoming_length' 並調用 'memcpy（）'，而不驗證 'incoming_data.length >= incoming_length'。因此，'CacheChange_t：：add_fragments（）' 讀取通過接收到的 UDP 數據包緩衝區並讀取到相鄰的堆積內存中，將這些位元組複製到重組緩衝區中。在探索伺服器部署中，產生的「CacheChange_t」可以轉送給其他參與者，這表示新加入的參與者可能會收到洩漏的堆積記憶體 （例如，可能有助於繞過 ASLR 的指標值）。版本 2.6.12、 2.14.6、 3.2.43.3.1，並3.4.2修正問題。（CVE-2026-22590）

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

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

  - apparmor：修正由 begin_current_label_crit_section（） 引起的 cred UAF AppArmor 的 begin_current_label_crit_section（） 是一個可怕的函數，可從許多 LSM 鉤子（特別是與 VFS/通訊端相關的鉤子）調用，它檢查當前 creds 引用的標籤是否標記為FLAG_STALE，如果是，則嘗試使用 aa_replace_current_label（） 將 creds 替換為使用新標籤的更新版本。這樣做的第一個問題是，如果核心中的任何內容採用指向當前憑據的指標並訪問這些，則會直接導致“struct cred”的 UAF，然後通過替換憑據的安全鉤調用，如下所示： ''' const struct cred *cred = current_cred（）;
    alloc_file_pseudo（...）;uid_t uid = cred->euid;''' 我不知道核心中是否有任何東西真的這樣做，但我認為這種模式可能導致 UAF 是非常令人驚訝的。第二個問題是，當 aa_replace_current_label（） 使用覆寫的憑證執行時，會出現問題。
    如果 'current_cred（） ！= current_real_cred（）' （鏡像簽入 proc_pid_attr_write（）），則 aa_replace_current_label（） 會退出，但此檢查實際上無法可靠地偵測覆寫的憑證，因為覆寫的憑證可能與目標憑證相同。因此，在大約以下情況下，事情會出錯： 1. 任務以 （作為客觀和主觀信用） 開 <creds A> 頭，refcount=2 2. 任務獲取一個額外的引用 <creds A> 以覆蓋 3. 任務調用 override_creds（），<creds A>它返回指向舊主觀信用 （） 的指標 4<creds A>. 任務進入 AppArmor LSM 鉤子 5.
    AppArmor 會檢查客觀/主觀信任是否相等 6。AppArmor 將兩個 cred 指標替換為 <creds B> 並在 7 上 <creds A> 刪除 2 個引用。 task 離開 AppArmor LSM hook 8. task 調用 revert_creds（<creds A>） 9. 現在 task->cred 是 <creds A> 而 task->real_cred 是 <creds B>，但task_struct在邏輯上保留兩個對 10 的 <creds B> 引用。 另一個任務刪除了用於覆蓋的額外引用 <creds A> ，refcount 下降到 0 11。 現在 task->real_cred 指向釋放的 creds 此時， 任何對 current_cred（） 的存取都將是 UAF。我有一個測試案例，我在配置文件上運行 aa-disable，而使用該配置文件的進程在 splice（） 上被阻止，從 FUSE 直通文件到一個完整的管道;設定檔更新後，管道變為空，splice（） 恢復，憑證不同步，後續的 getuid（） 系統調用會導致 KASAN UAF splat。若要修正此問題，請不要直接取代 creds，而是透過在目前系統調用結束時執行的task_work來執行。（cred 替換發生的時間點不應對正確性產生影響，這只是為了避免不必要地接觸新標籤的參照計數而進行的性能優化。請注意，在此變更之後，AppArmor 仍會在 sb_pivotroot LSM 勾點中執行直接 cred 替換，並且透過 proc_pid_attr_write（） 在 VFS ->write（） 回呼中仍可直接 cred 替換。如何使用 aa_dup_task_ctx（） 有兩個選項：在複製整個aa_task_ctx後明確重設 new->label_replacement_pending，或切換為手動複製成員。我正在切換到手動複製成員，因為這應該會使錯誤更加明顯。（CVE-2026-89762）

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

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

  - fbdev： ssd1307fb：延遲來自損壞回呼的 I2C 傳輸 當 printk 已停用搶佔時，fbdev 損壞回呼可能會從 fbcon 執行。他們目前同步更新顯示，從原子上下文進入休眠的 I2C 傳輸路徑。系統的完整 RK3566 報告如下： [258.129004] watchdog： watchdog0：watchdog 沒有停止！[ 258.129067] 錯誤：不可部分完成時的排程：
    systemd/1/0x00000003 [ 258.129076] 連結於： algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306（C） fbtft（C） btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil 藍牙 cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.129215] 在以下位置停用搶佔： [ 258.129216] [<ffff80008012f96c>] vprintk_emit+0x11c/0x340 [ 258.129234] CPU：0 PID：1 通訊：systemd 污染：G C 6.6.0-rc5-rockchip-rk356x #4 [ 258.129239] 硬體名稱：瑞芯微 RK3566 OPi 3B （DT） [ 258.129243] 呼叫追蹤：[ 258.129245] dump_backtrace+0xa0/0x128 [ 258.129252] show_stack+0x20/0x38 [ 258.129256] dump_stack_lvl+0x60/0xb0 [ 258.129265] dump_stack+0x18/0x28 [ 258.129269] __schedule_bug+0xa0/0xc8 [258.129274] __schedule+0x9ac/0xd30 [ 258.129279] schedule+0x60/0x100 [ 258.129282] schedule_timeout+0x194/0x338 [ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498 [ 258.129296] rk3x_i2c_xfer+0x20/0x60 [ 258.129300] __i2c_transfer+0x194/0x648 [ 258.129308] i2c_transfer+0x9c/0x130 [258.129313 ] i2c_transfer_buffer_flags+0x64/0x98 [ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb] [ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb] [ 258.129343] soft_cursor+0x13c/0x210 [ 258.129350] bit_cursor+0x2dc/0x550 [ 258.129354] fbcon_cursor+0xec/0x108 [258.129359] hide_cursor+0x44/0xc8 [ 258.129365] vt_console_print+0x398/0x3b0 [ 258.129370] console_flush_all.isra. 0+0x17c/0x410 [ 258.129377] console_unlock+0x4c/0x100 [ 258.129382] vprintk_emit+0x1c8/0x340 [ 258.129386] vprintk_default+0x40/0x58 [ 258.129389] vprintk+0xb8/0xd0 [258.129392 ] _printk+0x68/0x98 [ 258.129398] watchdog_release+0x170/0x230 [ 258.129404] __fput+0xbc/0x288 [258.129409 ] __fput_sync+0x58/0x70 [ 258.129413] __arm64_sys_close+0x40/0x90 [ 258.129419] invoke_syscall+0x4c/0x118 [ 258.129426] el0_svc_common.constprop.0+0x48/0xf0 [ 258.129432] do_el0_svc+0x24/0x38 [ 258.129437] el0_svc+0x48/0x100 [ 258.129443] el0t_64_sync_handler+0xc0/0xc8 [258.129448] el0t_64_sync+0x190/0x198 [ 258.573087] ------------[ 切到這裡 ]------------ [ 258.573098] DEBUG_LOCKS_WARN_ON（val > preempt_count（）） [ 258.573111] 警告： CPU：0 PID：1 在 kernel/sched/core.c：5871 preempt_count_sub+0x9c/0x148 [ 258.573130] 連結於：algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306（C） fbtft（C） btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fansnd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 SSD130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil 藍牙 cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp ---truncated--- （CVE-2026-89598）

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

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

  - SUNRPC：在銷毀 cache_detail sunrpc_destroy_cache_detail（） 之前始終清空cache_cleaner，僅在cache_list為空時取消全域cache_cleaner delayed_work。在 per-netns 拆卸期間，cache_list永遠不會是空的，因為init_net的快取會保持註冊狀態，因此永遠不會觸發取消。取消連結後，呼叫者繼續進行 cache_destroy_net（），這會釋放cache_detail，而 cache_clean（） 可能仍會保留指向它的懸空指標。結果是釋放後使用：cache_dequeue（） 在釋放的記憶體上獲取 cd->queue_lock，而 cache_put（） 將 cd->cache_put 解除參照為釋放 slab 中的函數指標。刪除 list_empty 防護，讓 cancel_delayed_work_sync（） 一律執行，確保任何進行中的 cache_clean（） 在釋放 cache_detail 之前完成。如果其他快取仍註冊，請稍後重新布防清理器。（CVE-2026-89548）

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

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

  - ALSA： pcxhr：在初始化 mgr->lock 之前，先要求執行緒 IRQ pcxhr_probe（） 要求 pcxhr_threaded_irq（） 之前初始化互斥，即使執行緒處理常式採用該互斥。在 request_threaded_irq（） 之前初始化管理程式鎖定，以便在探測期間無法針對未初始化的互斥狀態執行早期中斷。（CVE-2026-80967）

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

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

  - nvme-tcp：拒絕傳輸太少位元組的讀取 nvme_tcp_recv_data（） 會在目前的 C2HData PDU 耗用之後完成要求。沒有任何東西會將收到的總位元組數與命令要求的長度進行比較：struct nvme_tcp_request 沒有接收端計數器，queue->data_remaining 是每個佇列，並且 blk_mq_end_request（） 無條件地完成 blk_rq_bytes（rq），上面沒有殘餘概念。因此，控制器可以使用 512 位元組回應 4096 位元組的讀取，並將其報告為完整讀取;然後用戶空間獲得 4096 個字節，其中 3584 個是頁面中已有的任何字節。我用測試目標再現了這一點。計算在兩個NVME_TCP_F_DATA_SUCCESS路徑和 nvme_tcp_process_nvme_cqe（） 中收到的位元組，並拒絕完成計數不相符的成功讀取。
    成功測試會將 req->status 正確移位，因為驅動程式會保留配線值，並在完成時將其移位，因此檢查必須查看完成路徑將看到的內容。只檢查REQ_OP_READ，因為長度來自請求涵蓋的磁區;直通命令是由其提交者構建的，它同時選擇命令和緩衝區，因此核心沒有什麼可以比較的。
    (CVE-2026-89480)

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

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

  - eprosima Fast DDS 是 OMG（物件管理群組）的 DDS（資料分發服務）標準的 C++ 實作。在 2.6.12版本 、 2.14.6、 3.2.4和 3.4.3之前，Fast DDS 實作的 SQL 型內容篩選 （DDSSQLFilter） 允許 DDS 網域中的任何參與者透過傳送單一特製的 SEDP 'DATA' 子訊息來遠端當機，其 'PID_CONTENT_FILTER_PROPERTY.filterExpression' 包含深度巢狀篩選運算式。版本 2.6.12、 2.14.6、 3.2.4並 3.4.3 修正問題。（CVE-2026-22591）

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

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

  - 藍牙：eir：修正 eir_get_service_data（） 中的 OOB 讀取 eir_get_service_data（） 遍歷具有相符 UUID 的服務資料欄位的廣告資料。在不匹配的情況下，它前進：eir += dlen;eir_len -= 德倫;
    eir_get_data（） 將 dlen 報告為欄位的資料長度，但一旦欄位的長度和類型位元組計入，該欄位就會跨越 dlen + 2 個位元組，當跳過非 Service-Data 欄位以到達該欄位時，該欄位的跨度會更長。指標會正確落在下一個欄位上。eir_len則不會，而且不足值會在欄位之間複合，直到 eir_get_data（） 讀取超出緩衝區結尾的欄位的長度和類型位元組。對於 ISO 廣播接收器，該緩衝區是 hcon->le_per_adv_data[]，從遠端廣播公司的定期廣告報告中填充。包含不相符服務資料欄位的 PA 承載會離開陣列進入結構hci_conn的其餘部分。符合 BAA UUID 的漂移欄位會將這些位元組放在 iso_pi（sk）->base 中，使用者空間會使用 getsockopt（BT_ISO_BASE） 讀回這些位元組。每次反覆運算都從緩衝區結尾重新計算eir_len。（CVE-2026-89583）

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

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

  - platform/x86： ISST： 驗證邏輯 CPU ID 和 clos ID 驗證核心電源功能的最大 CLOS ID 和邏輯 CPU ID。拒絕任何大於支援上限的 clos 層級或邏輯 CPU 數目。這些用於計算 MMIO 偏移。（CVE-2026-89438）

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

ID	名稱	嚴重性
345297	Linux Distros 未修補弱點：CVE-2026-89564	high
345296	Linux Distros 未修補弱點：CVE-2026-89535	high
345295	Linux Distros 未修補弱點：CVE-2026-89627	high
345294	Linux Distros 未修補弱點：CVE-2026-89601	high
345293	Linux Distros 未修補弱點：CVE-2026-89748	high
345292	Linux Distros 未修補弱點：CVE-2026-80931	high
345291	Linux Distros 未修補弱點：CVE-2026-80986	critical
345290	Linux Distros 未修補弱點：CVE-2026-80946	high
345289	Linux Distros 未修補弱點：CVE-2026-89595	medium
345288	Linux Distros 未修補弱點：CVE-2026-89505	high
345287	Linux Distros 未修補弱點：CVE-2026-89472	high
345286	Linux Distros 未修補弱點：CVE-2026-89741	high
345285	Linux Distros 未修補弱點：CVE-2026-80941	medium
345284	Linux Distros 未修補弱點：CVE-2026-89475	high
345283	Linux Distros 未修補弱點：CVE-2026-89758	high
345282	Linux Distros 未修補弱點：CVE-2026-89516	medium
345281	Linux Distros 未修補弱點：CVE-2026-89452	high
345280	Linux Distros 未修補弱點：CVE-2026-89558	critical
345279	Linux Distros 未修補弱點：CVE-2026-89467	high
345278	Linux Distros 未修補弱點：CVE-2026-89723	high
345277	Linux Distros 未修補弱點：CVE-2026-89654	critical
345276	Linux Distros 未修補弱點：CVE-2026-89572	medium
345275	Linux Distros 未修補弱點：CVE-2026-80957	medium
345274	Linux Distros 未修補弱點：CVE-2026-89733	high
345273	Linux Distros 未修補弱點：CVE-2026-89551	critical
345272	Linux Distros 未修補弱點：CVE-2026-80998	high
345271	Linux Distros 未修補弱點：CVE-2026-89655	critical
345270	Linux Distros 未修補弱點：CVE-2026-80943	high
345269	Linux Distros 未修補弱點：CVE-2026-89517	medium
345268	Linux Distros 未修補弱點：CVE-2026-54258	medium
345267	Linux Distros 未修補弱點：CVE-2026-89520	high
345266	Linux Distros 未修補弱點：CVE-2026-89648	high
345265	Linux Distros 未修補弱點：CVE-2026-89545	high
345264	Linux Distros 未修補弱點：CVE-2026-89446	high
345263	Linux Distros 未修補弱點：CVE-2026-89768	low
345262	Linux Distros 未修補弱點：CVE-2026-89638	high
345261	Linux Distros 未修補弱點：CVE-2026-80970	high
345260	Linux Distros 未修補弱點：CVE-2026-89501	high
345259	Linux Distros 未修補弱點：CVE-2026-89465	high
345258	Linux Distros 未修補弱點：CVE-2026-89755	high
345257	Linux Distros 未修補弱點：CVE-2026-89623	high
345256	Linux Distros 未修補弱點：CVE-2026-22590	critical
345255	Linux Distros 未修補弱點：CVE-2026-89762	high
345254	Linux Distros 未修補弱點：CVE-2026-89598	high
345253	Linux Distros 未修補弱點：CVE-2026-89548	high
345252	Linux Distros 未修補弱點：CVE-2026-80967	high
345251	Linux Distros 未修補弱點：CVE-2026-89480	high
345250	Linux Distros 未修補弱點：CVE-2026-22591	high
345249	Linux Distros 未修補弱點：CVE-2026-89583	high
345248	Linux Distros 未修補弱點：CVE-2026-89438	medium

偵測

Nessus 的 Misc. 系列

high

high

high

high

high

high

critical

high

medium

high

high

high

medium

high

high

medium

high

critical

high

high

critical

medium

medium

high

critical

high

critical

high

medium

medium

high

high

high

high

low

high

high

high

high

high

high

critical

high

high

high

high

high

high

high

medium