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

  - 輸入：synaptics-rmi4 - 將鍵盤映射綁定 F30 到 GPIO/LED 計數 rmi_f30_map_gpios（） 分配最多 6 個條目的 min（gpioled_count， TRACKSTICK_RANGE_END） == gpioled_key_map，但 rmi_f30_attention（） 迭代完整的 f30->gpioled_count （設備查詢暫存器，範圍 0..31） 並取消參照 gpioled_key_map[i]，並且 input->keycodemax 設定為完整gpioled_count，而 input->keycode 指向 6 個條目分配。因此，在啟用 GPIO 支援的情況下報告 gpioled_count > 6 的裝置會導致注意力中斷的越界讀取，並透過 EVIOCGKEYCODE/EVIOCSKEYCODE ioctls 進行越界讀取/寫入，這只會針對 keycodemax 繫結索引。這與 F3A 處理常式的缺陷相同，它是從 複製而 F30來的。調整完整gpioled_count的鍵盤映射大小;映射迴圈仍然只分配第一個 min（gpioled_count， TRACKSTICK_RANGE_END） 項目。
    (CVE-2026-64276)

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

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

  - usb：typec： tcpm：驗證 svdm_consume_modes（） 中的 SVID 索引 在 svdm_consume_modes（） 中，使用 pmdata->svid_index 作為陣列索引，無需邊界驗證，從 pmdata->svids 讀取 SVID 值：
    paltmode->svid = pmdata->svids[pmdata->svid_index];如果 pmdata->svid_index 驅動超出 SVID_DISCOVERY_MAX （16） ，則會導致 pmdata->svids 陣列的越界讀取。由於pd_mode_data內嵌在結構tcpm_port內，因此將過去的 svid 編入索引會讀取到相鄰的欄位中。特別是： - 在索引 16 處，它會讀取 altmodes 計數。- 在索引 18 及更高時，它會 altmode_desc[]讀取 ，其中包含合作夥伴提供的 SVDM 探索模式 VDO。透過將選定的 SVID 注入 altmode_desc[0].vdo 並將 svid_index 驅動到 20，合作夥伴可以強制 paltmode->svid 載入任意合作夥伴選擇的 SVID，然後透過 typec_partner_register_altmode（） 註冊該 SVID。在存取 svdm_consume_modes（） 內的 pmdata->>svids 陣列之前，驗證 pmdata->svid_index 是否為非負數且嚴格小於 pmdata-nsvids，以修正此問題。（CVE-2026-64330）

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

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

  - crypto： caam - 使用 print_hex_dump_devel 來保護金鑰十六進位轉儲 使用 print_hex_dump_devel（） 傾印 *_setkey（） 中的機密金鑰資料，以避免在啟用 CONFIG_DYNAMIC_DEBUG 時在執行階段洩漏密碼。（CVE-2026-64315）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: arm64: Don't leak PFN when kvm_translate_vncr() races MMU notifier In the case that kvm_translate_vncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvm_release_faultin_page() for the unused PFN. (CVE-2026-64282)

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

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

  - iommufd：設定快取無效entry_num上限，entry_len iommufd_hwpt_invalidate（） 採用使用者控制的entry_num和entry_len，每個和僅以U32_MAX為界。超出核心結構大小的entry_len會使複製協助程式驗證額外的位元組為零，並在一次不間斷的傳遞中掃描該超出部分;超過零使用者記憶體的數 GB 值會觸發軟鎖定看門程式。另一半是大entry_num，驅動後端無效迴圈，無需重新排程。例如，VT-d 巢狀處理常式會複製每個項目，並在每次迭代時排清快取，將 CPU 固定在不可搶佔的核心上。在 ioctl 中限制兩者。entry_len保存在 PAGE_SIZE、任何要求結構之上，並entry_num 1 << 19 （硬體無效佇列的順序） 下，並且遠遠超出任何實際批次，從而限制了每個呼叫的迴圈長度。（CVE-2026-64289）

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

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

  - fs/ntfs3：驗證 log_replay copy_lcns 中的「已變更頁面表格」容量 在日誌重新執行的 $LogFile 分析階段中，log_replay（） 會將 LCN 從每一個動作記錄記錄複製到現有的「已變更頁面表格 （DPT）」項目中，而不限制目的地索引。具有 DPT 項目 lcns_follow=1 和動作記錄記錄的特製 NTFS 映像檔 （lcns_follow=2） 會在裝載時產生核心 slab 越界寫入： 錯誤：
    KASAN：log_replay+0x654c/0xdb60 中的 slab-out-of-bounds 透過任務掛載在 addr ffff8880095e1040 處寫入大小 8 兩個攻擊者控制的欄位可以驅動 j+i 通過分配 page_lcns[] 的陣列： 1.
    DP->lcns_follow（容量）可以小於 LRH->lcns_follow。2. LRH->target_vcn可能比DP->VCN小，使得U64減法包裝成一個巨大的size_t。根據 DPT 進入容量驗證目標 VCN 差異和每記錄 LCN 計數，透過現有的 out： 使用 -EINVAL 清除標籤進行保釋。這反映了在提交 b2bc7c44ed17 （fs/ntfs3：修正 DeleteIndexEntryRoot 中的 slab-out-of-bounds 讀取） 和提交 0ca0485e4b2e （fs/ntfs3：驗證 rec->用於日誌重播檔案記錄檢查） 中新增的邊界檢查模式。（CVE-2026-64432）

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

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

  - 韌體：arm_ffa：繫結PARTITION_INFO_GET_REGS複本 將分割區描述元複製到呼叫端緩衝區時，暫存器型PARTITION_INFO_GET路徑信任韌體提供的索引。拒絕不一致的計數或索引進度，讓複製迴圈無法寫入已配置的陣列。（修正cur_idx第一個片段中只有一個描述元的情況）（CVE-2026-64520）

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

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

  - USB： iowarrior：修正中斷連線時的釋放後使用 提交的寫入 URB 不會在 close（） 上停止，因此需要在 disconnect（） 上無條件停止，以避免完成處理常式中的釋放後使用。（CVE-2026-64342）

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

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

  - ksmbd：使用開啟器憑證執行集合資訊 SMB2 SET_INFO處理常式在檢查授與 SMB 控制碼的存取遮罩之後，呼叫路徑型 VFS 協助程式。這些協助程式會使用目前的 ksmbd 背景工作角色憑證來執行其所有者、inode 權限和 LSM 檢查。使用開啟控點時擷取的認證，執行完整的SET_INFO分派。這也會移除個別的安全性資訊認證設定，並將所有SET_INFO類別保留在一個認證範圍內。使用直接 override_creds（） 是因為它可以與重新命名和連結協助程式已使用的要求認證覆寫嵌套。
    (CVE-2026-64393)

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

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

  - net： ipv4：繫結的 TCP 重新排序 sysctl 寫入和 MTU 探查大小 在無效的「net.ipv4.tcp_reordering」值達到 TCP 通訊端狀態之前，將其拒絕。sysctl 儲存為 'int'，但會複製到新通訊端的 'u32' 'tp->reordering' 欄位中，因此負寫入會包裝為較大的值。使用「tcp_mtu_probing=2」時，包裝的值可能會溢位「tcp_mtu_probe（）」大小計算，並將 MTU 探查路徑驅動到越界讀取。路由 'tcp_reordering' 寫入 'proc_dointvec_minmax（）' 並要求它至少為 1。也要求 'tcp_max_reordering' 至少為 1，這樣配置的最大值也不能變成負數。為非 init 網路命名空間註冊資料表時，請重新定位參照 'init_net.ipv4' 的 'extra2' 指標，讓 'tcp_reordering' 上限遵循該命名空間的 'tcp_max_reordering'。透過將「size_needed」計算為「u64」來強化「tcp_mtu_probe（）」本身。這可防止傳送佇列和視窗檢查透過帶正負號的整數溢位繞過。（CVE-2026-64422）

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

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

  - USB：序列：digi_acceleport：修正中斷連線時的硬式鎖定：如果提交 OOB 寫入 urb 持續失敗 （例如，如果裝置中斷連線），驅動程式會在停用中斷的情況下無限迴圈。傳送 OOB 命令時檢查 urb 提交錯誤，以避免在 open（） 、set_termios（） 或 close（） 與實體中斷連線爭用時停擺。這是 Sashiko 在審查驅動程式的不相關變更時標記的問題。（CVE-2026-64334）

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

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

  - USB： gadget： f_printer：僅針對成功開啟的 kref 進行 printer_open（） 會在字元裝置已開啟時傳回 -EBUSY，但無論傳回值為何，它都會遞增 dev->kref。VFS 不會針對失敗的開啟呼叫 ->release（），因此每拒絕第二次開啟就會永久洩漏一個參照。將 kref_get（） 移至成功開啟的分支。（CVE-2026-64345）

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

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

  - IIO：陀螺儀：BMG160：當頻寬/濾波器不在表中時，救援 bmg160_get_filter（） 遍歷 bmg160_samp_freq_table[] 尋找與從晶片讀取的bw_bits值相符的條目：對於 （i = 0;
    i < ARRAY_SIZE（bmg160_samp_freq_table）;++i） { if （bmg160_samp_freq_table[i].bw_bits == bw_bits） break; }
    *val = bmg160_samp_freq_table[i].filter;如果沒有條目匹配，則 i 最終等於數組大小，下一行讀取末尾後的一個插槽。bmg160_set_filter（） 具有相同的形狀，由 'val' 驅動，而不是 bw_bits。smatch 標記兩者：drivers/iio/gyro/bmg160_core.c：204 bmg160_get_filter（） 錯誤：緩衝區溢位 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c：222 bmg160_set_filter（） 錯誤：緩衝區溢位 'bmg160_samp_freq_table' 7 <= 7 當沒有項目相符時，傳回 -EINVAL。set_filter（） 路徑可透過 sysfs in_anglvel_filter_low_pass_3db_frequency介面從使用者空間存取，因此使用者空間可以使用不在 .filter 中的 bmg160_samp_freq_table[]值輕鬆觸發越界讀取。
    (CVE-2026-64495)

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options: * do something like symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded (CVE-2026-64307)

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

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

  - ksmbd：透過限制無大小寫重試來防止路徑遊走繞過 ksmbd_vfs_path_lookup（） 強制LOOKUP_BENEATH以限制共用根目錄內的路徑解析。當特製路徑嘗試使用父目錄元件 （'..'） 逸出共用邊界時，vfs_path_parent_lookup（） 會偵測到此情況並立即失敗，並傳回 -EXDEV。但是，在無大小寫模式下，__ksmbd_vfs_kern_path（） 中存在一個錯誤。
    函式無法攔截 -EXDEV 錯誤，並錯誤地落入無大小寫重試邏輯，這僅適用於真正遺漏的檔案。在此重試程式期間，會重建路徑，導致意外的LOOKUP_BENEATH繞過，讓可寫入的使用者在匯出的共用之外建立零長度檔案或目錄。請確定只有在錯誤為 -ENOENT 時，執行才會繼續進行無大小寫查閱重試，以修正此問題。任何其他錯誤，例如
    路徑遊走嘗試的 -EXDEV，必須立即傳回。（CVE-2026-64400）

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

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

  - xfs：不要在 dqiterate 中包裝配額 ID LOLLM 注意到 q_id 是一個未帶正負號的 32 位元變數。如果由於檔案系統實際上具有 ID_MAX 的 dquot，因此碰巧將其設定為 XFS_DQ_ID_MAX，則此新增將截斷為零，並且反覆運算重新開始。透過轉換為 u64 來解決此問題。（CVE-2026-64256）

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

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

  - USB： xhci：修正 xhci_free_streams（） 中不可部分完成內容中的睡眠 當具有作用中資料流端點的 USB 裝置中斷連線時，系統會從 hub_event 工作佇列呼叫 xhci_free_streams（） 以釋放資料流程資源。它在停用 irqs 的情況下按住 xhci->lock 時呼叫 xhci_free_stream_info（）。
    xhci_free_stream_info（） 叫用 xhci_free_stream_ctx（），它呼叫大型串流上下文陣列的 dma_free_coherent（）。dma_free_coherent（） 可以休眠（例如透過 vunmap），在從原子上下文呼叫時觸發 BUG。呼叫追蹤：dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c 透過儲存stream_info指標和清除鎖下的 ep 參照，然後在允許休眠的鎖外呼叫 xhci_free_stream_info（）。
    (CVE-2026-64465)

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

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

  - 藍牙：L2CAP：透過按住 conn ref l2cap_chan_timeout（） 非同步運行並存取 chan->conn，修正通道逾時中的 UAF。如果在計時器執行或擱置時中斷連線，則 chan->conn 可能會被釋放，當計時器工作程式嘗試鎖定 conn->lock： |錯誤：KASAN：
    instrument_atomic_read_write include/linux/instrumented.h：112 中的 slab-use-after-free [內聯] |錯誤：
    KASAN：slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h：4456 [內聯] |錯誤：KASAN：__mutex_trylock_fast kernel/locking/mutex.c：161 中的 slab-use-after-free [inline] |錯誤：KASAN：mutex_lock+0x4f/0xa0 kernel/locking/mutex.c：318 中的 slab-use-after-free |透過任務 kworker/2:1/83 在 addr ffff8881298d9550 寫入大小 8 | |CPU：2 UID：0 PID：83 Comm：kworker/2:1 未受污染 7.1.0-rc6-next-20260601-dirty #6 PREEMPT（full） |硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 |工作佇列：事件l2cap_chan_timeout |通話追蹤： | <TASK> | instrument_atomic_read_write include/linux/instrumented.h：112 [內嵌] | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h：4456 [內嵌] |
    __mutex_trylock_fast kernel/locking/mutex.c：161 [內嵌] |mutex_lock+0x4f/0xa0 kernel/locking/mutex.c：318 |l2cap_chan_timeout+0x5d/0x1b0網路/藍牙/l2cap_core.c：422 |process_one_work kernel/workqueue.c：3326 [內嵌] |process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c：3409 |worker_thread+0x8a9/0xcf0 kernel/workqueue.c：3490 |kthread+0x346/0x430 kernel/kthread.c：436 |ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c：158 |ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 | </TASK> | |依作業 320 分配： |l2cap_conn_add+0xa7/0x820網路/藍牙/l2cap_core.c：7075 |l2cap_connect_cfm+0xdb/0xd70網路/藍牙/l2cap_core.c：7452 |hci_connect_cfm include/net/bluetooth/hci_core.h：2139 [內嵌] |hci_remote_features_evt+0x52f/0x9f0網路/藍牙/hci_event.c：3760 |hci_event_func net/bluetooth/hci_event.c：7796 [內嵌] |hci_event_packet+0x561/0xa70網路/藍牙/hci_event.c：7847 |hci_rx_work+0x370/0x890網路/藍牙/hci_core.c：4040 |process_one_work kernel/workqueue.c：3326 [內嵌] |process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c：3409 |worker_thread+0x8a9/0xcf0 kernel/workqueue.c：3490 |kthread+0x346/0x430 kernel/kthread.c：436 |ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c：158 |ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 | |由任務 322 釋放： |hci_disconn_cfm include/net/bluetooth/hci_core.h：2154 [內嵌] |hci_conn_hash_flush+0x101/0x1f0網路/藍牙/hci_conn.c：2736 |hci_dev_close_sync+0x889/0xde0網路/藍牙/hci_sync.c：5405 |hci_dev_do_close net/bluetooth/hci_core.c：502 [內嵌] |hci_unregister_dev+0x1f7/0x370網路/藍牙/hci_core.c：2679 |vhci_release+0x12a/0x180驅動程式/藍牙/hci_vhci.c：690 |__fput+0x369/0x890 fs/file_table.c：510 |task_work_run+0x160/0x1d0 kernel/task_work.c：233 |get_signal+0xf5b/0x1120 kernel/signal.c：2810 |arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c：337 |__exit_to_user_mode_loop kernel/entry/common.c：64 [內嵌] |exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c：98 |do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c：100 |entry_SYSCALL_64_after_hwframe+0x77/0x7f | |有錯誤的位址屬於 ffff8881298d9400 |屬於大小為 512 的快取 kmalloc-512 |有錯誤的位址位於 |釋放的 512 位元組區域 [ffff8881298d9400， ffff8881298d9600） 當通道新增至連線時，讓 chan->conn 保留對 l2cap_conn 的參照（透過 l2cap_conn_get），並在通道析構函式中釋放它，以修正此問題。這可確保只要通道存在，l2cap_conn就會保持活動狀態。引入了新的FLAG_DEL通道旗標，以指示 ch ---truncated--- （CVE-2026-64434）

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

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

  - USB： dwc3：執行 gadget disconnect from sleepable suspend context dwc3_gadget_suspend（） 在停用 IRQ 的情況下獲取 dwc->lock，然後呼叫 dwc3_disconnect_gadget（）。對於非同步回呼，該協助程式僅使用普通 spin_unlock（）/spin_lock（），因此小工具 ->disconnect（） 回呼仍然在停用 IRQ 的情況下運行，並且任何可休眠的回呼都會跳閘 Lockdep。此問題由我們的靜態分析工具發現，然後針對目前的樹狀結構手動檢閱。接地的 PoC 保留了 dwc3_gadget_suspend（） -> dwc3_disconnect_gadget（） -> gadget_driver->disconnect（） 鏈，Lockdep 報告： 錯誤：從無效上下文調用休眠函式 gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] 將中斷連接回呼選擇保留在一個通用協助程式中，但新增一個可休眠的暫停端包裝函式，該包裝函式會在 dwc->lock 下拍攝回呼的快照，然後在 spin_unlock_irqrestore（） 之後執行它。一般事件路徑仍會使用現有的 spin_unlock（）/spin_lock（） 視窗。（CVE-2026-64454）

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: chacha20poly1305 - validate poly1305 template argument chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp(). When the argument is missing, crypto_attr_alg_name() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp(). This matches the surrounding Crypto API template pattern where crypto_attr_alg_name() results are validated before string-specific use. (CVE-2026-64314)

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

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

  - crypto： qat - 修正 adf_disable_sriov（） 中的 VF2PF 工作拆卸爭用 VF2PF 中斷處理常式會將 PF 端回應工作排入佇列，該工作儲存每個 VF 狀態的原始指標 （struct adf_accel_vf_info）。目前，adf_disable_sriov（） 會破壞 per-VF 互斥並釋放 vf_info，而無需停止新的 VF2PF 工作或等待進行中的工作角色完成。然後，並行排程或已排入佇列的背景工作角色可以取消參照釋放的記憶體。當啟用 KASAN 時，這表現為釋放後使用： 錯誤：KASAN：mutex_lock+0x76/0000000000000260 0xe0 中的 null-ptr-deref 任務 kworker/24:2/... 工作佇列：
    qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] 呼叫追蹤：kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 新增 PF-local 旗標， vf2pf_disabled，這會在拆卸期間將工作佇列、背景工作處理和中斷重新啟用門禁。使用 adf_disable_all_vf2pf_interrupts（） 內的硬體中斷遮罩自動設定此旗標。遮罩之後，同步 AE 叢集 MSI-X 中斷並排清 PF 回應工作佇列，然後再拆除每個 VF 的鎖定和狀態，以便在vf_info被破壞之前完成所有進行中的工作。引入 adf_enable_all_vf2pf_interrupts（） 以清除旗標，並在重新啟用 SR-IOV 時取消遮罩相同鎖定下的所有 VF2PF 中斷。這可確保軟體旗標和硬體狀態在啟用和停用路徑上不可部分完成轉換。
    (CVE-2026-64438)

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

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

  - spi： fsl-lpspi：終止 TX 準備故障路徑上的 RX 通道 當 TX 通道的 dmaengine_prep_slave_sg（） 失敗時，錯誤路徑會終止 TX DMA 通道，但使 RX 通道保持執行狀態。由於在準備 TX 描述元之前已提交並發出 RX 通道，因此傳回 -EINVAL 會導致 SPI 核心取消對應 DMA 緩衝區，而 RX DMA 引擎會繼續寫入它們，進而導致潛在的記憶體損毀或釋放後使用。在返回 TX 準備失敗路徑之前，先終止 RX 通道。（CVE-2026-64303）

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

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

  - ALSA： seq：修正 snd_seq_event_dup（） 中未初始化的堆積洩漏 snd_seq_event_dup（） 將傳入事件複製到集區儲存格中，並在啟用 UMP 的組建中清除 memcpy（） 未涵蓋的尾端 cell->ump.raw.extra 字。決定是否清除它的守衛會將複製的大小與 sizeof（cell->event） 進行比較：memcpy（&cell->ump， event， size）;if （size < sizeof（cell->event）） cell->ump.raw.extra = 0;對於舊版 （非 UMP） 事件，size == sizeof（struct snd_seq_event） == sizeof（cell->event），因此條件為 false，且額外的字會保留過時的資料。儲存格集區使用 kvmalloc（） （未歸零） 分配，並且儲存格透過可用清單重複使用，因此該字包含未初始化的堆積或剩餘的事件資料。當這樣的儲存格被傳送到設定SNDRV_SEQ_FILTER_NO_CONVERT的 UMP 用戶端 （client->midi_version > 0） 時 （因此舊版事件未轉換就到達它） snd_seq_read（） 將其讀出為較大的結構snd_seq_ump_event，並將過時的字複製到使用者空間，即 4 位元組核心堆資訊洩露到無權限的 /dev/snd/seq 用戶端。請改為與 sizeof（cell->ump） 進行比較，因此對於每個短於 UMP 儲存格的事件，尾端單字都會歸零。（CVE-2026-64479）

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

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

  - 輸入：goodix - 箝制設備報告的接觸點計數 goodix_ts_read_input_report（） 將設備報告的接觸點數量複製到堆疊緩衝區 u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];其大小最多可容納 GOODIX_MAX_CONTACTS （10） 個觸點。唯一的執行階段檢查會針對 ts->max_touch_num 限制每個中斷計數，但該值是從裝置組態區塊的 4 位元欄位逐字擷取，而且永遠不會被限制：ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] &; 0x0f;半字節可以是 0..15，因此故障、惡意或偽造的控制器 （或篡改 I2C 匯流排的攻擊者） 最多可以通告 15 個觸點。
    然後，goodix_ts_read_input_report（） 接受最多 15 的touch_num，第二個 goodix_i2c_read（） 將 ts->contact_size * （touch_num - 1） 位元組寫入 92 位元組緩衝區之外的 point_data - 最多 30 位元組（9 位元組報告格式為 45 個）：堆疊越界寫入。從組態中讀取觸點數量時，將max_touch_num夾GOODIX_MAX_CONTACTS，即觸點 point_data[] 數量的大小。（CVE-2026-64274）

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

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

  - 輸入：mms114 - 修正 MMS134S 和 MMS134S MMS136 和 MMS136 觸控控制器的事件大小為 6 位元組，而不是 8 位元組。當 __mms114_read_reg（） 將觸控資料封包從裝置讀取到觸控緩衝區時，事件會以 6 位元組的間隔緊密封裝。不過，驅動程式會使用標準 C 陣列索引 （touch[index]） 逐一查看事件，其中每個元素的 sizeof（struct mms114_touch） （8 位元組） 相距。因此，超出第一個事件的任何觸摸事件都會從不正確的偏移中讀取並不正確地剖析。根據裝置的特定事件大小，明確計算每個觸控事件的位元組位移，以修正此問題。（CVE-2026-64272）

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

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

  - mfd： cros_ec：延遲 dev_set_drvdata（） 直到探查成功 如果 ec_device_probe（） 失敗，cros_ec_class_release 會釋放 cros_ec_dev 結構的記憶體。不過，因為 drvdata 已設定，所以像 cros_ec_typec 這樣的子驅動程式仍然可以透過平台裝置擷取過時的指標。
    當cros_ec_typec嘗試在已發行的裝置上存取 &typec->ec->ec->dev 時，這會導致釋放後使用。移動 dev_set_drvdata（） 以確保只有在所有初始化步驟成功後，指標才可用。sysfs：無法建立重複的檔案名稱「/class/chromeos/cros_ec」 呼叫追蹤：sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... 錯誤：KASAN：在 __memcpy+0x44/0x230 中存取無效 由任務 kworker/u32：5/125 寫入 addr f5ffff809e2d33ac 指標標籤：[f5]，記憶體標籤：[fe] 污染：[W]=WARN，[O]=OOT_MODULE 硬體名稱：Google Navi 未佈建 0x7FFFFFFF/sku0 board/sku3 工作佇列：
    events_unbound deferred_probe_work_func 呼叫追蹤：__memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0 （CVE-2026-64420）

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

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

  - bpf：拒絕 devmap 中的片段框架 Devmap 廣播重新導向會複製除最後一個目的地以外的所有目的地的封包。對於原生 XDP，該複製路徑僅複製線性xdp_frame資料，而片段化幀將skb_shared_info保留在線性區域之外的尾部。複製這類框架會留下XDP_FLAGS_HAS_FRAGS集，但沒有有效的片段中繼資料，而後續的自由路徑可能會將未初始化的尾部資料解譯為skb_shared_info，導致在框架返回期間越界存取。拒絕 dev_map_enqueue_clone（） 中片段化的原生 XDP 框架。將相同的限制新增至 dev_map_redirect_clone（） 中的通用 XDP 複製路徑。通用 XDP 將片段化封包表示為非線性 skb，在這裡拒絕它們可使原生和通用 XDP 之間的複製型廣播支援保持一致。
    (CVE-2026-64355)

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

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

  - 已解決 Linux 核心中的下列弱點：xhci: sideband: fix ring sg table pages leak xhci_ring_to_sgtable() allocates a temporary pages array and uses it to build the returned sg_table with sg_alloc_table_from_pages(). The error paths free the pages array, but the success path returns the sg_table without freeing it. This leaks the temporary array every time a sideband client gets an endpoint or event ring buffer. Free the pages array after sg_alloc_table_from_pages() succeeds. The returned sg_table has its own scatterlist entries and does not depend on the temporary array after construction. (CVE-2026-64464)

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

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

  - USB： idmouse：修正中斷連接爭用時的釋放後使用 mutex_unlock（） 可能會在釋放鎖定後存取互斥結構，因此無法直接用於管理物件的存留期 （與微調鎖定和參照計數不同）。[1][2] 使用 kref 釋放驅動程式資料，以避免當 release（） 與 disconnect（） 爭用時，mutex_unlock（） 中的釋放後使用。[1] a51749ab34d9 （locking/mutex：證明 mutex_unlock（） 是非原子的）[2] 2b9d9e0a9ba0 （locking/mutex：澄清 mutex_unlock（） 和大多數其他休眠鎖在解鎖後仍然可以使用鎖定物件） （CVE-2026-64344）

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

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

  - crypto： qat - 使用 service_lock 保護服務表格反覆專案 當新增或移除項目時 （在 adf_service_add（） 及 adf_service_remove（） 中），service_table清單會受到 service_lock 的保護，但有數個函式會反覆運算清單而不保留此鎖定。並行的 adf_service_register（） 或 adf_service_unregister（） 呼叫可能會在遊走期間修改清單，導致清單損毀或釋放後使用。透過在 adf_dev_init（）、adf_dev_start（）、adf_dev_stop（）、adf_dev_shutdown（）、adf_dev_restarting_notify（）、adf_dev_restarted_notify（） 和 adf_error_notifier（） 中所有 list_for_each_entry（） service_table 迭代中保持service_lock來解決此問題。鎖定順序是安全的：靜態協助程式 （adf_dev_up（） 和 adf_dev_down（）） 的呼叫者在service_lock之前取得state_lock，並且沒有event_hld回呼或service_lock持有者以相反的順序取得state_lock。（CVE-2026-64305）

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

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

  - net： usb： kalmia：kalmia_rx_fixup（） 中綁定的 RX 幀長度 kalmia_rx_fixup（） 計算 usb_packet_length = skb->len - （2 * KALMIA_HEADER_LENGTH） 為 u16，僅由 skb->len 至少為 KALMIA_HEADER_LENGTH 的前迴圈檢查保護，即 6。設備可以提供 skb->len 在 6 到 11 範圍內的短批量 IN 幀，或者在以後的循環迭代中留下一個短的尾隨餘數。任一情況下溢，usb_packet_length約 65530。這會繞過usb_packet_length < ether_packet_length截斷路徑。裝置提供的ether_packet_length，即從 header_start[2] 讀取的 le16 至 65535，然後驅動 memcmp（） 以及隨後的 skb_trim（） 和 skb_pull（） 經過 rx 緩衝區的末端。rx 緩衝區為 hard_mtu * 10，即 14000 位元組。這是越界的讀法。要求在每次迴圈反覆專案中，在減去開始和結束框架標頭之前都存在它們。（CVE-2026-64351）

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

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

  - media：nxp：imx8-isi：修正移除 KASAN 在
    imx8_isi 的 rmmod 期間的 __media_entity_remove_link（）：錯誤：KASAN：slab-use-after-free in
    __media_entity_remove_link+0x608/0x650 任務 rmmod/724 在 addr ffff0000d47cb02a 讀取大小 2 呼叫追蹤：__media_entity_remove_link+0x608/0x650 __media_entity_remove_links+0x78/0x144
    __media_device_unregister_entity+0x150/0x280 media_device_unregister_entity+0x48/0x68 v4l2_device_unregister_subdev+0x158/0x300 v4l2_async_unbind_subdev_one+0x22c/0x358 v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0 v4l2_async_nf_unregister+0x5c/0x14c mxc_isi_remove+0x124/0x2a0 [imx8_isi] 由任務 249 分配：__kmalloc_noprof+0x27c/0x690 mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi] 由任務 724 釋放： kfree+0x1e4/0x5b0 mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi] mxc_isi_remove+0x11c/0x2a0 [imx8_isi] 問題是 mxc_isi_remove（） 在 mxc_isi_v4l2_cleanup（） 之前呼叫 mxc_isi_crossbar_cleanup（）。交叉列清除會釋放媒體實體填充，但後續的 v4l2 清理仍會嘗試移除參照這些填充的媒體連結。在 mxc_isi_crossbar_cleanup（） 之前呼叫 mxc_isi_v4l2_cleanup（） 來修正此問題，以確保在填充仍然有效時，所有媒體實體都已正確取消註冊。（CVE-2026-64421）

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

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

  - 已解決 Linux 核心中的下列弱點：ALSA: virtio: Validate control metadata from the device virtio-snd control handling trusts the device-provided control type and value count returned by the device. That metadata is then used directly to index g_v2a_type_map[] in virtsnd_kctl_info(), and to size loops and memcpy() operations in virtsnd_kctl_get() and virtsnd_kctl_put() against fixed-size virtio_snd_ctl_value and snd_ctl_elem_value arrays. A buggy or malicious device can therefore trigger out-of-bounds access by advertising an invalid control type or an oversized value count. Validate control type and count once in virtsnd_kctl_parse_cfg(), before querying enumerated items or exposing the control to ALSA. (CVE-2026-64490)

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

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

  - ALSA： usb-audio：避免 DualSense 比對中的 kobject 路徑查詢 DualSense 插孔偵測輸入處理常式會針對輸入裝置和 USB 音訊裝置建置 kobject 路徑字串，然後比較路徑前置詞，以驗證相符的輸入裝置是否屬於相同的實體控制器。當弱實體連接導致控制器快速中斷連接並重新連接時，就會觀察到這種情況。在重複的熱插拔期間，snd_dualsense_ih_match（） 可以在控制器的 USB 裝置中斷連線時執行。kobject_get_path（） 遍歷祖先 kobject 並取消參照其名稱;如果 USB 裝置 kobject 名稱不再有效，則 strlen（） 中可能會出錯： RIP：0010：strlen+0x10/0x30 呼叫追蹤：
    kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] 可以在不建立 kobject 路徑字串的情況下完成相同的所有權檢查。輸入裝置位於 HID 裝置、USB 介面和 USB 裝置下方，因此遍歷輸入裝置父鏈並與混音器 USB 裝置進行比較可保留檢查，而不會在中斷連線期間取消參照 kobject 名稱。（CVE-2026-64478）

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

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

  - 已解決 Linux 核心中的下列弱點：fuse-uring: make a fuse_req on SQE commit only findable after memcpy Bad userspace might try to trick us and send commit SQEs request unique / commit-id of requests that are not even send to fuse-server (io_uring_cmd_done() not called) yet.
    fuse_uring_commit_fetch() ends the fuse request when the ring entry has a wrong state, but that could have caused a use-after-free with the memcpy operations in fuse_uring_send_in_task(). In order to avoid such races the call of fuse_uring_add_to_pq() is moved after the copy operations and just before completing the io-uring request - malicious userspace cannot find the request anymore until all prepration work in fuse-client/kernel is completed. This also moves fuse_uring_add_to_pq() a bit up in the code to avoid a forward declaration. Also not with a preparation commit, to make it easier to back port to older kernels.
    (CVE-2026-64259)

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

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

  - 已解決 Linux 核心中的下列弱點：fuse-uring: Avoid use-after-free in fuse_uring_async_stop_queues fuse_uring_async_stop_queues() might run when the last reference on ring->queue_refs was already dropped. In order to avoid an early destruction a reference on struct fuse_conn is now taken before starting fuse_uring_async_stop_queues() and that reference is only released when that delayed work queue terminates. (CVE-2026-64261)

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

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

  - iio： accel： bmc150：箝制裝置報告的 FIFO 幀計數 __bmc150_accel_fifo_flush（） 將裝置在其硬體 FIFO 中報告的樣本數複製到堆疊上緩衝區 u16 緩衝區 [BMC150_ACCEL_FIFO_LENGTH * 3];其大小最多可容納 BMC150_ACCEL_FIFO_LENGTH （32） 個樣品。
    幀計數是從FIFO_STATUS暫存器讀取的，並且僅遮罩到其 7 個有效位元：count = val &; 0x7F;所以它可以是 0..127。套用至它的唯一其他限制是選擇性呼叫端提供的範例預算：if （samples &; count > samples） count = samples;這不會限制全部排清路徑上的計數 （samples == 0），並在樣本較大時使其遠高於 32。然後將計數樣本轉移到 buffer[]： bmc150_accel_fifo_transfer（data， （u8 *）buffer， count）;
    bmc150_accel_fifo_transfer（） 透過 regmap 讀取計數 * 6 位元組，因此報告多達 127 個幀的故障、惡意或偽造的加速度計（或篡改 I2C/SPI 匯流排的攻擊者）會將多達 762 位元組寫入 192 位元組緩衝區：最多 570 位元組的堆疊越界寫入會破壞堆疊金絲雀， 儲存的暫存器和傳回地址。clamp count 為 BMC150_ACCEL_FIFO_LENGTH，則在傳輸之前，樣本 buffer[] 的大小取決於 bmc150_accel_set_watermark（） 中已完成的浮水印限制。格式正確的重新整理最多會報告BMC150_ACCEL_FIFO_LENGTH幀，因此合法裝置不受影響。（CVE-2026-64504）

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

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

  - 已解決 Linux 核心中的下列弱點：usb: gadget: f_fs: Fix DMA fence leak In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the underlying dma_fence later initialized by dma_fence_init(), which sets its kref counter to 1. Then, dma_resv_add_fence() gets a second reference, and a pointer to the ffs_dma_fence is passed as the usb_request's context field. The dma-resv mechanism will manage the second reference, but the first reference is never properly released;
    the ffs_dmabuf_cleanup() function decreases the reference count, but only to balance with the reference grab in ffs_dmabuf_signal_done(). The code will then slowly leak memory as more ffs_dma_fence objects are created without being ever freed. Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dma_fence_put() right after dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded after being signalled. (CVE-2026-64328)

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

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

  - USB： iowarrior：修正中斷連接爭用時的釋放後使用 mutex_unlock（） 可能會在釋放鎖定後存取互斥結構，因此不能用來直接管理物件的存留期 （與微調鎖定和參照計數不同）。[1][2] 使用 kref 釋放驅動程式資料，以避免當 release（） 與 disconnect（） 爭用時，mutex_unlock（） 中的釋放後使用。[1] a51749ab34d9 （locking/mutex：證明 mutex_unlock（） 是非原子的）[2] 2b9d9e0a9ba0 （locking/mutex：澄清 mutex_unlock（） 和大多數其他休眠鎖在解鎖後仍然可以使用鎖定物件） （CVE-2026-64341）

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

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

  - io_uring/io-wq：重新檢查每個連結工作專案認可 10dc95939817 的IO_WQ_BIT_EXIT （io_uring/io-wq：
    檢查IO_WQ_BIT_EXIT內部工作執行迴圈）修正了 io_worker_handle_work（） 在清空擱置工作之前拍攝一個退出位元快照的明顯情況，但修正會提前停止一級。
    io_worker_handle_work（） 現在會重新檢查其外部工作執行迴圈中的IO_WQ_BIT_EXIT，但在處理整個相依連結工作鏈之前，它仍會對該位進行一次快照。如果 io_wq_exit_start（） 在第一個連結項目啟動後設定IO_WQ_BIT_EXIT，則剩餘的連結項目仍然可以重複使用過時的 do_kill = false，跳過IO_WQ_WORK_CANCEL，並在結束開始後繼續執行。將檢查移至更內側，使其也涵蓋連結的項目。注意：這是一個 syzbot 的特別功能，因為它喜歡在像 msr 這樣的奇怪設備上設置大量緩慢的鏈接工作，這些設備需要很長時間才能讀取，並立即關閉環。然後退出需要很長時間。（CVE-2026-64425）

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

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

  - USB： gadget： udc：修正 gadget_match_driver 中的釋放後使用 udc 結構作為小工具的管理結構，但其生命週期是分離的。存在爭用情形，其中 usb_del_gadget（） 釋放 udc 記憶體 （例如，透過模式切換工作），而 gadget_match_driver（） 同時存取釋放的 udc 記憶體 （例如，透過 configfs），導致釋放後使用 （UAF），當釋放的記憶體歸零時，觸發 NULL 指標解除參照： [39430.908615][ T1171] 無法處理虛擬位址 000000000000000000 的核心 NULL 指標解除參照 [39430.911397][ T1171] pc ：
    __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr ： gadget_match_driver+0x34/0x60 ...[39430.911890][T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][T1171] 工作佇列：events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 透過確保 udc 結構在釋放小工具之前保持配置狀態來解決此問題。若要達成此目的，請在核心中引入新的 usb_gadget_release（） 常式。
    新增小工具時，usb_add_gadget（） 會將小工具的發布常式儲存在 udc 結構中，並引用 udc。當小工具被釋放時，usb_gadget_release（） 會刪除對 udc 的引用，然後呼叫小工具的釋放常式。（CVE-2026-64346）

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

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

  - mm/damon/ops-common：處理 damon_hot_score（） 中的極端間隔 修正 damon_hot_score（） 中的三個問題，這些問題是由於錯誤處理極端 （零或過高） 監控間隔使用者設定造成的。當使用者設定取樣間隔零時，從 damon_hot_score（） 呼叫的 damon_max_nr_accesses（） 會導致除以零。不用說，這是一個問題。當使用者將彙總間隔設定為零時，函式會傳回零。這是錯誤的，因為設置中真正的最大nr_acceses應該是 1。更糟糕的是，它可能會導致調用方 damon_hot_score（） 的另一個除以零，因為它使用 damon_max_nr_accesses（） 傳回值作為分母。當使用者將彙總間隔設定得非常高時，damon_hot_score（） 可能會傳回超出 [0， DAMOS_MAX_SCORE] 範圍的值。由於傳回值是作為 regions_score_histogram 陣列的索引，即 DAMOS_MAX_SCORE+1 大小，因此會造成越界陣列存取。這些問題可以相對容易地重現，如下所示。不過，需要 sysfs 寫入權限。# ./damo 啟動 --damos_action lru_prio_quota_space --damos100M \
    --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...][ 131.329762] 哎呀：除法錯誤：0000 [#1] SMP NOPTI [...][131.336089] RIP：0010：damon_hot_score+0x27/0xd0 [...]透過明確處理 damon_max_nr_accesses（） 中的零間隔來修正除以零間隔問題。在從 damon_hot_score（） 返回之前，套用 [0， DAMOS_MAX_SCORE] 邊界，以修正越界陣列存取。這個問題是由 Sashiko 發現的 [1]。（CVE-2026-64458）

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

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

  - usbip： vudc：修正 vep_dequeue（） 中的空取消參照 vep_alloc_request（） 未初始化 vrequest->udc，因此 FunctionFS AIO 路徑上的取消會在沒有有效 UDC 參照的情況下到達vep_dequeue。由於 vrequest->udc 實際上從未在任何地方正確使用，因此我們選擇將其刪除，並更新 vep_dequeue以使用 ep_to_vudc（） 獲取對 udc 的引用，這與其他vep_操作一致。AFAICT 這個錯誤已經存在了 ~10 年。似乎沒有人真正強調 usbip 的 vudc 上的 FunctionFS AIO 路徑。我在透過 AIO 驅動 FunctionFS 端點的 QEMU aarch64 客體中測試了此修復。在修正之前，從主機執行「usbip attach」會導致客體以下列回溯追蹤 oops： 呼叫追蹤：
    vep_dequeue+0x1c/0xe4 （P） usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34
    __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158 （CVE-2026-64331）

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

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

  - bpf：允許從可休眠的 BPF 程式存取 LPM 映射 trie_lookup_elem（） 僅使用 rcu_read_lock_bh_held（） 註釋其 rcu_dereference_check（） 遍歷。因為 rcu_dereference_check（p， c） 解析為 c ||rcu_read_lock_held（），這對於 XDP/NAPI 和傳統 RCU 讀取器來說是通過的，但對於可休眠的 BPF 程式來說是失敗的，這些程式透過 __bpf_prog_enter_sleepable（） 進入並且僅保留 rcu_read_lock_trace（）。
    trie_update_elem（） 和 trie_delete_elem（） 以不同的形式存在相同的問題：它們使用簡單的 rcu_dereference（） 來運行 trie，無條件地斷言 rcu_read_lock_held（）。兩者都可以透過 bpf_map_update_elem / bpf_map_delete_elem 協助程式從可休眠的 BPF 程式以及從傳統 rcu_read_lock（） 下的系統調用路徑存取。在寫入器路徑中，trie 實際上受到 trie->lock （跨越遍歷的 rqspinlock） 保護;我們從不依賴 RCU 讀取端鎖來保持節點在那裡活動。因此，最終接觸 LPM trie 的可休眠 LSM 鉤子會在除錯核心上觸發 lockdep：
    ============================= 警告：可疑的 RCU 使用-...7.1.0 污染：G E
    ----------------------------- kernel/bpf/lpm_trie.c：249 可疑的 rcu_dereference_check（） 用法！net_tests/540 持有的 1 個鎖： #0（rcu_tasks_trace_srcu_struct）{....}-{0:0}，位於：
    __bpf_prog_enter_sleepable+0x26/0x280 呼叫追蹤：dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_...security_socket_connect __sys_connect do_syscall_64 這是僅限 lockdep 的 -- 沒有 UAF，因為 Tasks Trace RCU 確實會針對 trie 的回收路徑進行序列化 -- 但它會在每個執行接觸 LPM trie 的可休眠 BPF LSM 的除錯核心上，每個不同的呼叫點向主控台發送一次垃圾郵件，這越來越常見。對於查詢路徑，將 rcu_dereference_check（） 註解從 rcu_read_lock_bh_held（） 切換為 bpf_rcu_lock_held（），後者接受所有三個內容 （傳統、BH、任務追蹤）。其他地圖類型已遵循此慣例。對於 trie_update_elem（） 和 trie_delete_elem（），請將遍歷註解為 rcu_dereference_protected（*p， 1） -- 符合相同檔案中的 trie_free（） -- 因為在遍歷中保持 trie->lock。rqspinlock 沒有lockdep_map，因此述詞退化為「1」而不是 lockdep_is_held（&trie->lock）;保護是真實的，但無法通過機器驗證。trie_get_next_key（） 也使用裸rcu_dereference（），但只能從 BPF 系統調用訪問，該調用在分派之前保存經典 rcu_read_lock（），因此保持不變。(CVE-2026-64352)

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

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

  - 已解決 Linux 核心中的下列弱點：perf/aux: Fix page UAF in map_range() map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are serialized by rb->aux_mutex, and mmap_mutex is per event.
    Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows: CPU 0 CPU 1 ===== ===== rb_alloc_aux() map_range() [1]:
    allocate rb->aux_pages[0] [2]: rb->aux_nr_pages++ [3]: perf_mmap_to_page() returns rb->aux_pages[0] [4]:
    map it as VM_PFNMAP [5]: rb->aux_pgoff = 1 munmap the page [6]: free rb->aux_pages[0] Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame. Fix this by taking rb->aux_mutex across the page walk in map_range(). (CVE-2026-64300)

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

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

  - isofs：將 Rock Ridge 符號連結元件繫結至 SL 記錄 get_symlink_chunk（），而 parse_rock_ridge_inode_internal（） 中的 SL 處理會遍歷 Rock Ridge SL （符號連結） 記錄的可變長度元件。每個元件都是一個兩個位元組的標頭（flags、len），後面接著 len 位元組的文字，因此它佔用 slp->len + 2 個位元組。這兩個迴圈都讀取 slp->len 並前進到下一個元件，並且 get_symlink_chunk（） 還執行 memcpy（rpnt， slp->text， slp->len），但在取消引用之前都不會檢查元件是否位於 SL 記錄中。因此，特製的 SL 記錄，其元件宣告經過該記錄的 len （rr->len） 會觸發最多 255 個位元組的越界讀取。當記錄位於其支援緩衝區的尾部時 （例如，透過 CE 記錄連線到的小型 kmalloc（） 接續區塊 - 讀取會跨越配置;然後，get_symlink_chunk（） 將越界位元組複製到 readlink（） 返回給使用者空間的符號連結主體中，從而洩露相鄰的核心記憶體。ISO 9660 映像通常會從不受信任的卸任式多媒體掛載 - 桌面環境會自動掛載它們（例如，透過 udisks2），無需CAP_SYS_ADMIN - 因此記錄內容由攻擊者控制。在使用之前，拒絕任何不適合剩餘記錄位元組的元件。在 get_symlink_chunk（） 中傳回 NULL，就像現有的輸出緩衝區 （plimit） 檢查一樣，因此格式錯誤的記錄會使 readlink（） 以 -EIO 失敗，而不是無訊息地傳回截斷的目標;在 parse_rock_ridge_inode_internal（） 中，停止 inode 大小遍歷。
    (CVE-2026-64317)

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

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

  - tipc：修正廣播間隙 ACK 區塊中的越界讀取 廣播 PROTOCOL/STATE_MSG 可以在其資料區域中攜帶間隙 ACK 區塊記錄。tipc_get_gap_ack_blks（） 僅驗證記錄的 len 欄位是否與其 ugack_cnt/bgack_cnt計數自洽 （sz == struct_size（p， gacks， ugack_cnt + bgack_cnt））;
    它不會檢查記錄是否實際適合訊息資料區 msg_data_sz（）。單播呼叫端 tipc_link_proto_rcv（） 會限制它 （if （glen > dlen） break;），但廣播呼叫端 tipc_bcast_sync_rcv（） 捨棄傳回的大小，因此 tipc_link_advance_transmq（） 會使用攻擊者控制的計數從接收 skb 複製記錄：this_ga = kmemdup（ga， struct_size（ga， gacks， ga->bgack_cnt）， GFP_ATOMIC）;協商TIPC_GAP_ACK_BLOCK的 TIPC 鄰居使用一個普通廣播STATE_MSG （msg_bc_ack_invalid（） 清除） 觸發它，其大小使其資料區域較短，攜帶 len = 0x400、bgack_cnt = 0xff 且 ugack_cnt = 0 的間隙 ACK 記錄。len 則等於 struct_size（p， gacks， 255），因此一致性檢查通過且 ga 為非 NULL;kmemdup（） 從小得多的 skb 中讀取 struct_size（GA， gacks， 255） = 1024 位元組： 錯誤：KASAN：kmemdup_noprof+0x48/0x60 中的 slab-out-of-bounds 透過任務 poc864/69 在 addr ffff0000c7030d38 讀取大小 1024 呼叫追蹤：kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 有錯誤的位址屬於ffff0000c7030d00 處的物件，屬於大小為 704 的快取skbuff_small_head 錯誤位址位於已配置的 704 位元組區域內 56 位元組 [ffff0000c7030d00， ffff0000c7030fc0） 複製的位元組隨後會作為 gap/ack 值使用，但無論如何使用它們，讀取都已經超出 kmemdup（） 的越界。單播 STATE 路徑會丟棄這類訊息：if （glen > dlen） break;會跳過其餘STATE_MSG處理，並釋放 skb。讓廣播路徑也刪除它。
    tipc_bcast_sync_rcv（） 現在會針對 msg_data_sz（） 設定記錄，並在記錄不適合時，透過 tipc_node_bc_sync_rcv（） 將其報告回 tipc_rcv（），以便捨棄而不是處理 skb。在此路徑上未清除 ga：ga == NULL 已經表示沒有選擇性 ACK 的舊版對等體，這是不同的合法狀態。（CVE-2026-64450）

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

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

  - USB：小工具： 函數：rndis：新增標頭的長度檢查 在 rndis_rm_hdr 中新增 rndis 標頭的長度檢查，以確保在存取 MessageType、MessageLength、DataOffset 和 DataLength 欄位之前存在。（CVE-2026-64505）

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

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

  - 暫存：rtl8723bs：修正 issue_assocreq（） 和 join_cmd_hdl（） 中 IE 迴圈中的 OOB 讀取 兩個 IE 剖析迴圈在取消參照 pIE->length 之前遺漏標頭邊界檢查： - issue_assocreq（） 遍歷 pmlmeinfo->network.ies 以建立關聯要求。如果儲存的 IE 資料結尾只有 element_id 個位元組，而且沒有長度位元組，則會在緩衝區結尾一個位元組後讀取 pIE->length。- join_cmd_hdl（） 在站點加入期間遍歷 pnetwork->ies，並在相同條件下遇到相同的問題。
    這兩個緩衝區都是從 AP 信標和探查回應框架填充的，因此傳送截斷的最終 IE 的惡意 AP 可能會觸發此問題。套用 update_beacon_info（） 中建立的雙保護模式： 1. 如果剩餘的位元組少於 sizeof（*pIE） 個位元組，則中斷。2. 如果 IE 宣告的資料延伸超過緩衝區端，則中斷。
    (CVE-2026-64442)

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

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

  - NFSv4：在 O_TRUNC 的開放權限遮罩中包含 MAY_WRITE POSIX 需要寫入權限才能截斷檔案，因此無論 O_ACCMODE 存取模式為何，指定O_TRUNC的 open（） 都必須獲得寫入存取權的授權。nfs_open_permission_mask（） 建立傳遞給 nfs_may_open（） 的存取遮罩，這是用戶端透過 nfs4_try_open_cached（） 中的 can_open_delegated（） 路徑從快取的寫入委派自行服務的 OPEN 的本機授權閘道。遮罩是單獨衍生自O_ACCMODE，因此 open（O_RDONLY |O_TRUNC） 針對檔案，呼叫端只能MAY_READ寫入要求，並通過本機檢查。然後在本端滿足 OPEN，並將截斷作為委派 stateid 的 SETATTR（size=0） 發出給伺服器，伺服器在標準寫入委派語意下接受該委派。POSIX 要求使用 EACCES 進行此開啟失敗。每當設定O_TRUNC時，請在遮罩中包含MAY_WRITE，以便本機檢查符合伺服器本應強制執行的存取權。（CVE-2026-64298）

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

ID	名稱	嚴重性
329884	Linux Distros 未修補弱點：CVE-2026-64276	high
329883	Linux Distros 未修補弱點：CVE-2026-64330	high
329882	Linux Distros 未修補弱點：CVE-2026-64315	high
329881	Linux Distros 未修補弱點：CVE-2026-64282	medium
329880	Linux Distros 未修補弱點：CVE-2026-64289	medium
329879	Linux Distros 未修補弱點：CVE-2026-64432	high
329878	Linux Distros 未修補弱點：CVE-2026-64520	high
329877	Linux Distros 未修補弱點：CVE-2026-64342	high
329876	Linux Distros 未修補弱點：CVE-2026-64393	critical
329875	Linux Distros 未修補弱點：CVE-2026-64422	high
329874	Linux Distros 未修補弱點：CVE-2026-64334	medium
329873	Linux Distros 未修補弱點：CVE-2026-64345	medium
329872	Linux Distros 未修補弱點：CVE-2026-64495	high
329871	Linux Distros 未修補弱點：CVE-2026-64307	medium
329870	Linux Distros 未修補弱點：CVE-2026-64400	high
329869	Linux Distros 未修補弱點：CVE-2026-64256	medium
329868	Linux Distros 未修補弱點：CVE-2026-64465	medium
329867	Linux Distros 未修補弱點：CVE-2026-64434	high
329866	Linux Distros 未修補弱點：CVE-2026-64454	medium
329865	Linux Distros 未修補弱點：CVE-2026-64314	medium
329864	Linux Distros 未修補弱點：CVE-2026-64438	high
329863	Linux Distros 未修補弱點：CVE-2026-64303	critical
329862	Linux Distros 未修補弱點：CVE-2026-64479	high
329861	Linux Distros 未修補弱點：CVE-2026-64274	high
329860	Linux Distros 未修補弱點：CVE-2026-64272	high
329859	Linux Distros 未修補弱點：CVE-2026-64420	high
329858	Linux Distros 未修補弱點：CVE-2026-64355	critical
329857	Linux Distros 未修補弱點：CVE-2026-64464	high
329856	Linux Distros 未修補弱點：CVE-2026-64344	high
329855	Linux Distros 未修補弱點：CVE-2026-64305	high
329854	Linux Distros 未修補弱點：CVE-2026-64351	medium
329853	Linux Distros 未修補弱點：CVE-2026-64421	high
329852	Linux Distros 未修補弱點：CVE-2026-64490	high
329851	Linux Distros 未修補弱點：CVE-2026-64478	medium
329850	Linux Distros 未修補弱點：CVE-2026-64259	high
329849	Linux Distros 未修補弱點：CVE-2026-64261	high
329848	Linux Distros 未修補弱點：CVE-2026-64504	high
329847	Linux Distros 未修補弱點：CVE-2026-64328	medium
329846	Linux Distros 未修補弱點：CVE-2026-64341	high
329845	Linux Distros 未修補弱點：CVE-2026-64425	medium
329844	Linux Distros 未修補弱點：CVE-2026-64346	high
329843	Linux Distros 未修補弱點：CVE-2026-64458	medium
329842	Linux Distros 未修補弱點：CVE-2026-64331	medium
329841	Linux Distros 未修補弱點：CVE-2026-64352	high
329840	Linux Distros 未修補弱點：CVE-2026-64300	high
329839	Linux Distros 未修補弱點：CVE-2026-64317	high
329838	Linux Distros 未修補弱點：CVE-2026-64450	critical
329837	Linux Distros 未修補弱點：CVE-2026-64505	high
329836	Linux Distros 未修補弱點：CVE-2026-64442	high
329835	Linux Distros 未修補弱點：CVE-2026-64298	high

偵測

Nessus 的 Misc. 系列

high

high

high

medium

medium

high

high

high

critical

high

medium

medium

high

medium

high

medium

medium

high

medium

medium

high

critical

high

high

high

high

critical

high

high

high

medium

high

high

medium

high

high

high

medium

high

medium

high

medium

medium

high

high

high

critical

high

high

high