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

  - NSIS（Nullsoft Scriptable Scriptable Install System） 3.06.1 有時 3.12 會在執行 SYSTEM 時使用 Low IL temp 目錄，允許本地攻擊者獲得權限（前提是他們能讓 my_GetTempFileName 回傳 0，如參考文獻所示）。（CVE-2026-42171）

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

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

  - usbip：驗證 usbip_pack_ret_submit() 中的 number_of_packets。USB/IP 用戶端收到 RET_SUBMIT 回應時，usbip_pack_ret_submit() 會無條件覆寫網路 PDU 的 urb->number_of_packets。
    此值隨後用作 usbip_recv_iso() 和 usbip_pad_iso() 中的迴圈邊界，以反覆使用 urb->iso_frame_desc[]，這是一種彈性陣列，其大小在 URB 配置時已根據
    來自 CMD_SUBMIT 的 *original* number_of_packets 固定。惡意 USB/IP 伺服器可將回應中的 number_of_packets 設定為大於最初提交的值，進而在 usbip_recv_iso() 寫入超出配置區域的 urb->iso_frame_desc[i] 時，造成堆積超出邊界寫入。KASAN 已在核心版本 7.0.0-rc5 證實此問題：錯誤：KASAN：在 usbip_recv_iso+0x46a/0x640 處發生 slab 超出邊界寫入。由任務 vhci_rx/69 執行的大小為 4 位元組寫入動作，發生在位址 ffff888106351d40。該錯誤位址位於已配置的 320 位元組區域 [ffff888106351c00, ffff888106351d40) 右側 0 位元組處。伺服器端 (stub_rx.c) 與 Gadget 端 (vudc_rx.c) 自從提交紀錄 c6688ef9f297 起，就已經在 CMD_SUBMIT 路徑中驗證了 number_of_packets (usbip：
    修正 stub_rx：強化 CMD_SUBMIT 路徑以處理惡意輸入) 和 b78d830f0049 (usbip：修正 vudc_rx：
    強化 CMD_SUBMIT 路徑以處理惡意輸入)。伺服器端會根據 USBIP_MAX_ISO_PACKETS 進行驗證，因為此時還不存在 URB。在用戶端，我們擁有原始 URB，因此我們可以使用更嚴格的邊界：回應不得超過原始 number_of_packets。這會針對 usbip_recv_xbuff() 中的 transfer_buffer_length 鏡像現有的實際長度驗證，進而根據原始配置大小檢查回應值。Kelvin Mbogo 的系列 (usb：usbip：
    修正 usbip_recv_iso() 中的整數溢位，v2) 可強化接收端函式本身；此修補程式可在其來源 (覆寫前的 usbip_pack_ret_submit() 中) 擷取錯誤值，並使用更嚴格的 per-URB 配置邊界，而非全域 USBIP_MAX_ISO_PACKETS 限制，藉此補充上述工作。透過在覆寫前於 usbip_pack_ret_submit() 中比對 rpdu->number_of_packets 與 urb->number_of_packets 是否一致，可修正此問題。發生違規時，箝制為零，以便 usbip_recv_iso() 和 usbip_pad_iso() 安全提早傳回。(CVE-2026-31607)

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

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

  - NFC：數位：邊界檢查 SDD 回應處理常式中的 NFC-A 級聯深度 digital_in_recv_sdd_res（） 中的 NFC-A 防衝突級聯會在每一輪的 target->nfcid1 上附加 3 或 4 個位元組，但級聯輪數完全由對等裝置控制。對等體在SDD_RES中設定級聯標籤（決定 3 與 4 位元組），並在SEL_RES中設定級聯不完整位（決定是否後續進行另一輪）。 ISO 14443-3 將 NFC-A 限制為三個串聯層級，而 target->nfcid1 會相應地調整大小 （NFC_NFCID1_MAXSIZE = 10） ，但驅動程式中沒有任何內容實際強制執行此動作。這表示惡意對等體可以維持級聯執行，並在每一輪中寫入堆積配置的nfc_target。當累積的 UID 超過緩衝區時，拒絕回應來修正此問題。提交 e329e71013c9 （NFC：nci：邊界檢查結構nfc_target陣列） 修正了針對 NCI 路徑上相同欄位的類似遺漏檢查。（CVE-2026-31622）

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

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

  - net：lan966x：修正 use-for-free 及 lan966x_fdma_reload（） 洩漏問題 ） 當 lan966x_fdma_reload（） 未能分配新的 RX 緩衝區時，還原路徑會用已透過 lan966x_fdma_rx_free_pages（） 釋放的舊描述符重新啟動 DMA。由於 page_pool_put_full_page（） 可以將頁面釋放回夥伴配置器，硬體可能會將 DMA 傳送到其他核心子系統擁有的記憶體中。此外，在還原路徑上，若部分配置成功，新建立的頁面池會被覆寫且未被刪除，導致洩漏。解決這兩個問題的方法，就是延後舊頁面的釋出，直到新分配成功之後再進行。在分配前先儲存舊頁面陣列，這樣成功路徑上可以釋放舊頁面。在失敗路徑上，舊的描述符、頁面和頁面池都仍然有效，使還原安全。同時確保還原路徑能重新啟用 NAPI 並喚醒 netdev，與成功路徑相符。（CVE-2026-31644）

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

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

  - drm/mediatekdsi在叫用 mipi_dsi_host_register 之前先儲存驅動程式資料。對 mipi_dsi_host_register 的呼叫會觸發對 mtk_dsi_bind 的回呼其使用 dev_get_drvdata 擷取 mtk_dsi 結構因此在叫用此結構之前必須先將其儲存在驅動程式資料內。由於 drvdata 目前未初始化若在取得 mode_config.idr_mutex 之後立即註冊 DSI DRM 編碼器會導致當機進而封鎖所有後續 DRM 作業。修正 mediatek-drm 探查期間發生的下列損毀問題 (在 Xiaoxian Smart Clock x04g 上測試)無法處理虛擬位址 0000000000000040 的核心 NULL 指標解除參照 [...] 連結於的模組mediatek_drm(+) drm_display_helper cec drm_client_lib drm_dma_helper drm_kms_helper Panel_simple [. ..] Call trace: drm_mode_object_add+0x58/0x98 (P) __drm_encoder_init+0x48/0x140 drm_encoder_init+0x6c/0xa0 drm_simple_encoder_init+0x20/0x34 [drm_kms_helper] mtk_dsi_bind+0x34/0x13c [mediatek_drm] component_bind_all+0x120/0x280 mtk_drm_bind+0x284/0x67c [mediatek_drm] try_to_bring_up_aggregate_device+0x23c/0x320
    __component_add+0xa4/0x198 component_add+0x14/0x20 mtk_dsi_host_attach+0x78/0x100 [mediatek_drm] mipi_dsi_attach+0x2c/0x50 panel_simple_dsi_probe+0x4c/0x9c [panel_simple] mipi_dsi_drv_probe+0x1c/0x28 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/ 0x120
    __device_attach_driver+0xbc/0x17c bus_for_each_drv+0x88/0xf0 __device_attach+0x9c/0x1cc device_initial_probe+0x54/0x60 bus_probe_device+0x34/0xa0 device_add+0x5b0/0x800 mipi_dsi_device_register_full+0xdc/0x16c mipi_dsi_host_register+0xc4/0x17c mtk_dsi_probe+0x10c/0x260 [mediatek_drm] platform_probe+ 0x5c/0xa4 real_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x24/0x30 bus_add_driver+0x11c/0x24130_register+x068/0x240_register+x068
    __platform_register_drivers+0x64/0x160 mtk_drm_init+0x24/0x1000 [mediatek_drm] do_one_initcall+0x60/0x1d0 do_init_module+0x54/0x240 load_module+0x1838/0x1dc0 init_module_from_file+0xd8/0xf0
    __arm64_sys_finit_module+0x1b4/0x428 invoke_syscall.constprop.0+0x48/0xc8 do_el0_svc+0x3c/0xb8 el0_svc+0x34/0xe8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800022 941004ab 2a0003f3 37f80040 (29005a80) (CVE-2026-31562)

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

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

  - ocfs2：修正 ocfs2_fault（） 中的釋放後使用，當 VM_FAULT_RETRY filemap_fault（） 可能會在傳回 VM_FAULT_RETRY 之前刪除mmap_lock時，如 mm/filemap.c 中所述：如果我們的傳回值設定VM_FAULT_RETRY，這是因為在執行 I/O 之前或被 lock_folio_maybe_drop_mmap（） 刪除mmap_lock。發生這種情況時，並發的 munmap（） 可以呼叫 remove_vma（） 並透過 RCU 釋放vm_area_struct。然後，在 ocfs2_fault（） 中儲存的 'vma' 指標會變成一個懸空指標，後續的 trace_ocfs2_fault（） 呼叫會取消參照它 -- 釋放後使用。在呼叫 filemap_fault（） 之前將ip_blkno儲存為純整數，並從追蹤事件中移除 vma，以修正此問題。由於ip_blkno在刪除鎖定之前會按值複製，因此無論之後 vma 或 inode 發生什麼情況，它都保持有效。
    (CVE-2026-31597)

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

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

  - smb伺服器使用 smbdirect_socket.send_io.bcredits 結果當我們觸發立即 (空白) 傳送時我們的程式碼會損毀已重新判定資料傳輸訊息的資料流。為了修正此問題我們將為每個連線設定一個單一的「批次」額度。取得該額度的程式碼可免費使用盡可能多的訊息直到剩余長度達到 0 為止然後可發生其提供的批次額度及下一次邏輯傳送。 (CVE-2026-31537)

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom Since upstream commit e75665dd0968 (wifi: wlcore: ensure skb headroom before skb_push), wl1271_tx_allocate() and with it wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails. However, in wlcore_tx_work_locked(), a return value of -EAGAIN from wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being full. This causes the code to flush the buffer, put the skb back at the head of the queue, and immediately retry the same skb in a tight while loop. Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens immediately with GFP_ATOMIC, this will result in an infinite loop and a CPU soft lockup. Return -ENOMEM instead so the packet is dropped and the loop terminates. The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. (CVE-2026-31552)

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

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

  - drm/amdgpu：修正 等待前設置的圍欄 在 amdgpu_amdkfd_submit_ib amdgpu_amdkfd_submit_ib（） 提交 GPU 工作並從 amdgpu_ib_schedule（） 獲得圍欄。這道圍欄用來等待工程完成。目前，程式碼會先使用 dma_fence_put（） 來移除圍欄參考，然後再呼叫 dma_fence_wait（）。若dma_fence_put（）釋放最後一個參考，圍欄可在dma_fence_wait（）被呼叫前被釋放。
    這可能導致免費使用後的使用。解決方法是先等待 fentry 狀態，並在 dma_fence_wait（） 完成後才釋放參考。修正以下問題：drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c：697 amdgpu_amdkfd_submit_ib（） 警告：傳入釋放記憶體 'f'（第 696 行）（從 commit 8b9e5259adc385b61a6590a 13b82ae0ac2bd3482 挑選）CVE-2026-31566 （）

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

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

  - NFC：nxp-nci：允許 GPIO 進入睡眠狀態 允許韌體並啟用 GPIO 進入睡眠狀態。這修復了“WARN_ON”，並允許驅動程序操作連接到 I2C GPIO 擴展器的 GPIO。-- >8 -- 核心：
    警告：CPU：3 PID：2636，位於 drivers/gpio/gpiolib.c：3880 gpiod_set_value+0x88/0x98 -- >8 -- （CVE-2026-31545）

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

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

  - i2ccp2615修正探查時的序列字串 NULL-deref。cp2615 驅動程式使用 USB 裝置序列字串作為 i2c 介面卡名稱但未確認該字串是否存在。存取裝置前請先驗證該裝置是否有序號以避免觸發 NULL 指標解除參照 (例如利用惡意裝置觸發)。
    (CVE-2026-31549)

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

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

  - 已解決 Linux 核心中的下列弱點：LoongArch: Fix missing NULL checks for kstrdup() 1. Replace of_find_node_by_path(/) with of_root to avoid multiple calls to of_node_put(). 2. Fix a potential kernel oops during early boot when memory allocation fails while parsing CPU model from device tree. (CVE-2026-31559)

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

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

  - mediavidtv修正 start_streaming 失敗時發生的 nfeeds 狀態損毀 syzbot 報告 vidtv_psi_service_desc_init [1] 中有記憶體洩漏問題。當 vidtv_start_streaming() 在 vidtv_start_feed() 內失敗時即使實際上未啟動任何摘要nfeeds 計數器仍會保持遞增。這會損毀驅動程式狀態
    後續的 start_feed 呼叫會看到 nfeeds > 1 並略過啟動 mux而 stop_feed 呼叫最終會嘗試停止不存在的資料流。此狀態損毀也可導致記憶體洩漏因為在失敗的 start_streaming 期間可能會配置部分 mux 和通道資源但從未清理過因為停止路徑發現 dvb->streaming == false 並提早傳回。修正的方式是在 start_streaming 失敗時往前遞減 nfeeds使計數器與使用中摘要的實際數量保持同步。 [1] 錯誤記憶體洩漏未參照的物件 0xffff888145b50820 (大小 32)comm syz.0.17、pid 6068、jiffies 4294944486 反向追踪 (crc 90a0c7d4)vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c 288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/ test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [內嵌] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 (CVE-2026-31585)

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

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

  - drm/i915/gt：修正 intel_engine_park_heartbeat 中的參照計數反向溢位 當活動訊號工作程式和 intel_engine_park_heartbeat（） 爭用釋放相同的 engine->heartbeat.systole 要求時，可能會發生釋放後使用/參照計數反向溢位。活動訊號工作程式會讀取 engine->heartbeat.systole 並在要求完成時呼叫 i915_request_put（），但在單獨的非不可部分完成步驟中清除指標。同時，另一個 CPU 上的請求淘汰可能會將引擎喚醒參考降至零，從而觸發
    __engine_park（） -> intel_engine_park_heartbeat（）。如果活動訊號計時器此時處於擱置狀態，則 cancel_delayed_work（） 傳回 true，而 intel_engine_park_heartbeat（） 會讀取過時的非空收縮指標，並再次呼叫 i915_request_put（），從而造成參照計數反向溢位： ''' <4> [487.221889] 工作佇列：i915-無序engine_retire [i915] <4> [487.222640] RIP：0010：refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] 呼叫追蹤： <4> [487.222711] [487.222716] <TASK> <4> intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973]
    ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ？
    __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ？
    __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ？
    __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] </TASK> ''' 透過在兩個競速路徑中將非原子指標 read + separate clear 替換為 xchg（） 來修正此問題。 xchg（） 是一個不可分割的硬體指令，它以原子方式讀取舊指標並寫入 NULL。這保證兩個並行呼叫端中的一個只會取得非 NULL 指標並執行放置，另一個會取得 NULL 並略過它。（從提交 13238dc0ee4f9ab8dafa2cca7295736191ae2f42 中挑選）（CVE-2026-31656）

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

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

  - hwmon：（powerz） 修正 USB 中斷連線時的釋放後使用 powerz_disconnect（） 釋放 URB 並釋放互斥之後，後續的 powerz_read（） 呼叫可以取得互斥並呼叫 powerz_read_data（），這會取消參照釋放的 URB 指標。修正方式： - 在 powerz_disconnect（） 中將 priv->urb 設定為空，以便 powerz_read_data（） 可以偵測中斷連線的狀態。- 在 powerz_read_data（） 的開頭新增 ！priv->urb 檢查，以在中斷連線的裝置上傳回 -ENODEV。- 在 hwmon 註冊之前移動 usb_set_intfdata（），以便中斷連接處理常式始終可以找到 priv 指標。（CVE-2026-31582）

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

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

  - media：as102：修正在 as102_usb_probe（） 中註冊裝置後不釋放記憶體的問題 在as102_usb驅動程式中，會發生下列爭用情形： ''' CPU0 CPU1 as102_usb_probe（） kzalloc（）;分配as102_dev_t ....usb_register_dev（）;fd = sys_open（/path/to/dev）;打開 AS102 FD ....
    usb_deregister_dev（）;....kfree（）;免費as102_dev_t ....sys_close（fd）;as102_release（） // UAF！！as102_usb_release（） kfree（）;德國央行！！''' 當以 usb_register_dev（） 註冊的 USB 字元裝置稍後取消註冊 （透過 usb_deregister_dev（） 或中斷連線） 時，裝置節點會移除，因此新的 open（） 呼叫會失敗。然而，已經開啟的檔案描述元不會立即消失：它們一直有效，直到刪除最後一個參照並叫用驅動程式的 .release（） 為止。在 as102 中，as102_usb_probe（） 呼叫 usb_register_dev（），然後在錯誤路徑上執行 usb_deregister_dev（） 並立即釋放as102_dev_t。如果使用者空間在取消註冊之前成功爭用 open（），則該開放的 FD 稍後將點擊 as102_release（） --> as102_usb_release（） 並再次存取或釋放as102_dev_t，從而發生釋放後使用和雙重釋放漏洞的競爭。修復方法是一旦 usb_register_dev（） 成功，就永遠不要直接 kfree（as102_dev_t）。取消註冊後，將釋放記憶體推遲到 .release（）。換句話說，當最終打開的 FD 關閉時，讓 release（） 執行最後一個 kfree。（CVE-2026-31578）

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

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

  - ocfs2：修正取消連結和 dio_end_io_write ocfs2_unlink 之間可能的鎖死，會先inode_lock孤立的目錄，然後再ip_alloc_sem，而在ocfs2_dio_end_io_write中，它會以相反的順序取得這些鎖定。
    這會在鎖定類別 ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] 和 ocfs2_file_ip_alloc_sem_key 上建立 ABBA 鎖定順序違規。鎖定鏈結 #0 （孤立的目錄 inode_lock -> ip_alloc_sem）：ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock（orphan_dir_inode） <- 鎖定 A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write（&oi->ip_alloc_sem） <- 鎖定 B 鎖定鏈結 #1 （ip_alloc_sem ->孤立的目錄 inode_lock）： ocfs2_dio_end_io_write down_write（&oi->ip_alloc_sem） <- 鎖定 B ocfs2_del_inode_from_orphan（） inode_lock（orphan_dir_inode） <- 鎖定 A 鎖死案例： CPU0 （取消連結） CPU1 （dio_end_io_write） ------ ------ inode_lock（orphan_dir_inode） down_write（ip_alloc_sem） down_write（ip_alloc_sem） inode_lock（orphan_dir_inode） 由於ip_alloc_sem是為了保護分配變更， 這與ocfs2_del_inode_from_orphan中的操作無關。因此，ocfs2_del_inode_from_orphan從ip_alloc_sem移出以修復鎖死。（CVE-2026-31598）

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

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

  - 已解決 Linux 核心中的下列弱點：clockevents: Add missing resets of the next_event_forced flag The prevention mechanism against timer interrupt starvation missed to reset the next_event_forced flag in a couple of places: - When the clock event state changes. That can cause the flag to be stale over a shutdown/startup sequence - When a non-forced event is armed, which then prevents rearming before that event. If that event is far out in the future this will cause missed timer interrupts. - In the suspend wakeup handler. That led to stalls which have been reported by several people. Add the missing resets, which fixes the problems for the reporters. (CVE-2026-31574)

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

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

  - smb： client：修正 OOB 讀取剖析符號連結錯誤回應 當 CREATE 傳回 STATUS_STOPPED_ON_SYMLINK時，smb2_check_message（） 傳回成功而不進行任何長度驗證，讓符號連結剖析器成為防止不受信任伺服器的唯一防禦措施。symlink_data（） 會以迴圈測試 p <結束來遍歷 SMB 3.1.1 錯誤內容，但在位移 4 處讀取 p->ErrorId，在位移 0 處讀取 p->ErrorDataLength。當伺服器控制的 ErrorDataLength 將 p 前進到 end 的 1-7 位元組以內時，下一次反覆專案將讀取它。找到相符的內容時，會在位移 4 處從 p->ErrorContextData 讀取 sym->SymLinkErrorTag，而不檢查符號連結標頭本身是否適合。然後，smb2_parse_symlink_response（） 使用 SMB2_SYMLINK_STRUCT_SIZE 作為 PathBuffer 與iov_base的偏移量來檢查替代名稱。該值的計算方式為 sizeof（smb2_err_rsp） + sizeof（smb2_symlink_err_rsp），只有在 ErrorContextCount == 0 時才正確。
    對於至少一個錯誤上下文，符號連結資料會加深 8 個位元組，並且每個跳過的不相符上下文都會將其進一步移動 8 + ALIGN（ErrorDataLength， 8）。檢查太短，導致讀取的替代名稱超出iov_len。越界堆位元組被 UTF-16 解碼到符號連結目標中，並透過 readlink（2） 傳回使用者空間。藉由使迴圈測試需要完整的上下文標頭來適應，如果標頭運行超過結尾，則拒絕 sym，並將替代名稱綁定到 sym->PathBuffer 的實際位置，而不是固定位移，從而解決所有問題。因為 sub_offs 和 sub_len 是 16 位元，所以指標數學不會在這裡用新的大於溢位。（CVE-2026-31613）

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

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

  - PCI端點pci-epf-vntb停止 epf_ntb_epc_cleanup 中的 cmd_handler 工作。停用清除 BAR 對應和門鈴前的延遲工作避免在資源中斷後執行處置程式。
    無法在虛擬位址 ffff800083f46004 [...] 處理核心分頁要求 [...] 內部錯誤Oops
    0000000096000007 [#1] SMP [...] 呼叫追踪epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0xCVE-2026-31595)

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

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

  - batman-adv：透過參照保留宣告骨幹閘道 batadv_bla_add_claim（） 可以取代宣告>backbone_gw，並在讀取器仍遵循指標時刪除舊閘道的最後一個參照。網路連結宣告傾印路徑會解除參照 claim->backbone_gw->orig 並採用宣告 >backbone_gw->crc_lock，而不釘選基礎骨幹閘道。batadv_bla_check_claim（） 仍然具有相同的裸指標存取模式。在兩個讀取器中重複使用 batadv_bla_claim_get_backbone_gw（），以便它們在穩定的閘道參照上運作，直到讀取端工作完成為止。如此一來，傾印和宣告檢查路徑會與其他 BLA 宣告讀取程式所引入的存留期規則保持一致。（CVE-2026-31657）

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

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

  - media：mediatek：vcodec：修正編碼器發行路徑中的釋放後使用 fops_vcodec_release（） 函式可釋放上下文結構 （ctx），而無需先取消 ctx->encode_work 中任何擱置或執行中的工作。這會建立一個爭用視窗，其中工作佇列處理常式 （mtk_venc_worker） 在釋放內容記憶體之後可能仍在存取內容記憶體。爭用情形：CPU 0 （釋放路徑） CPU 1 （工作佇列） --------------------- ------------------ fops_vcodec_release（） v4l2_m2m_ctx_release（） v4l2_m2m_cancel_job（） // 等待 m2m 工作完成 mtk_venc_worker（） v4l2_m2m_job_finish（） // m2m 工作完成 // 但背景工作仍在執行！ post-job_finish access： other ctx 取消參照 // 如果 ctx 已釋放，則 UAF // 傳回 （工作完成） kfree（ctx） // ctx 已釋放 根本原因：v4l2_m2m_ctx_release（） 僅等待 m2m 工作生命週期 （透過 TRANS_RUNNING 標誌），而不是工作佇列生命週期。呼叫 v4l2_m2m_job_finish（） 後，m2m 框架認為作業完成並傳回 v4l2_m2m_ctx_release（），但工作函數繼續執行並且仍可能存取 ctx。在編碼作業期間，工作會透過以下方式排入佇列： queue_work（ctx->dev->encode_workqueue， &ctx->encode_work） 即使在呼叫 v4l2_m2m_job_finish（） 之後，worker 函式仍會存取 ctx->m2m_ctx、ctx->dev 和其他 ctx 欄位。KASAN 透過執行可擴大 post-job_finish 爭用視窗的檢測測試模組來確認此漏洞。偵測到 KASAN： 錯誤： KASAN：mtk_venc_worker+0x159/0x180 中的 slab-use-after-free 由任務 kworker/u8：0/12 在 addr ffff88800326e000 讀取大小 4 工作佇列：mtk_vcodec_enc_wq mtk_venc_worker 由任務 47 分配：__kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 由任務 47 釋放：__kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 透過在 kfree（ctx） 之前呼叫 cancel_work_sync（&ctx->encode_work） 來修正此問題。這可確保工作佇列處理常式在釋放內容之前，已取消 （如果擱置中） 和同步處理 （等候任何執行中的處理常式完成）。放置理由：修正會放置在 v4l2_ctrl_handler_free（） 之後和 list_del_init （&ctx->list） 之前。此時，所有的m2m操作都完成了（v4l2_m2m_ctx_release（）已經傳回），我們需要確保工作佇列是同步的，然後才能從清單中移除ctx並釋放它。附註： 開啟錯誤路徑不需要 cancel_work_sync（），因為 INIT_WORK（） 只會起始設定工作結構 - 它不會排程它。只有在稍後的 device_run（） 作業期間才會排程工作。（CVE-2026-31584）

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

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

  - 已解決 Linux 核心中的下列弱點：bnge: return after auxiliary_device_uninit() in error path When auxiliary_device_add() fails, the error block calls auxiliary_device_uninit() but does not return. The uninit drops the last reference and synchronously runs bnge_aux_dev_release(), which sets bd->auxr_dev = NULL and frees the underlying object. The subsequent bd->auxr_dev->net = bd->netdev then dereferences NULL, which is not a good thing to have happen when trying to clean up from an error. Add the missing return, as the auxiliary bus documentation states is a requirement (seems that LLM tools read documentation better than humans do...) (CVE-2026-31621)

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

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

  - ocfs2：處理 fs/ocfs2/resize.c：308 的 ocfs2_group_extend [BUG] 核心錯誤中無效的 dinode！哎呀：
    無效的操作碼：0000 [#1] SMP KASAN NOPTI RIP：0010：ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c：308 代碼：8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe 呼叫追蹤：...ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c：869 vfs_ioctl fs/ioctl.c：51 [內嵌] __do_sys_ioctl fs/ioctl.c：597 [內嵌]
    __se_sys_ioctl fs/ioctl.c：583 [內嵌] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c：583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h：17 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend（） 假設從 ocfs2_inode_lock（） 傳回的全域點陣圖 inode 區塊已經經過驗證，並在簽名不是 dinode 時BUG_ONs。對於特製的檔案系統來說，這個假設太強了，因為 JBD2 管理的緩衝區路徑可能會繞過結構驗證，並將無效的 dinode 傳回給調整大小的 ioctl。[修復]在 ocfs2_group_extend（） 中明確驗證 dinode。如果全域點陣圖緩衝區不包含有效的 dinode，請使用 ocfs2_error（） 報告檔案系統損毀，並使調整大小作業失敗，而不是使核心當機。（CVE-2026-31596）

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

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

  - usb： gadget： f_hid：不要在 cdev 使用時呼叫 cdev_init 當呼叫 unbind，然後再次綁定時，cdev_init重新初始化了 cdev，即使可能仍然有對它的引用。當 /dev/hidg* 裝置仍處於開啟狀態時，就是這種情況。這種明顯不安全的行為就像 oopes 一樣。這透過使用 cdev_alloc 將 cdev 放在堆積上來解決此問題。這樣，我們就可以簡單地在hidg_bind中分配一個新的。
    (CVE-2026-31606)

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

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

  - nfc：llcp：LLCP_CLOSED檢查後新增遺漏的返回 在 nfc_llcp_recv_hdlc（） 和 nfc_llcp_recv_disc（） 中，當通訊端狀態為 LLCP_CLOSED 時，程式碼正確呼叫 release_sock（） 和 nfc_llcp_sock_put（），但無法返回。執行會落入函式的其餘部分，該函式會再次呼叫 release_sock（） 和 nfc_llcp_sock_put（）。這會導致雙 release_sock（） 和透過雙 nfc_llcp_sock_put（） 的參照計數下溢，從而導致釋放後使用。在這兩個函式中LLCP_CLOSED分支之後新增缺少的 return 陳述式，以防止貫穿。（CVE-2026-31629）

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

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

  - batman-adv：拒絕過大的全域 TT 回應緩衝區。batadv_tt_prepare_tvlv_global_data() 會在 16 位元暫存項目中構建全域 TT 回應的配置長度。當遠端始作者公告一個足夠大的全域 TT 時，TT 承載長度加上 VLAN 標頭位移可超過 65535，並在 kmalloc() 之前換行。填滿 tt_change 時，完整表格回應路徑仍使用原始 TT 承載長度，因此包裝的配置太小，且 batadv_tt_prepare_tvlv_global_data() 會在之後的封包大小檢查執行前，寫入超過堆積物件的結尾。透過拒絕其 TVLV 值長度無法容納在 16 位元 TVLV 承載長度欄位中的 TT 回應來修正此問題。 (CVE-2026-31659)

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

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

  - ksmbd當 SPNEGO 解碼在 token 配置後失敗時修正 mechToken 洩漏。核心 ASN.1 BER 解碼器在遍歷輸入時以遞增方式呼叫動作回呼。當 ksmbd_decode_negTokenInit() 到達 mechToken [2] OCTET STRING 元素時ksmbd_neg_token_alloc() 會立即透過 kmemdup_nul() 配置 conn->mechToken。如果相同 blob 中的後續元素格式錯誤則解碼器將在配置生效後傳回非零。如果 mechListMIC [3] 超出封閉的 SEQUENCE 可能會發生此情況。然後decode_negotiation_token() 會設定 conn->use_spnego = false因為 negTokenInit 和 negTokenTarg 文法皆失敗。smb2_sess_setup() 底部的清理在 use_spnego 上有閘道 if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL因此會略過 kfree造成 mechToken 永遠不會被釋放。此程式碼路徑為驗證前可連線因此未受信任的用戶端可在未經正確驗證的情況下造成伺服器上的緩慢記憶體洩漏。透過不檢查 use_spnego 的檢查來修正此問題因為這並非必要程序因此記憶體將一律正確釋放。同時一律釋放 ksmbd_conn_free() 中的記憶體以防其他失敗路徑忘記釋放記憶體。 (CVE-2026-31610)

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

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

  - mmc：vub300：修正中斷連接時的 NULL 解除參照 請務必在中斷連接時卸除驅動程式資料的參照之前，先取消註冊控制器，以避免 NULL 指標解除參照或釋放後使用。
    (CVE-2026-31651)

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

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

  - USB： gadget： renesas_usb3：驗證標準要求處理常式中的端點索引 GET_STATUS 和 SET/CLEAR_FEATURE 處理常式會從主機提供的 wIndex 擷取端點編號，而不進行任何類型的驗證。在嘗試根據此數學計算取消參照指標之前，驗證端點數目是否與裝置實際相符的數目來修正此問題。這就像在 aspeed 驅動程式的提交 ee0d382feb44 （usb： gadget： aspeed_udc： validate endpoint index for ast udc） 中所做的一樣。（CVE-2026-31615）

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

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

  - SMB：伺服器：讓 send_done 在沒有 IB_SEND_SIGNALED 的情況下處理完成 在smbdirect_send_batch 處理中，我們可能會有沒有 IB_SEND_SIGNALED 的請求，這些請求將在設定 IB_SEND_SIGNALED 的最終請求中遭到銷毀。如果連線中斷，即使沒有明確 IB_SEND_SIGNALED，所有要求都會發出訊號。（CVE-2026-31536）

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

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

  - ASoC： qcom： q6apm：將元件登錄移至非受管理版本 q6apm 元件暫存器 DAI 從 ASoC 拓蹼動態配置，這些 DAI 是使用裝置受管理版本 API 配置的。使用受控版本配置元件和動態 DAI 可能會導致不正確的自由排序，當元件仍保留對它的引用時，dai 將被釋放。藉由將元件移至未管理版本來修正此問題，讓 dai 指標只有在移除元件之後才會釋放。
    ================================================================== 錯誤：KASAN：snd_soc_del_component_unlocked+0x3d4/0x400 中的 slab-use-after-free [snd_soc_core] 任務 kworker/u48：0/3426 在 addr ffff00084493a6e8 讀取大小 8 污染：[W]=WARN 硬體名稱：LENOVO 21N2ZC5PUS/21N2ZC5PUS，BIOS N42ET57W （1.31 ） 08/08/2024 工作佇列：pdr_notifier_wq pdr_notifier_work [pdr_interface] 呼叫追蹤：show_stack+0x28/0x7c （C） dump_stack_lvl+0x60/0x80 print_report+0x160/0x4b4 kasan_report+0xac/0xfc
    __asan_report_load8_noabort+0x20/0x34 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] devm_component_release+0x30/0x5c [snd_soc_core] devres_release_all+0x13c/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [4 月]device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [4 月] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 由任務 77 分配：kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x44/0x58 __kasan_kmalloc+0xbc/0xdc __kmalloc_node_track_caller_noprof+0x1f4/0x620 devm_kmalloc+0x7c/0x1c8 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] audioreach_tplg_init+0x124/0x1fc [snd_q6apm] q6apm_audio_probe+0x10/0x1c [snd_q6apm] snd_soc_component_probe+0x5c/0x118 [snd_soc_core] soc_probe_component+0x44c/0xaf0 [snd_soc_core] snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] platform_probe+0xc0/0x188 really_probe+0x188/0x804 __driver_probe_device+0x158/0x358 driver_probe_device+0x60/0x190 __device_attach_driver+0x16c/0x2a8 bus_for_each_drv+0x100/0x194
    __device_attach+0x174/0x380 device_initial_probe+0x14/0x20 bus_probe_device+0x124/0x154 deferred_probe_work_func+0x140/0x220 process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 由任務 3426 釋放：kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 __kasan_save_free_info+0x4c/0x80 __kasan_slab_free+0x78/0xa0 kfree+0x100/0x4a4 devres_release_all+0x144/0x210 device_unbind_cleanup+0x20/0x190device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [4 月] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [4 月] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 （CVE-2026-31587）

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

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

  - nilfs2：修正 nilfs_mdt_save_to_shadow_map 中的 NULL i_assoc_inode取消參照 DAT inode 的 btree 節點快取 （i_assoc_inode） 在 btree 作業期間延遲初始化。但是，在 GC 期間將髒頁面複製到陰影貼圖時，nilfs_mdt_save_to_shadow_map（） 假設 i_assoc_inode 已經初始化。如果在 DAT inode 上發生任何 btree 作業之前，在掛載後立即呼叫 NILFS_IOCTL_CLEAN_SEGMENTS，則 i_assoc_inode 為 NULL，導致一般保護錯誤。透過在裝載時在 nilfs_dat_read（） 中呼叫 DAT inode 上的 nilfs_attach_btree_node_cache（） 來解決此問題，確保在任何 GC 操作可以使用它之前始終初始化 i_assoc_inode。（CVE-2026-31577）

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

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

  - ksmbd：讀取前需要 3 個子授權單位 sub_auth[2] parse_dacl（） 會將每個 ACE SID 與 sid_unix_NFS_mode 進行比較，並在比對時讀取 sid.sub_auth[2] 作為檔案模式。如果 sid_unix_NFS_mode 是前置詞 S-1-5-88-3 且 num_subauth = 2，則 compare_sids（） 僅比較 min（num_subauth， 2） 子授權單位，因此 num_subauth = 2 且 sub_auth = {88， 3} 的用戶端 SID 將相符。如果 num_subauth = 2 且 ACE 位於安全性描述元的最末尾，則 sub_auth[2] 將比 end_of_acl 多 4 個位元組。然後，帶外位元組將被遮罩為低 9 位並應用為檔案的 POSIX 模式，這可能不是一件好事。透過強制 SID 在讀取第三個子授權單位之前實際攜帶第三個子授權單位來解決這個問題。（CVE-2026-31611）

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

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

  - ksmbd：驗證 smb2_get_ea（） 中的 EaNameLength smb2_get_ea（） 會從用戶端要求讀取 ea_req->EaNameLength，並將它直接傳遞至 strncmp（） 作為比較長度，而不驗證名稱的長度是否確實是收到的輸入緩衝區大小。根據收到的值和要求的整體大小，正確檢查名稱的大小，以防止稍後的 strncmp（） 呼叫使用長度作為緩衝區的受信任大小，以修正此問題。如果沒有此檢查，未初始化的堆積值可能會慢慢洩漏給用戶端。（CVE-2026-31612）

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

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

  - 暫存：rtl8723bs：在 rtw_BIP_verify（） 中初始化 le_tmp64 在 rtw_BIP_verify（） 中初始化 le_tmp64 為零，以防止使用未初始化的資料。Smatch 警告只有 6 個位元組被複製到這個 8 位元組 （u64） 變數中，而最後兩個位元組未初始化：
    drivers/staging/rtl8723bs/core/rtw_security.c：1308 rtw_BIP_verify（） 警告：未為「&le_tmp64」複製足夠的位元組 （8 vs 6 位元組） 在函式開頭初始化變數可修正此警告並確保可預測的行為。（CVE-2026-31626）

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

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

  - Deskflow 是一款鍵盤和鼠標共享應用程序。之前 1.26.0.138，Deskflow 剪貼簿反序列化中的遠端記憶體安全弱點允許連接的對等體透過傳送格式錯誤的剪貼簿更新來觸發越界讀取。問題出在 src/lib/deskflow/IClipboard.cpp 的實作中。這是可以實現的，因為 src/lib/deskflow/ClipboardChunk.cpp 中的 ClipboardChunk：：assemble（） 僅驗證外部剪貼簿傳輸大小。它不會驗證序列化剪貼簿 blob 的內部結構，因此格式錯誤的內部長度會以不變的方式達到 IClipboard：：unmarshall（）。此弱點已在 1.26.0.138 中修正。(CVE-2026-41476)

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

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

  - FreeRDP 是遠端桌面通訊協定的免費實作。 3.25.0 之前的版本在 `channels/drive/client/drive_file.c` 的路徑遊走篩選器中有一個差一。`contains_dotdot()` 函式可擷取 `../` 和 `..\` mid-path但在其為無結尾分隔符號的最後一個元件時會遺漏 `..`。
    惡意 RDP 伺服器可透過 RDPDR 要求讀取、列出或寫入位於用戶端共用資料夾上一個目錄的檔案。這需要受害者在啟用磁碟機重新導向的情況下連線。版本 3.25.0 針對此問題提供了修補程式。(CVE-2026-40254)

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

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

  - NET：lan966x：lan966x_fdma_rx_alloc_page_pool（） page_pool_create（） 中錯誤處理page_pool修正，故障時可返回ERR_PTR。回傳值在隨後的迴圈中無條件使用，將錯誤指標通過 xdp_rxq_info_reg_mem_model（） 進入 page_pool_use_xdp_mem（），導致該指標去參照，造成核心失誤。在page_pool_create（）後加IS_ERR檢定，讓失敗時能早點回來。
    (CVE-2026-31646)

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

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

  - 已解決 Linux 核心中的下列弱點：smb: server: avoid double-free in smb_direct_free_sendmsg after smb_direct_flush_send_list() smb_direct_flush_send_list() already calls smb_direct_free_sendmsg(), so we should not call it again after post_sendmsg() moved it to the batch list.
    (CVE-2026-31608)

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

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

  - net：lan966x：修正錯誤路徑中的頁面集區洩漏 lan966x_fdma_rx_alloc（） 會建立頁面集區，但如果後續 fdma_alloc_coherent（） 呼叫失敗，則不會銷毀它，從而洩漏集區。同樣地，當 lan966x_fdma_tx_alloc（） 失敗時，lan966x_fdma_init（） 會釋放一致的 DMA 記憶體，但不會破壞 lan966x_fdma_rx_alloc（） 成功建立的頁面集區，從而洩漏它。在兩個錯誤路徑中新增缺少的 page_pool_destroy（） 呼叫。（CVE-2026-31645）

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

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

  - nfcpn533在消耗位元組之前配置 rx skb pn532_receive_buf() 會向 serdev 核心報告已接受的位元組數目。目前的程式碼會消耗 recv_skb 中的位元組且在配置新的接收緩衝區之前可能已將完整框架交給 pn533_recv_frame()。如果 alloc_skb() 失敗即使已消耗位元組回呼也會傳回 0並將 recv_skb 保留為 NULL以供下次接收回呼使用。這會破壞 receive_buf() 計量合約而且也會導致下一個 skb_put_u8() 發生 NULL 解除參照。改為在消耗下一個位元組之前消極地配置接收 skb。若配置失敗則傳回已接受的位元組數目。 (CVE-2026-31660)

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

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

  - ALSA：ctxfi：將 PTP 限制為單一頁面 提交 391e69143d0a 將CT_PTP_NUM從 1 增加到 4，以支援 256 個播放串流，但卡片無法正確使用其他頁面。CT20K2 硬體已經有多個VMEM_PTPAL暫存器，但單獨使用它們需要重構整個虛擬記憶體配置邏輯。無論CT_PTP_NUM為何，ct_vm_map（） 一律使用 vm->ptp[0].area 中的 PTE。
    在系統上 AMD64 ，單一 PTP 涵蓋 512 個 PTE （2M）。當聚合記憶體配置超過此限制時，ct_vm_map（） 會嘗試存取超出配置的空間並導致頁面錯誤： 錯誤：無法處理位址的頁面錯誤：ffffd4ae8a10a000 哎呀：哎呀：0002 [#1] SMP PTI RIP：0010：ct_vm_map+0x17c/0x280 [snd_ctxfi] 呼叫追蹤：atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e 將CT_PTP_NUM還原為 1。256 SRC_RESOURCE_NUM和playback_count保持不變。（CVE-2026-31602）

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

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

  - Authlib 是一種 Python 程式庫，可構建 OAuth 和 OpenID Connect 伺服器。 1.6.11之前的版本中authlib.integrations.starlette_client.OAuth 的快取功能沒有 CSRF 保護。此弱點已在 1.6.11 中修正。(CVE-2026-41425)

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

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

  - drm/i915/gt：在推銷前檢查 set_default_submission（） 當 i915 驅動韌體二進位檔不存在時，set_default_submission指標未設定。這個指標在暫停期間會被取消參考。在取消參考前，先檢查確定設定已設定。[ 23.289926] PM：暫停進入（深度） [23.293558] 檔案系統同步： 0.000 秒數 [ 23.298010] 凍結使用者空間程序 [ 23.302771] 凍結用戶空間程序完成（經過秒 0.000 數） [ 23.309766] OOM 殺手已停用。[23.313027] 凍結剩餘可凍結任務 [ 23.318540] 凍結剩餘可凍結任務完成（經過秒 0.001 數） [ 23.342038] 序列 00:05： 停用 [ 23.345719] 序列 00:02： 停用 [23.349342 ] 序列 00:01： 停用 [ 23.353782] sd 0：0：0： [sda] 同步 SCSI 快取 [ 23.358993] sd 1：0：0：0： [sdb] 同步 SCSI 快取 [ 23.361635] ata1.00： 進入待機電源模式 [ 23.368863] ata2.00： 進入待機電源模式 [ 23.445187] BUG： 核心 NULL 指標引用，位址：
    0000000000000000000 [ 23.452194] #PF：核心模式下的監督指令擷取 [ 23.457896] #PF：
    error_code（0x0010） - 不存在頁面 [ 23.463065] PGD 0 P4D 0 [ 23.465640] 哎呀：哎呀：0010 [#1] SMP NPP [ 23.469869] CPU： 8 UID： 0 PID： 211 通訊： kworker/u48：18 受污染： G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 搶佔（自願） [ 23.482512] 受污染： [S]=CPU_OUT_OF_SPEC， [W]=WARN [ 23.496511] 工作佇列：非同步 async_run_entry_fn [ 23.501087] RIP： 0010：0x0 [ 23.503755] 代碼：無法存取 0xffffffffffffffd6 的操作碼位元組。[ 23.510324] RSP： 0018：ffffb4a60065fca8 EFLAGS： 00010246 [23.515592] RAX： 00000000000000000000000 RBX： ffff9f428290e0000 RCX： 000000000000000f [ 23.522765] RDX：
    0000000000000000 RSI：0000000000000282 RDI：ffff9f428290e000 [ 23.529937] RBP：ffff9f4282907070 R08：
    ffff9f4281130428 R09： 0000000ffffffffff [ 23.537111] R10： 00000000000000000000 R11： 0000000000000001 R12：
    ffff9f42829070f8 [ 23.544284] R13： ffff9f4282906028 R14： ffff9f428290000 R15： ffff9f4282906b68 [23.551457] FS： 0000000000000000000（0000） GS：ffff9f466b2cf000（0000） knlGS：00000000000000000000000000000000 23.559588
    0010 DS： 0000 ES： 0000 CR0： 0000000080050033 [ 23.565365] CR2： ffffd6 CR3： 000000031c230001 CR4：
    0000000000f70ef0 [ 23.572539] PKRU： 55555554 [ 23.575281] 通話追蹤：[ 23.577770] <TASK> [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ？
    __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ？ __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [23.643464] __pfx_kthread+0x10/0x10 [ 23.647263] ？ __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] </TASK> [ 23.664826] 模組連結於：[ 23.667914] CR2： 00000000000000000000 23.671271
    ------------[此處切斷]------------（摘自 commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad） （CVE-2026-31540）

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

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

  - rxrpc：修正來自 call->key 的金鑰參照計數洩漏 在 rxrpc_alloc_client_call（） 中建立用戶端呼叫時，程式碼會取得金鑰的參照。這永遠不會清除，並在呼叫被破壞時洩露。透過釋放 rxrpc_destroy_call（） 中的 call->key 來解決此問題。在修補程式之前，它顯示金鑰參照計數器已提升：$ cat /proc/keys |grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321： ka $ 修補程式之後，當程式碼結束時，會移除無效的金鑰： $ cat /proc/keys |grep afs@54321 $ （CVE-2026-31639）

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

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

  - usb： gadget： f_phonet：修正 pn_rx_complete（） 中的 skb frags[] 溢位 損毀/無聊/平均 USB 主機可透過傳送無限的整頁 OUT 傳輸序列，使 Linux 小工具上的 skb_shared_info->frags[] 陣列溢位，從而暴露 Phonet 函式。pn_rx_complete（） 僅在 req->actual < req->length 時才會完成 skb，其中 req->length 被小工具設定為PAGE_SIZE。如果主機每次傳輸總是發送恰好 PAGE_SIZE 個位元組，則 fp->rx.skb 將永遠不會重置，並且每次完成都會通過 skb_add_rx_frag（） 添加另一個片段。一旦nr_frags超過 MAX_SKB_FRAGS （預設值 17），後續片段會儲存與堆積上 shinfo 相鄰的覆寫記憶體。當達到片段限制時，刪除 skb 並考慮長度錯誤，以符合透過提交 f0813bcd2d9d 在 t7xx 中套用的修正 （net： wwan： t7xx：修正 RX 路徑中潛在的 skb->frags 溢位）。（CVE-2026-31616）

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

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

  - staging sm750fb修正 ps_to_hz() 中的除以零錯誤。在未驗證 pixclock 是否為非零的情況下從 hw_sm750_crtc_set_mode() 呼叫 ps_to_hz()。透過 FBIOPUT_VSCREENINFO 傳遞的零 pixclock 會造成除以零錯誤。透過拒絕 lynxfb_ops_check_var() 中的零 pixclock 來修正此問題與其他 framebuffer 驅動程式一致。 (CVE-2026-31603)

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

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

  - 已解決 Linux 核心中的下列弱點：vfio/xe: Reorganize the init to decouple migration from reset Attempting to issue reset on VF devices that don't support migration leads to the following: BUG: unable to handle page fault for address: 00000000000011f8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy) Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name:
    Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe] Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 <83> bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89 RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202 RAX:
    ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff888101a48800 R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0 FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0 PKRU: 55555554 Call Trace: <TASK> xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci] pci_dev_restore+0x3b/0x80 pci_reset_function+0x109/0x140 reset_store+0x5c/0xb0 dev_attr_store+0x17/0x40 sysfs_kf_write+0x72/0x90 kernfs_fop_write_iter+0x161/0x1f0 vfs_write+0x261/0x440 ksys_write+0x69/0xf0
    __x64_sys_write+0x19/0x30 x64_sys_call+0x259/0x26e0 do_syscall_64+0xcb/0x1500 ? __fput+0x1a2/0x2d0 ? fput_close_sync+0x3d/0xa0 ? __x64_sys_close+0x3e/0x90 ? x64_sys_call+0x1b7c/0x26e0 ? do_syscall_64+0x109/0x1500 ? __task_pid_nr_ns+0x68/0x100 ? __do_sys_getpid+0x1d/0x30 ? x64_sys_call+0x10b5/0x26e0 ? do_syscall_64+0x109/0x1500 ? putname+0x41/0x90 ? do_faccessat+0x1e8/0x300 ?
    __x64_sys_access+0x1c/0x30 ? x64_sys_call+0x1822/0x26e0 ? do_syscall_64+0x109/0x1500 ? tick_program_event+0x43/0xa0 ? hrtimer_interrupt+0x126/0x260 ? irqentry_exit+0xb2/0x710 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7877d5f1c5a4 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d a5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4 RDX:
    0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009 RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007 R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9 R13:
    0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0 </TASK> This is caused by the fact that some of the xe_vfio_pci_core_device members needed for handling reset are only initialized as part of migration init. Fix the problem by reorganizing the code to decouple VF init from migration init. (CVE-2026-31601)

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

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

  - mm：直接在 folio_unmap_invalidate（） 中調用 ->free_folio（） 只有在我們引用（或鎖定）映射時，我們才能調用 filemap_free_folio（）。否則，我們已從對應中移除對開本，使其不再釘選對應，而且可以移除對應，從而在存取 mapping->a_ops 時造成釋放後使用。遵循與 __remove_mapping（） 相同的模式，並在刪除對應上的鎖定之前載入 free_folio 函數指標。這讓我們可以使 filemap_free_folio（） 靜態，因為這是 filemap.c 之外的唯一調用方。（CVE-2026-31589）

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

ID	名稱	嚴重性
310329	Linux Distros 未修補的弱點：CVE-2026-42171	high
310328	Linux Distros 未修補弱點：CVE-2026-31607	high
310327	Linux Distros 未修補弱點：CVE-2026-31622	high
310326	Linux Distros 未修補的弱點：CVE-2026-31644	high
310325	Linux Distros 未修補的弱點：CVE-2026-31562	medium
310324	Linux Distros 未修補弱點：CVE-2026-31597	high
310323	Linux Distros 未修補的弱點：CVE-2026-31537	medium
310322	Linux Distros 未修補弱點：CVE-2026-31552	high
310321	Linux Distros 未修補的弱點：CVE-2026-31566	high
310320	Linux Distros 未修補的弱點：CVE-2026-31545	medium
310319	Linux Distros 未修補的弱點：CVE-2026-31549	medium
310318	Linux Distros 未修補的弱點：CVE-2026-31559	medium
310317	Linux Distros 未修補的弱點：CVE-2026-31585	medium
310316	Linux Distros 未修補弱點：CVE-2026-31656	high
310315	Linux Distros 未修補弱點：CVE-2026-31582	high
310314	Linux Distros 未修補弱點：CVE-2026-31578	high
310313	Linux Distros 未修補弱點：CVE-2026-31598	high
310312	Linux Distros 未修補弱點：CVE-2026-31574	medium
310311	Linux Distros 未修補的弱點：CVE-2026-31613	high
310310	Linux Distros 未修補的弱點：CVE-2026-31595	medium
310309	Linux Distros 未修補弱點：CVE-2026-31657	critical
310308	Linux Distros 未修補弱點：CVE-2026-31584	high
310307	Linux Distros 未修補弱點：CVE-2026-31621	medium
310306	Linux Distros 未修補弱點：CVE-2026-31596	medium
310305	Linux Distros 未修補弱點：CVE-2026-31606	medium
310304	Linux Distros 未修補弱點：CVE-2026-31629	high
310303	Linux Distros 未修補的弱點：CVE-2026-31659	critical
310302	Linux Distros 未修補的弱點：CVE-2026-31610	medium
310301	Linux Distros 未修補的弱點：CVE-2026-31651	medium
310300	Linux Distros 未修補弱點：CVE-2026-31615	medium
310299	Linux Distros 未修補弱點：CVE-2026-31536	critical
310298	Linux Distros 未修補弱點：CVE-2026-31587	high
310297	Linux Distros 未修補弱點：CVE-2026-31577	medium
310296	Linux Distros 未修補弱點：CVE-2026-31611	high
310295	Linux Distros 未修補弱點：CVE-2026-31612	high
310294	Linux Distros 未修補弱點：CVE-2026-31626	high
310293	Linux Distros 未修補的弱點：CVE-2026-41476	high
310292	Linux Distros 未修補的弱點：CVE-2026-40254	medium
310291	Linux Distros 未修補的弱點：CVE-2026-31646	medium
310290	Linux Distros 未修補弱點：CVE-2026-31608	critical
310289	Linux Distros 未修補的弱點：CVE-2026-31645	medium
310288	Linux Distros 未修補的弱點：CVE-2026-31660	medium
310287	Linux Distros 未修補弱點：CVE-2026-31602	high
310286	Linux Distros 未修補的弱點：CVE-2026-41425	medium
310285	Linux Distros 未修補的弱點：CVE-2026-31540	medium
310284	Linux Distros 未修補的弱點：CVE-2026-31639	medium
310283	Linux Distros 未修補弱點：CVE-2026-31616	medium
310282	Linux Distros 未修補的弱點：CVE-2026-31603	medium
310281	Linux Distros 未修補弱點：CVE-2026-31601	medium
310280	Linux Distros 未修補弱點：CVE-2026-31589	critical

偵測

Nessus 的 Misc. 系列

high

high

high

high

medium

high

medium

high

high

medium

medium

medium

medium

high

high

high

high

medium

high

medium

critical

high

medium

medium

medium

high

critical

medium

medium

medium

critical

high

medium

high

high

high

high

medium

medium

critical

medium

medium

high

medium

medium

medium

medium

medium

medium

critical