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

  - crypto：qat - 移除未使用的字元裝置和 IOCTL QAT 驅動程式會公開字元裝置 （qat_adf_ctl） ，其中包含 IOCTL，用於裝置設定、啟動、停止、狀態查詢和列舉。這些 IOCTL 不是任何公用 uAPI 標頭的一部分，而且沒有已知的樹狀結構內或樹狀結構外使用者。裝置生命週期已透過 sysfs 進行管理。ioctl 介面也會增加攻擊破綻，並成為許多錯誤報告的主題。移除字元裝置、IOCTL 定義和相關的資料結構 （adf_dev_status_info、adf_user_cfg_key_val、adf_user_cfg_section、adf_user_cfg_ctl_data） 。
    刪除現在未使用的 adf_cfg_user.h 標頭，並將 adf_ctl_drv.c 剝離為最小的 module_init/module_exit 勾點，用於工作佇列、AER 和加密/壓縮演算法註冊。清除只能從已移除的 IOCTL 路徑連線的剩餘無效程式碼：adf_cfg_del_all（） 、adf_devmgr_verify_id （） 、adf_devmgr_get_num_dev （） 、adf_devmgr_get_dev_by_id （） 、adf_get_vf_real_id（） 和未使用的 ADF_CFG 巨集。此外，刪除 ioctl-number.rst 中與 QAT IOCTL 相關聯的項目。
    (CVE-2026-64529)

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

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

  - 已解決 Linux 核心中的下列弱點：usb: misc: usbio: fix disconnect UAF in client teardown usbio_disconnect() walks usbio->cli_list in reverse and uninitializes each auxiliary device. auxiliary_device_uninit() drops the device reference, and for an unbound child that can run usbio_auxdev_release() and free the containing struct usbio_client. list_for_each_entry_reverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliary_device_uninit(), the iterator dereferences freed memory. Use list_for_each_entry_safe_reverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime.
    Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150 Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? usbio_disconnect+0x12e/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? usbio_disconnect+0x12e/0x150 kasan_report+0xe0/0x110 ? usbio_disconnect+0x12e/0x150 usbio_disconnect+0x12e/0x150 usb_unbind_interface+0xf3/0x400 really_probe+0x316/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60
    __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ?
    _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? usb_enable_lpm+0x3c/0x260 usb_set_configuration+0xb64/0xf20 usb_generic_driver_probe+0x5f/0x90 usb_probe_device+0x71/0x1b0 really_probe+0x46b/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110
    __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ?
    __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ?
    __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_device_randomness+0xb7/0xf0 usb_new_device+0x492/0x870 hub_event+0x1b10/0x29c0 ?
    __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x187/0x300 ? process_one_work+0x475/0xb90 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ?
    __list_add_valid_or_report+0x37/0xf0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ?
    __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> (CVE-2026-64453)

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

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

  - smb/client：修正具有 SMB3 POSIX 延伸模組的 chown/chgrp 使用 SMB3 POSIX 延伸模組裝載時，會忽略擁有權 （chown） 和群組 （chgrp） 修改，除非也明確設定了 CIFS_MOUNT_CIFS_ACL 或 CIFS_MOUNT_MODE_FROM_SID。透過在更新 UID 和 GID 時檢查 cifs_setattr_nounix（） 中的posix_extensions來解決此問題，確保呼叫 id_mode_to_cifs_acl（） 來映射和設定伺服器上的所有權/群組資訊。（CVE-2026-64388）

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

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

  - 已解決 Linux 核心中的下列弱點：iommufd: Move vevent memory allocation outside spinlock The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves. Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail fast under memory pressure without dipping into the GFP_ATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the lost_events_header (so userspace learns of the drop) and return
    -ENOMEM so the caller learns of the kernel-side memory pressure. This is intentionally distinct from the queue-overflow path, which also queues the lost_events_header but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error. A subsequent change will cap the upper bound of the veventq_depth. (CVE-2026-64292)

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

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

  - ksmbd：將開啟程式認證用於關閉時刪除 關閉時刪除可以透過延遲或持久控點拆卸來完成，其中沒有可用的要求工作。因此，基底檔案解除連結和 ADS xattr 移除都會使用 ksmbd 背景工作者憑證執行，並且可以繞過檔案系統權限檢查。開啟控制碼時，使用結構檔案中擷取的認證來執行這兩個作業。這會在最終關閉時保留已驗證使用者的 fsuid、fsgid、補充群組和功能限制。
    (CVE-2026-64392)

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

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

  - hfs/hfsplus：修正 check_and_correct_requested_length check_and_correct_requested_length（） 中的 u32 溢位，使用 u32 算術將 （off + len） 與 node_size 進行比較。當調用方傳遞一個大的 len 值時（例如，來自 hfs_brec_remove（） 中的下溢減法），off + len 可以換行超過 2^32 並產生一個小結果，導致邊界檢查在應該失敗時通過。例如，當 off=14 且 len=0xFFFFFFF2 （從 data_off - keyoffset - size in hfs_brec_remove 反向溢位） 時，off + len 會換行至 6，這小於典型的 node_size 512，因此檢查通過，後續的 memmove 讀取 ~4GB 超過節點緩衝區。在與 node_size 進行比較之前，通過擴大對 u64 的添加來解決此問題。這可以防止 u32 包裝，同時保持邏輯簡單。（CVE-2026-64361）

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

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

  - 藍牙：hci_conn：當連線擱置時，修正 hci_abort_conn（） hci_abort_conn（） 讀取hci_skb_event （hdev->sent_cmd） 中的空 ptr 解除參照，但當 req_status 仍處於HCI_REQ_PEND狀態時，hdev->sent_cmd 可能為 NULL，從而導致 NULL 指標解除參照和來自 hci_rx_work（） 接收路徑的一般保護錯誤。不要檢查 hdev->sent_cmd，而是使用新的 per-connection HCI_CONN_CREATE 旗標追蹤正在進行的建立連接命令，並透過 hci_cancel_connect_sync（） 路由所有取消，該 （） 會分派到專用的 per-type 取消函式。create 命令正處於以下兩種狀態之一：仍在佇列中或正在進行中。取消函數在整個決策中保留cmd_sync_work_lock：背景工作者使用此鎖來出列每個項目，因此當它被保留時，佇列的命令無法開始運行，並且正在進行的命令無法完成，並讓下一個命令成為擱置狀態。這會讓旗標 test 和 hci_cmd_sync_cancel（） 相對於背景工作保持不可部分完成，因此佇列中的命令只會出列，並且取消此連線所擁有的進行中命令，而不會取消同時變成擱置中的不相關命令的風險。CIS 透過HCI_CONN_CREATE_CIS使用相同的旗標機制，但無法針對每個連線出列。hci_acl_create_conn_sync（） 和 hci_le_create_conn_sync（） 會在 create 命令完成後清除HCI_CONN_CREATE，但命令狀態處理常式可以透過 hci_conn_del（） 釋放 conn （例如，當控制器拒絕連線時），而背景工作程式仍會在連線完成事件上遭到封鎖。在 create 命令中保留 conn 上的參照，以便在沒有釋放後使用的情況下清除旗標。（CVE-2026-64405）

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

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

  - posix-cpu-timers：修正 do_cpu_nanosleep（） 錯誤路徑中的 pid 參照計數洩漏 在 do_cpu_nanosleep（） 中，posix_cpu_timer_create（） 透過 get_pid（） 獲取 pid 參照並將其儲存在 timer.it.cpu.pid 中。如果後續的posix_cpu_timer_set（）呼叫失敗，函數會立即返回，而不呼叫posix_cpu_timer_del（）釋放pid引用，從而造成洩漏。透過在錯誤路徑上的解鎖和返回之前呼叫 posix_cpu_timer_del（） 來修正它，與同一函式中的其他退出路徑一致。（CVE-2026-64370）

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

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

  - x86/錯誤：在 BPF JIT 分配時啟用 IBPB 重新整理 當使用 Spectre-v2 緩解措施時，啟用針對 JIT 噴灑的強化。具體而言，請針對 BPF JIT 記憶體重複使用發出 IBPB 排清。如果 BPF 分派器已使用 retpoline 序列，請跳過啟用 IBPB 排清。只有在使用 BPF-JIT 時，才適用此強化。保護 CONFIG_BPF_JIT 下的啟用，以便 bugs.c 仍以 CONFIG_BPF_JIT=n 建置。
    (CVE-2026-64507)

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

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

  - crypto： pcrypt - 還原非平行後援回呼 pcrypt 會在子 AEAD 要求上安裝 pcrypt_aead_done（），然後再嘗試透過 padata 提交。如果 padata_do_parallel（） 傳回 -EBUSY，pcrypt 會回復為直接呼叫子 AEAD。該後援不得保留 padata 完成回呼。否則，非同步完成會執行 pcrypt_aead_done（），即使要求從未在 padata 中註冊。在直接呼叫子 AEAD 之前，先還原原始要求回呼和回呼資料。這會使後援路徑與直接 AEAD 要求保持一致，同時保持平行路徑不變。（CVE-2026-64312）

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

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

  - 已解決 Linux 核心中的下列弱點：usb: misc: usbio: bound bulk IN response length to the received transfer usbio_bulk_msg() copies bpkt_len = le16_to_cpu(bpkt->len) bytes out of the bulk IN buffer (usbio->rxbuf, allocated with size usbio->rxbuf_len) into the caller's buffer.
    bpkt_len is fully controlled by the device and is only checked against ibuf_len; ibuf_len in turn is checked against usbio->txbuf_len, not against rxbuf_len: if ((obuf_len > (usbio->txbuf_len - sizeof(*bpkt))) || (ibuf_len > (usbio->txbuf_len - sizeof(*bpkt)))) return -EMSGSIZE; txbuf_len and rxbuf_len are taken independently from the bulk OUT and bulk IN endpoint wMaxPacketSize in usbio_probe().
    A malicious or malfunctioning device that advertises a large bulk OUT endpoint and a small bulk IN endpoint (e.g. by claiming one of the quirk-free IDs such as the Lattice NX33U, 0x2ac1:0x20cb) therefore makes ibuf_len, and hence the device-supplied bpkt_len, exceed rxbuf_len. memcpy() then reads up to txbuf_len - rxbuf_len bytes past the end of the rxbuf slab object. The over-read bytes are handed back to the i2c layer and on to user space through i2c-dev, disclosing adjacent slab memory; with KASAN this is reported as a slab-out-of-bounds read. The number of bytes actually received is already known: act equals the URB actual_length and is bounded by rxbuf_len. Reject any response that claims more payload than was received, mirroring the existing act < sizeof(*bpkt) check just above. The control path (usbio_ctrl_msg()) is not affected: it uses a single buffer (ctrlbuf) for both directions, so its analogous copy can never leave the allocation. Found by code review. The out-of-bounds read was confirmed under AddressSanitizer with a faithful userspace model of usbio_bulk_msg()'s receive path (an rxbuf_len-sized buffer, the same act/ibuf_len/bpkt_len checks and the memcpy). A USB raw-gadget + dummy_hcd reproducer is also available. (CVE-2026-64339)

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

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

  - nvmet：修正探索取得記錄頁 nvmet_execute_disc_get_log_page（） 中的預先驗證越界堆積讀取，只會驗證主機提供的記錄頁位移 （lpo） 的 dword 對齊方式。然後，將 64 位元偏移量新增至保存發現日誌頁面的小型 kzalloc'd 緩衝區，並將結果直接傳遞給 nvmet_copy_to_sgl（），其中 memcpy（） 會data_len位元組輸出給主機，而沒有來源端綁定檢查：u64 偏移量 = nvmet_get_log_page_offset（req->cmd）;/* 64 位元主機 */ size_t data_len = nvmet_get_log_page_len（req->cmd）;/* 32 位元主機 */ ...if （offset &; 0x3） { ... } /* 僅檢查 */ ...
    alloc_len = sizeof（*hdr） + entry_size * discovery_log_entries（req）;緩衝區 = kzalloc（alloc_len， GFP_KERNEL）;...狀態 = nvmet_copy_to_sgl（req， 0， buffer + offset， data_len）;探索控制器未經鑑別 -- nvmet_host_allowed（） 無條件地傳回探索子系統的 true -- 因此，任何可以到達 nvmet 目標的 TCP/RDMA/FC 對等體都可以預先鑑別來連線呼叫。當探索記錄頁面為 ~1 KiB 時，攻擊者從位移 == 開始要求最多 4 KiB alloc_len 會讀取下一個 slab 頁面，並透過光纖傳回其內容 （在預設 nvmet-tcp 回送目標上實證執行，在一個 Get Log Page 回應中洩漏了 81 個標準核心指標）。將位移指向未對應的核心記憶體會導致核心內 memcpy 出錯，並改為當機 （或錯誤，在 panic_on_oops=1） 上）。攻擊者控制的來源端偏移模式 nvmet_copy_to_sgl（req， 0， buffer + ATTACKER_OFFSET， ...） 對於整個 nvmet 程式碼庫中的 nvmet_execute_disc_get_log_page 來說是唯一的：admin-cmd.c 中的每個其他 Get Log Page 處理常式要麼忽略 lpo （並在位移量 0 處無訊息地啟動每個回應），要麼使用固定來源指標追蹤本機目的地偏移。針對記錄頁面大小驗證主機提供的位移、將副本長度限制為實際可用的長度，並將主機傳輸緩衝區的任何其餘部分歸零。零填入符合 nvmet_execute_get_log_changed_ns（） （admin-cmd.c） 中現有的短回應模式，並防止在主機要求的位元組數超過記錄頁面包含的位元組時洩露傳輸 SGL 內容。（CVE-2026-64320）

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

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

  - ALSA： caiaq：修正 Traktor Kontrol S4 輸入剖析器 snd_usb_caiaq_tks4_dispatch（） 中的越界讀取，將 Traktor Kontrol S4 輸入資料流解碼為固定的 16 位元組 （TKS4_MSGBLOCK_SIZE） 訊息區塊。在每次迭代中，它都會推進 buf 並減去區塊大小，同時循環 while （len）。Len 是城市>actual_length。該值由裝置提供，不保證是 16 的倍數。
    當最後一個短區塊離開 len 介於 1 到 15 之間時，循環再次運行，讀取到 buf[15]，然後執行 len -= TKS4_MSGBLOCK_SIZE。由於 len 未簽名，這下溢到一個巨大的價值。然後，循環繼續迭代並遍歷 buf 遠遠超過 512 位元組ep4_in_buf的末尾，讀取越界，直到碰巧命中虛假區塊 ID。僅在有完整訊息區塊可用時反覆運算。這會停止未帶正負號的反向溢位，並無訊息地刪除任何尾隨部分區塊，無論如何，該區塊都不帶有完整的控制值。同級 endpoint-4 剖析器不受影響。Traktor Kontrol X1 和 Maschine 在調度前在 snd_usb_caiaq_ep4_reply_dispatch（） 地板城市>actual_length中部署。（CVE-2026-64487）

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

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

  - 已解決 Linux 核心中的下列弱點：xfs: fix exchmaps reservation limit check xfs_exchmaps_estimate_overhead() adds the bmbt and rmapbt overhead to a local resblks variable, but the final UINT_MAX check still tests req->resblks. That is the reservation value from before the overhead was added. The computed value is stored back in req->resblks and later passed to xfs_trans_alloc(), whose block reservation argument is unsigned int. Check the computed reservation so the existing limit applies to the value that will be used. (CVE-2026-64357)

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

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

  - mm：shrinker：修正 debugfs 中的 NULL 指標解除參照 shrinker_debugfs_add（） 會無條件地建立計數和掃描 debugfs 檔案。這假設每個縮減器都同時實作 count_objects（） 和 scan_objects（），這並不能保證。例如，xen-backend 縮減器設定 count_objects（） 但保留 scan_objects（） 為 NULL，因此透過 NULL 函數指標寫入其掃描檔案呼叫並使核心陷入錯誤： 錯誤：核心 NULL 指標解除參照，位址：00000000000000000 RIP：0010：0x0 程式碼：無法存取 0xffffffffffffffd6 處的操作碼位元組。呼叫追蹤： <TASK> shrinker_debugfs_scan_write+0x12e/0x270 full_proxy_write+0x5f/0x90 vfs_write+0xde/0x420 ？ filp_flush+0x75/0x90 ？ filp_close+0x1d/0x30 ？ do_dup2+0xb8/0x120 ksys_write+0x68/0xf0 ？ filp_flush+0x75/0x90 do_syscall_64+0xb3/0x5b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 原則上，如果縮小器省略了 count_objects（），計數路徑也會有相同的問題。若要修正此問題，請僅在存在對應回呼時建立計數並掃描 debugfs 檔案。（CVE-2026-64417）

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

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

  - ALSA： ymfpci：檢查 snd_ctl_new1（） 傳回值 snd_ctl_new1（） 可以在記憶體配置失敗時傳回 NULL。snd_ymfpci_create_spdif_controls（） 不會在取消參照 kctl->id.device 之前檢查傳回值，這可能會導致 NULL 指標解除參照。在 snd_ctl_new1（） 呼叫後新增 NULL 檢查，如果有失敗，則傳回 -ENOMEM。（CVE-2026-64489）

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

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

  - Bluetooth： MGMT：修正 add_device_complete add_device_complete（） 中從 hci_cmd_sync_work kworker 執行的 hci_conn_params 的 UAF，該 kworker 僅包含 hci_req_sync_lock 個，*不* hci_dev_lock。它調用 hci_conn_params_lookup（），然後取消參照傳回的物件 （params->flags），而不採取hci_dev_lock：params = hci_conn_params_lookup（hdev， &cp->addr.bdaddr， le_addr_type（cp->addr.type））;...
    device_flags_changed（NULL， hdev， &cp->addr.bdaddr， cp->addr.type， hdev->conn_flags， params ？ params->flags ： 0）;hci_conn_params_lookup（） 遍歷 hdev->le_conn_params，並記錄為需要 hdev->lock。在 hci_dev_lock 下運行的並發MGMT_OP_REMOVE_DEVICE （remove_device（）） 可以調用 hci_conn_params_free（） 來查找返回的對象 list_del（） 和 kfree（），因此後續的 params->flags 讀取會接觸釋放的記憶體 [0]。在 hci_conn_params_lookup（） 和讀取 params->flags（以及相符的事件發出）中保留 hci_dev_lock（），這樣查找結果就不能在使用之前被並發 remove_device（） 釋放，從而遵守 hci_conn_params_lookup（） 的鎖定合約。
    [0]：（尾隨頁面/記憶體狀態轉儲已修剪） 錯誤： KASAN：add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c：7671 在 addr ffff000017ab26c1 處讀取大小 1 由任務 kworker/u9：8/388 CPU：1 UID：0 PID：388 通訊：kworker/u9：8 未受 7.0.11 #20 污染 PREEMPT 硬體名稱：
    linux，dummy-virt （DT） 工作佇列：hci0 hci_cmd_sync_work 呼叫追蹤：show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c：499 （C） __dump_stack lib/dump_stack.c：94 [內嵌] dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 [內嵌] print_report+0x118/0x5d8 mm/kasan/report.c：482 kasan_report+0xb0/0xf4 mm/kasan/report.c：595 __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c：378 add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c：7671 hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c：334 process_one_work+0x628/0xd38 kernel/workqueue.c：3289 process_scheduled_works kernel/workqueue.c：3372 [內聯] worker_thread+0x7a8/0xac0 kernel/workqueue.c：3453 kthread+0x39c/0x444 kernel/kthread.c：436 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry。S：860 由任務 3401 分配： kasan_save_stack+0x3c/0x64 mm/kasan/common.c：57 kasan_save_track+0x20/0x3c mm/kasan/common.c：78 kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c：570 poison_kmalloc_redzone mm/kasan/common.c：398 [內嵌] __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c：415 kasan_kmalloc include/linux/kasan.h：263 [內嵌] __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c：5385 kmalloc_noprof include/linux/slab.h：950 [內嵌] kzalloc_noprof include/linux/slab.h：1188 [內嵌] hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c：2279 hci_conn_params_set net/bluetooth/mgmt.c：5162 [內嵌] add_device+0x5b4/0xa54 net/bluetooth/mgmt.c：7755 hci_mgmt_cmd net/bluetooth/hci_sock.c：1721 [內嵌] hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c：1841 sock_sendmsg_nosec net/socket.c：727 [內嵌] __sock_sendmsg+0xe0/0x128 net/socket.c：742 sock_write_iter+0x250/0x390 net/socket.c：1195 new_sync_寫入 fs/read_write.c：595 [內嵌] vfs_write+0x66c/0xab0 fs/read_write.c：688 ksys_write+0x1fc/0x24c fs/read_write.c：740 __do_sys_write fs/read_write.c：751 [內嵌] __se_sys_write fs/read_write.c：748 [內嵌] __arm64_sys_write+0x70/0xa4 fs/read_write.c：748 __invoke_syscall arch/arm64/kernel/syscall.c：35 [內嵌] invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c：49 el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c：132 do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c：151 el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c：724 el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c：743 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry。S：596 被任務 3740 釋放：kasan_save_stack+0x3c/0x64 ---truncated--- （CVE-2026-64433）

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

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

  - USB： cdnsp：修正 cdnsp_alloc_stream_info（） 中的串流上下文陣列洩漏 cdnsp_alloc_stream_info（） 使用 cdnsp_alloc_stream_ctx（） 配置 stream_info->stream_ctx_array。如果稍後的資料流程通道配置或資料流程對應更新失敗，錯誤路徑會釋放配置的資料流程通道和stream_rings陣列，但會保留配置stream_ctx_array。在流向stream_rings清除路徑之前，先釋放資料流內容陣列。（CVE-2026-64350）

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

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

  - 暫存：rtl8723bs：修正 update_beacon_info（） IE 迴圈中的 OOB 讀取 update_beacon_info（） 中的 IE 剖析迴圈每次反覆運算都會前進 （pIE->length + 2），但只會保護 i < len。當惡意 AP 傳送的信標，其最後一個 IE 在框架中僅剩下一個位元組 （element_id 位元組位於 len-1） 時，迴圈會從經過分配的接收緩衝區的一個位元組讀取 pIE->length。此外，即使標頭位元組在邊界內，pIE->length 本身也可以將資料視窗延伸至 len 之外，將截斷的 IE 傳遞至處理常式函式。在迴圈主體的頂端新增兩個保護： 1. 如果剩餘的位元組少於 sizeof（*pIE） 位元組，則中斷 （無法讀取標頭）。2. 如果 IE 宣告的資料延伸超過 len，則中斷。同時將 i += （pIE->length + 2） 替換為 i += sizeof（*pIE） + pIE->length，以便與上面新增的 sizeof（*pIE） 保護保持一致。（CVE-2026-64443）

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

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

  - 已解決 Linux 核心中的下列弱點：ALSA: compress: Fix task creation error unwind snd_compr_task_new() allocates the driver task before validating the returned DMA buffers and reserving file descriptors. When either of those later steps fails, the core frees its task wrapper and DMA-buffer references without calling the driver's task_free() callback. Any driver resources allocated by task_create() are therefore leaked. The dual-fd allocation path also jumps to cleanup without storing the negative get_unused_fd_flags() result in retval. Since retval still contains the successful task_create() return value, TASK_CREATE can incorrectly report success although the task was discarded. Preserve the fd allocation errors and call task_free() when failure occurs after a successful task_create() callback.
    (CVE-2026-64485)

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

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

  - udf：驗證備用表長度作為項目計數，而不是位元組計數 當 sizeOf（*st） + le16_to_cpu（st->reallocationTableLen） > sb->s_blocksize 為 false 時，udf_load_sparable_map（） 接受備用表，即它將 reallocationTableLen 視為必須適合區塊的位元組數。但該表作為 8 位元組 sparingEntry 元素的陣列遍歷：for （i = 0; i < le16_to_cpu（st->reallocationTableLen）; i++） {struct sparingEntry *entry = &st->mapEntry[i]; ...entry->origLocation ... }在 udf_get_pblock_spar15（） 和 udf_relocate_blocks（） 中。因此，只要 sizeof（*st） + N <= 區塊大小，但消費者索引 sizeof（*st） + N * sizeof（struct sparingEntry） 位元組 -- 最多是區塊的 ~8 倍，N 的 relocationTableLen 就會通過檢查。在特製的 UDF 映像檔上，這是 udf_get_pblock_spar15（） 中的越界讀取;
    udf_relocate_blocks（） 還向 udf_update_tag（） 提供相同的長度，其 crc_itu_t（） 讀取範圍遠遠超過區塊，其透過 st->mapEntry[] 的 memmove（） 是越界寫入。使用 struct_size（） 驗證 reallocationTableLen 作為項目計數。(CVE-2026-64322)

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

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

  - ksmbd：在 smb2_ioctl（） 中新增 FSCTL_SET_ZERO_DATA FSCTL_SET_ZERO_DATA 的權限檢查，在僅檢查共用層級KSMBD_TREE_CONN_FLAG_WRITABLE之後，會透過 ksmbd_vfs_zero_data（） -> vfs_fallocate（PUNCH_HOLE/ZERO_RANGE） 破壞檔案資料，而沒有每個控制碼的存取檢查。僅用 FILE_WRITE_ATTRIBUTES 開啟的句柄仍然會產生FMODE_WRITE filp （FILE_WRITE_ATTRIBUTES是 FILE_WRITE_DESIRE_ACCESS_LE 的一部分，因此 smb2_create_open_flags（） 會O_WRONLY開啟它），因此vfs_fallocate FMODE_WRITE檢查不會停止它;只有缺少的 FP->D 存取門才能。由經過驗證的 SMB 用戶端在主線上 7.1-rc7 與 KASAN 重現：僅 FILE_WRITE_ATTRIBUTES 句柄將 4096 位元組的檔案資料歸零，它無權FILE_WRITE_DATA （6/6;僅 FILE_READ_DATA 句柄被正確拒絕）。
    這是提交 cc57232cae23 的未修正同級 （ksmbd：透過新增 FSCTL_SET_SPARSE 的權限檢查來修正 FSCTL 權限繞過）。因為SET_ZERO_DATA寫入資料 （不是屬性），所以需要FILE_WRITE_DATA。（CVE-2026-64398）

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

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

  - 調節器：scmi：修正 scmi_regulator_probe（） scmi_regulator_probe（） 呼叫 of_find_node_by_name（） 中的of_node參照計數洩漏，該呼叫在傳回的裝置節點上獲取參照。在 process_scmi_regulator_of_node（） 失敗的錯誤路徑上，函式會傳回而不呼叫子節點上的 of_node_put（），從而洩漏參照。在錯誤路徑上新增 of_node_put（np） 以正確釋放參照。
    (CVE-2026-64301)

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

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

  - 已解決 Linux 核心中的下列弱點：fuse-uring: remove request-less entries from ent_w_req_queue to fix NULL deref If a copy into the userspace ring buffer fails, a request will be terminated and fuse_uring_req_end() will set ent->fuse_req to NULL but it will leave the entry on ent_w_req_queue in FRRS_FUSE_REQ state. This can lead to a NULL deref if the request expiration logic scans ent_w_req_queue in the window before the entry is moved off it. Fix this by taking the entry off ent_w_req_queue and changing its state from FRRS_FUSE_REQ to FRRS_INVALID before terminating the request.
    (CVE-2026-64258)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: handle unreadable frags sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skb_frags_readable(skb) returns false) is processed by the u32 module, skb_copy_bits() will safely return a negative error code [..] xt_u32: bail out with hotdrop in this case. gather_frags: return -1, just as if we had no fragment header. nfnetlink_queue: restrict to the linear part. nfnetlink_log: restrict to the linear part. v2: - skb_zerocopy helpers don't copy readable flag, i.e. nfnetlink_queue is broken too xt_u32 shouldn't return true if hotdrop was set. (CVE-2026-64414)

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

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

  - SMB： client：修正查詢目錄重播雙重釋放 具有回應的嘗試可能會傳回可重播的錯誤，並釋放其回應緩衝區。如果 SMB2_query_directory_init（） 在下次傳送之前失敗，則清理會保留先前的緩衝區類型，並再次釋放該回應。每次嘗試前重設回應簿記，以防止無效釋放。(CVE-2026-64387)

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

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

  - 已解決 Linux 核心中的下列弱點：iommufd: Set veventq_depth upper bound iommufd_veventq_alloc() accepts any !0 veventq_depth from userspace, with an upper bound at U32_MAX. This leaves a vulnerability where userspace can allocate excessively large queues to exhaust kernel memory reserves. Cap the veventq_depth (maximum number of entries) to 1 << 19, matching the maximum number of entries in the SMMUv3 EVTQ (the largest use case today). (CVE-2026-64291)

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

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

  - iio： adc： lpc32xx： 在請求 IRQ 之前初始化完成 在 Jaeyoung Chung 的報告中：
    drivers/iio/adc/lpc32xx_adc.c 中的 lpc32xx_adc_probe（） 在使用 init_completion（） 初始化 st->completion 之前，先向 devm_request_irq（） 註冊其中斷處理常式。如果中斷在 devm_request_irq（） 之後和 init_completion（） 之前到達，則處理常式會在未初始化的完成時呼叫 complete（），從而導致核心錯誤。探查路徑，以 lpc32xx_adc_probe（） 為單位：iodev = devm_iio_device_alloc（&pdev->dev， sizeof（*st））;/* st kzalloc-zeroed */ ...retval = devm_request_irq（&pdev->dev， irq， lpc32xx_adc_isr， 0， LPC32XXAD_NAME， st）;/* 暫存器處理常式 */ ...
    init_completion（&st->completion）;/* 初始化完成 */ lpc32xx_adc_isr（） 呼叫 complete（）：
    complete（&st->completion）;如果裝置在 init_completion（） 執行之前引發中斷，complete（） 會取得未初始化的 wait.lock 並遍歷 swake_up_locked（） 中的歸零task_list。歸零的task_list使 list_empty（） 傳回 false，因此 swake_up_locked（） 解除參照 NULL 清單項目，觸發 KASAN wild-memory-access。透過將 init_completion（） 移至 devm_request_irq（） 上方，修正虛假 IRQ 導致未初始化指標解除參照的可能性。(CVE-2026-64500)

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

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

  - SMB： 用戶端：將伺服器提供的模式遮罩至 modefromsid 中的 07777 當 modefromsid 處於作用中狀態時，parse_dacl（） 會將伺服器提供的 sub_auth[2] 值從 NFS 模式 SID 套用至 cf_mode，而不遮罩至 07777。
    套用正確的遮罩，與讀取路徑中的遮罩相同。（CVE-2026-64379）

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

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

  - 藍牙：btmtksdio：修正 btmtksdio_txrx_work（） 中的無限迴圈 每隔一段時間，我們就會看到懸置的 btmtksdio_flush（） 任務： INFO：任務 kworker/u17：0：189 被封鎖超過 122 秒。
    __cancel_work_timer+0x3f4/0x460 cancel_work_sync+0x1c/0x2c btmtksdio_flush+0x2c/0x40 hci_dev_open_sync+0x10c4/0x2190 [..]這一切都歸結為 btmtksdio_txrx_work（） 中不正確的 time_is_before_jiffies（） 用法。如果執行時間超過 5*HZ，則預期會終止 btmtksdio_txrx_work（） 迴圈。然而，逾時檢查是扭曲的：當 old_jiffies + 5*HZ 過去時，即發生逾時時，time_is_before_jiffies（old_jiffies + 5*HZ） 的評估結果為 true。搭配 time_is_before_jiffies（txrx_timeout） 使用 OR 表示： - 在 5 秒逾時之前：條件為「int_status ||false'，因此只要有擱置中的中斷，它就會循環。- 5 秒逾時後：
    條件會變成「int_status ||true'，這始終為真。當迴圈變成無限時，btmtksdio_txrx_work（） 迴圈永遠不會終止，也永遠不會釋放 SDIO 主機。修正迴圈終止條件以實際執行 5*HZ 逾時。（CVE-2026-64409）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: SEV: Pin source page for write when adding CPUID data for SNP guest When populating a guest_memfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the source page as KVM will write back the correct CPUID information if the userspace provided data is rejected by trusted firmware. Because KVM writes to the source page using a kernel mapping, pinning for read could result in KVM clobbering read-only memory.
    Note, well-behaved VMMs are unlikely to be affected, as CPUID information is almost always dynamically generated by userspace, i.e. it's unlikely for the CPUID information to be backed by a read-only mapping.
    [sean: rewrite shortlog and changelog, tag for stable@] (CVE-2026-64285)

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

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

  - exfat：exfat_find_dir_entry（） 中綁定的 uniname 前進 在 exfat_find_dir_entry（） 中，每個 TYPE_EXTEND （檔案名稱） 項目都會將輸出指標提前固定數量，而迴圈保護僅追蹤累積的名稱長度： if （++order == 2） uniname = p_uniname->name;否則 uniname += EXFAT_FILE_NAME_LEN;len = exfat_extract_uni_name（ep， entry_uniname）;name_len += len;unichar = *（uniname+len）;*（uniname+len） = 0x0;uniname 每個名稱項目會增加 EXFAT_FILE_NAME_LEN （15），但name_len只會增加實際擷取的長度，當名稱片段包含早期 NUL 時，長度會更短。唯一的保護是「name_len >= MAX_NAME_LENGTH」，因此具有許多短名稱片段的特製目錄會讓 uniname 遠遠超出 p_uniname->name[MAX_NAME_LENGTH + 3] 緩衝區，而 name_len 保持較小，從而導致 *（uniname+len） 處的越界讀取和寫入。同級擷取器 exfat_get_uniname_from_ext_entry（） 已在短片段上停止 （提交 d42334578eba 中新增的鎖定步驟 'len ！= EXFAT_FILE_NAME_LEN' 保護 （exfat：檢查檔案名稱項目是否超過最大檔案名稱長度））;exfat_find_dir_entry（） 從未得到過等效的。將每個項目的寫入位移追蹤為計數，並在位移或位移加上擷取的長度超過 MAX_NAME_LENGTH 時拒絕片段，然後再形成輸出指標。（CVE-2026-64296）

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

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

  - SMB： 用戶端：修正 query_info（） 重播雙重釋放 回應嘗試可能會傳回可重播的錯誤，並釋放其回應緩衝區。如果 SMB2_query_info_init（） 在下次傳送之前失敗，則清理會保留先前的緩衝區類型，並再次釋放該回應。每次嘗試前重設回應簿記，以防止無效釋放。(CVE-2026-64386)

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

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

  - USB：serial：digi_acceleport：修正寫入緩衝區損毀 digi_write_inb_command（） 應該等待寫入 urb 可用或傳回錯誤，但它會更新傳輸緩衝區，並嘗試在逾時時重新提交 urb。更糟糕的是，對於不使用逾時的中斷控制等命令，驅動程式會因為 jiffies 比較中斷而立即損壞 urb（在 32 位元機器上，由於INITIAL_JIFFIES，這需要五分鐘的正常運作時間才能觸發）。修正此問題，方法是新增逾時時遺失的返回，並在未如預期指定逾時時無限期等候。
    此問題（在某種程度上）是由 Sashiko 在審查驅動程式的不相關變更時標記的。
    (CVE-2026-64333)

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

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

  - 輸入：iforce - 綁定設備報告的強制反饋效應指數 iforce_process_packet（） 通過直接從設備線獲取強制反饋效應指數並使用它來處理每個效果狀態陣列來處理狀態報告（數據包 ID 0x02）：i = data[1] &; 0x7f;if （data[1] &; 0x80） { if （！test_and_set_bit（FF_CORE_IS_PLAYED， iforce->core_effects[i].flags）） ... }， else if （test_and_clear_bit（FF_CORE_IS_PLAYED， iforce->core_effects[i].flags）） { ... }索引僅用 0x7f遮罩，因此範圍為 0..127，但 core_effects[] 僅包含 IFORCE_EFFECTS_MAX （32） 個項目。對於索引 32..127，test_and_set_bit（）/test_and_clear_bit（） 是越過陣列的越界單位讀取-修改-寫入。 core_effects[] 是結構 iforce 的倒數第二個成員，因此寫入位於尾隨成員中，並且超出嵌入 kzalloc（） 的 iforce_serio / iforce_usb 物件。 data[1] 是兩種傳輸 （USB 中斷端點和 SERIO） 上未經驗證的裝置負載，並且狀態路徑不會在存在強制回饋時進行門控，因此惡意或仿冒裝置可以在攻擊者選擇的偏移量處設定或清除超過物件的位移。拒絕超出範圍的索引，而不是使用它進行索引。
    針對陣列維度 IFORCE_EFFECTS_MAX 而不是 dev->ff->max_effects 繫結，因此無論裝置註冊多少效果，檢查都會保證記憶體安全性。合法效果已啟動/已停止狀態的索引一律低於 IFORCE_EFFECTS_MAX，因此格式正確的裝置不會受到影響;鄰近的 mark_core_as_ready（） 迴圈已有界，且保持不變。
    (CVE-2026-64273)

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

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

  - PCI： altera： 修正探查失敗時的資源洩漏 鏈結的 IRQ 處理常式是在探測期間設定的，但只會在驅動程式 remove（） 期間移除。如果 pci_host_probe（） 失敗，則即使釋放包含結構altera_pcie的 devm 管理主機橋接器儲存體，處理常式和 INTx IRQ 網域仍會保持設定狀態，讓處理常式留下過時的資料指標。在呼叫 pci_host_probe（） 之前也會啟用中斷。如果探查在該點之後失敗，則在移除鏈結處理常式和 INTx 網域之前，應該先停用控制器中斷來源。因此，只有在建立 INTx 網域之後，才能設定鏈結處理常式。在 IRQ 拆卸期間停用控制器中斷，並在 pci_host_probe（） 失敗時拆除 IRQ 設定。[mani：提交日誌]（CVE-2026-64462）

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

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

  - crypto： qat - 驗證 RSA CRT 元件長度 通用 RSA 金鑰剖析器 （rsa_helper.c） 會依模數大小 n_sz 來界定每個 CRT 元件 （p、q、dp、dq、qinv），但 qat_rsa_setkey_crt（） 會配置半大小的 DMA 緩衝區 （key_sz / 2） ，並將每個元件與以下元件右對齊： memcpy（dst + half_key_sz - len， src， len） 當 CRT 元件大於 half_key_sz 時，減法會下溢，memcpy 會寫入 DMA 緩衝區， 造成記憶體損毀。在五個 CRT 元件的現有 ！len 檢查旁邊新增 len > half_key_sz檢查，讓驅動程式回復至非 CRT 路徑，而不是寫入越界。
    (CVE-2026-64304)

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

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

  - HID：letsketch：在驅動程式解除綁定時修正 inrange_timer 上的 UAF letsketch_driver不提供 .remove 回呼，但 letsketch_probe（） 會為每個裝置配備計時器：timer_setup（&data->inrange_timer， letsketch_inrange_timeout， 0）;計時器從 letsketch_raw_event（） 重新武裝，每個筆在範圍內報告上都有 100 毫秒的逾時，其回呼會解除參照資料>input_tablet，以提供合成BTN_TOOL_PEN版本。letsketch_data 使用 devm_kzalloc（） 分配，其input_dev欄位透過 letsketch_setup_input_tablet（） 進行 devm 分配。在裝置解除繫結 （USB 拔拔或 rmmod） 時，HID 核心會執行其預設拆卸，而 devm 清除會釋放 letsketch_data 和輸入裝置。因為不存在 .remove 回呼，所以不會先耗盡計時器：如果raw_event在解除綁定的 ~100 毫秒內武裝它，則擱置計時器會在釋放的記憶體上觸發。這是對資料和資料>input_tablet的 UAF 讀取，然後將 input_report_key（） / input_sync（） 讀取到釋放的input_dev中。探查錯誤路徑上也可能出現相同的問題：如果 hid_hw_start（） 在 always-poll-quirk 裝置上啟用 I/O 然後失敗，則 raw_event 可能在 devm 釋放資料之前布防計時器。透過新增先呼叫 hid_hw_stop（） 的 .remove 回呼來修正。hid_hw_stop（） 會同步終止傳遞 raw_event（） 的 URB，因此一旦傳回，任何路徑都無法重新布防計時器。然後，timer_shutdown_sync（） 會清空任何進行中的回呼，並永久停用進一步的 mod_timer（） 呼叫。在探查錯誤路徑中套用相同的 timer_shutdown_sync（），以保證計時器不會超過資料。（CVE-2026-64365）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exits Move the handling of fastpath userspace exits into vendor code to ensure KVM runs vendor specific operations that need to run before userspace gains control of the vCPU.
    E.g. for VMX (and soon to be for SVM as well), KVM needs to flush the PML buffer prior to exiting to userspace, otherwise any memory written by the final KVM_RUN might never be flagged as dirty. Note, waiting to snapshot CR0 and CR3 until svm_handle_exit() is flawed in general, as that risks consuming stale state in a fastpath handler. That will be addressed in a future change. (CVE-2026-64284)

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

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

  - fuse：在從 fuse_ref_folio（） 返回之前重新鎖定請求 fuse_ref_folio（） 解鎖請求，但在返回之前不會重新鎖定它。fuse_chan_abort（） 可以結束請求，非同步結束回呼（例如 fuse_writepage_free（））可以釋放參數，而 fuse_ref_folio（） 之後的後續複製鏈邏輯存取它們，從而導致釋放後使用問題。透過在返回之前將請求鎖定在 fuse_ref_folio（） 中來解決此問題。（CVE-2026-64266）

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

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

  - hfs/hfsplus：當 is_bnode_offset_valid（） 失敗或 check_and_correct_requested_ length（） 將長度更正為零時，hfs_bnode_read hfs_bnode_read（） 中的零初始化緩衝區可以提前返回，而不寫入輸出緩衝區。hfs_bnode_read_ u16（） 和 hfs_bnode_read_u8（） 等呼叫端會傳遞堆疊配置的緩衝區，並無條件地使用結果，導致 KMSAN uninit-value 報告。不要在每個個別呼叫站點初始化，而是在任何驗證檢查之前，在 hfs_bnode_read（） 的開頭將緩衝區歸零。這可確保 hfs 和 hfsplus 中的所有呼叫端都獲得確定性零值，無論採用哪種提前返回路徑。（CVE-2026-64360）

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

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

  - iio： event：修正事件 FIFO 重設爭用「iio_event_getfd（）」會建立具有「anon_inode_getfd（）」的事件檔案描述元，該描述元會配置新的 fd，建立匿名檔案並將其安裝在處理程序 fd 表中，然後再傳回給呼叫端。IIO 程式碼在 'anon_inode_getfd（）' 傳回之後，但在 'IIO_GET_EVENT_FD_IOCTL' 將 fd 編號複製到使用者空間之前，會重設事件 FIFO。但是由於 fd 表是在執行緒之間共用的，因此另一個執行緒可以猜測新分配的 fd 編號，並在安裝 fd 後立即對其發出「read（）」。這意味著「iio_event_chrdev_read（）」中的「kfifo_to_user（）」可以與「iio_event_getfd（）」中的「kfifo_reset_out（）」並行執行。kfifo 文件說，「kfifo_reset_out（）」只有在從讀取器執行緒呼叫並且只有一個並發讀取器時才是安全的。否則是危險的，必須以與「kfifo_reset（）」相同的方式處理。如果發生這種情況，'kfifo_to_user（）' 可以根據重設前的狀態推進 FIFO 'out' 索引，在重設已經將 'out' 索引移至目前的 'in' 索引之後。這可能會使 FIFO 的「out」指數超過「in」指數。然後，稍後的「read（）」可以看到反向溢位的 FIFO 長度，並複製比事件 FIFO 緩衝區包含的資料更多。這可能會導致越界讀取並將鄰近核心記憶體洩漏到使用者空間。將 FIFO 重設移至 'anon_inode_getfd（）' 之前。此時，事件 fd 被標記為忙碌，但尚未安裝新的 fd，因此當 FIFO 重設時，使用者空間無法存取它。
    (CVE-2026-64496)

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

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

  - 已解決 Linux 核心中的下列弱點：HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo doesn't have enough space for the incoming report. If the kfifo is empty, kfifo_skip() reads stale data left in the kmalloc'd buffer via __kfifo_peek_n() and interprets it as a record length, advancing fifo->out by that garbage value. This corrupts the internal kfifo state, causing kfifo_unused() to return a value much larger than the actual buffer size, which bypasses __kfifo_in_r()'s guard: if (len + recsize > kfifo_unused(fifo)) return 0; kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to 3842 bytes past the 256-byte buffer. Add a !kfifo_is_empty() condition to the while loop so kfifo_skip() is never called on an empty fifo, and check the return value of kfifo_in() to reject reports that are too large for the fifo. (CVE-2026-64366)

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

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

  - 已解決 Linux 核心中的下列弱點：i2c: imx-lpi2c: mark I2C adapter when hardware is powered down On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available. (CVE-2026-64278)

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

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

  - SMB： client：修正 SMB2_ioctl（） 重播中的雙重釋放 具有回應的嘗試可能會傳回可重播的錯誤並釋放其回應緩衝區。如果 SMB2_ioctl_init（） 在下次傳送之前失敗，清理會保留先前的緩衝區類型，並再次釋放該回應。每次嘗試前重設回應簿記，以防止無效釋放。(CVE-2026-64385)

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

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

  - firmware_loader：修正 firmware_upload_register（） firmware_upload_register（） -> fw_create_instance（） -> device_initialize（） 中的裝置參照洩漏 fw_create_instance（） 成功後，內嵌結構裝置的生命週期應透過裝置核心參照計數進行管理，因為 fw_create_instance（） 已呼叫 device_initialize（） 。在firmware_upload_register（）中，如果fw_create_instance（）成功後alloc_lookup_fw_priv（）失敗，則程式碼到達free_fw_sysfs並直接釋放fw_sysfs，而不是使用put_device（）釋放裝置參照。這可能會使內嵌結構裝置的參照計數不平衡，進而導致參照計數洩漏。該問題是由我開發的靜態分析工具發現的，並通過人工審查確認。在失敗路徑中使用 put_device（fw_dev） 並讓 fw_dev_release（） 處理最終清除，而不是直接從錯誤路徑釋放執行個體，以修正此問題。（CVE-2026-64376）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case. Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer. Solve this by introducing a new iterator built on top of the usual kvm_for_each_vcpu() that checks for both of the above conditions, and convert the two users to it. (CVE-2026-64288)

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

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

  - HID： logitech-dj： 修正 DJ 短報驗證中的 maxfield 簽入 提交 b6a57912854e （HID： logitech-dj：
    防止REPORT_ID_DJ_SHORT相關使用者啟動 OOB 寫入） 已新增 DJ 短輸出報告的驗證，但即使 rep->maxfield 為零，錯誤路徑也會解除參照 rep->field[0]。提交 8b9a097eb2fc （HID：logitech-dj：修正錯誤偵測不良DJ_SHORT輸出報告） 使檢查以 rep 存在為條件，但特製的描述元仍然可以建立僅包含填充輸出項目的報告 ID 0x20。
    hid-core 會註冊報告，忽略填充欄位，並將 rep->maxfield 保留為零。在此情況下，驗證會< 1 分支輸入 rep->maxfield，然後在列印錯誤訊息時取消參照 rep->field[0]->report_count，在探測期間造成 NULL 指標解除參照。這可以透過模擬具有僅填充 DJ 短輸出報告的羅技接收器來使用 uhid 重現： 錯誤：KASAN：logi_dj_probe+0xb1/0x754 中的 null-ptr-deref [hid_logitech_dj] 任務 kworker/4:1/129 在 addr 0000000000000028 讀取大小 4 ... 通話追蹤：logi_dj_probe+0xb1/0x754 [hid_logitech_dj] hid_device_probe+0x329/0x3f0 [HID] really_probe+0x162/0x570 __device_attach+0x137/0x2c0 bus_probe_device+0x38/0xc0 device_add+0xa56/0xce0 hid_add_device+0x19c/0x280 [HID] uhid_device_add_worker+0x2c/0xb0 [uhid] 在列印欄位report_count之前拒絕零欄位報告。（CVE-2026-64427）

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

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

  - KVM： guest_memfd：將記憶體插槽繫結位移量+大小視為無符號值 將記憶體插槽繫結至guest_memfd檔時，請將位移量和大小視為無符號值，以修正在針對檔案大小檢查溢位時，兩者之和可能導致漏報的錯誤。傳遞無符號值也可避免依賴其他流程中有些模糊的檢查以確保安全，並將偏移和大小追蹤為未帶正負號的值。在 64 位元核心上，記憶體插槽包含的頁數及其guest_memfd綁定的大小（和位移量）是無符號的 64 位元值。
    如果位移和/或大小很大，則將位移+大小作為loff_t而不是uoff_t，會無意中將未帶正負號的值轉換為帶正負號的值。將偏移和大小本地存儲為帶正負號的值本身是良性的（儘管即使這樣也*極其*難以辨別），但對它們的總和進行操作則不然。對於偏移量，KVM 會明確地檢查負值，這似乎是一個錯誤，因為 KVM 可能會錯誤地拒絕合法的綁定，但實際上情況並非如此，因為 KVM_CREATE_GUEST_MEMFD 的大小採用帶正負號的值，即可能為負的偏移量也大於任何guest_memfd檔案的最大可能大小。關於大小，雖然 KVM 缺乏對負值的明確檢查，即似乎有缺陷的溢位檢查，但 KVM 將單個 memslot 中的頁數限制為最大的正負號 32 位值：if （id < KVM_USER_MEM_SLOTS & （mem->memory_size >> PAGE_SHIFT） > KVM_MEM_MAX_NR_PAGES） return -EINVAL;因此，最大尺寸將永遠是0x7fffffff000。然而，兩者的總和是有問題的。雖然大小受到 KVM 內嵌槽邏輯的限制，但偏移量卻不受限制，即在偏移量 + 大小 > i_size_read（inode） 檢查之前，偏移量完全未檢查。如果位移是 （幾乎） 最大可能的 _正_ 值，則將大小新增至位移可能會導致帶正負號的負 64 位值。當與檔案大小（保證為正數）進行比較時，負總和總是較小，並且 KVM 錯誤地允許荒謬的偏移量。機會主義地在 kvm_mm.h 中新增缺少的包含 （而不是依賴其父項）。
    (CVE-2026-64283)

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

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

  - iio：緩衝區：hw-consumer：緩衝區釋放時釋放scan_mask 提交 9a2e1233d38c 中的scan_mask存留期已變更 （iio：緩衝區：hw-consumer：移除冗餘scan_mask彈性陣列）。在該更改之前，掃描遮罩存儲嵌入在結構hw_consumer_buffer中，因此 iio_hw_buf_release（） 可以使用單個 kfree（hw_buf） 釋放整個分配。該提交將掃描遮罩移動到儲存在 buffer.scan_mask 中的單獨 bitmap_zalloc（） 分配，但保持 iio_hw_buf_release（） 不變。在釋放緩衝區包裝函式之前，先釋放 iio_hw_buf_release（） 中的掃描遮罩。（CVE-2026-64498）

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

ID	名稱	嚴重性
329826	Linux Distros 未修補弱點：CVE-2026-64529	high
329825	Linux Distros 未修補弱點：CVE-2026-64453	high
329824	Linux Distros 未修補弱點：CVE-2026-64388	high
329823	Linux Distros 未修補弱點：CVE-2026-64292	medium
329822	Linux Distros 未修補弱點：CVE-2026-64392	critical
329821	Linux Distros 未修補弱點：CVE-2026-64361	high
329820	Linux Distros 未修補弱點：CVE-2026-64405	medium
329819	Linux Distros 未修補弱點：CVE-2026-64370	medium
329818	Linux Distros 未修補弱點：CVE-2026-64507	medium
329817	Linux Distros 未修補弱點：CVE-2026-64312	high
329816	Linux Distros 未修補弱點：CVE-2026-64339	high
329815	Linux Distros 未修補弱點：CVE-2026-64320	critical
329814	Linux Distros 未修補弱點：CVE-2026-64487	medium
329813	Linux Distros 未修補弱點：CVE-2026-64357	medium
329812	Linux Distros 未修補弱點：CVE-2026-64417	medium
329811	Linux Distros 未修補弱點：CVE-2026-64489	medium
329810	Linux Distros 未修補弱點：CVE-2026-64433	high
329809	Linux Distros 未修補弱點：CVE-2026-64350	medium
329808	Linux Distros 未修補弱點：CVE-2026-64443	high
329807	Linux Distros 未修補弱點：CVE-2026-64485	high
329806	Linux Distros 未修補弱點：CVE-2026-64322	high
329805	Linux Distros 未修補弱點：CVE-2026-64398	high
329804	Linux Distros 未修補弱點：CVE-2026-64301	medium
329803	Linux Distros 未修補弱點：CVE-2026-64258	medium
329802	Linux Distros 未修補弱點：CVE-2026-64414	high
329801	Linux Distros 未修補弱點：CVE-2026-64387	critical
329800	Linux Distros 未修補弱點：CVE-2026-64291	medium
329799	Linux Distros 未修補弱點：CVE-2026-64500	medium
329798	Linux Distros 未修補弱點：CVE-2026-64379	high
329797	Linux Distros 未修補弱點：CVE-2026-64409	medium
329796	Linux Distros 未修補弱點：CVE-2026-64285	medium
329795	Linux Distros 未修補弱點：CVE-2026-64296	high
329794	Linux Distros 未修補弱點：CVE-2026-64386	critical
329793	Linux Distros 未修補弱點：CVE-2026-64333	high
329792	Linux Distros 未修補弱點：CVE-2026-64273	high
329791	Linux Distros 未修補弱點：CVE-2026-64462	medium
329790	Linux Distros 未修補弱點：CVE-2026-64304	high
329789	Linux Distros 未修補弱點：CVE-2026-64365	high
329788	Linux Distros 未修補弱點：CVE-2026-64284	high
329787	Linux Distros 未修補弱點：CVE-2026-64266	high
329786	Linux Distros 未修補弱點：CVE-2026-64360	medium
329785	Linux Distros 未修補弱點：CVE-2026-64496	high
329784	Linux Distros 未修補弱點：CVE-2026-64366	high
329783	Linux Distros 未修補弱點：CVE-2026-64278	medium
329782	Linux Distros 未修補弱點：CVE-2026-64385	critical
329781	Linux Distros 未修補弱點：CVE-2026-64376	medium
329780	Linux Distros 未修補弱點：CVE-2026-64288	medium
329779	Linux Distros 未修補弱點：CVE-2026-64427	medium
329778	Linux Distros 未修補弱點：CVE-2026-64283	high
329777	Linux Distros 未修補弱點：CVE-2026-64498	medium

偵測

Nessus 的 Misc. 系列

high

high

high

medium

critical

high

medium

medium

medium

high

high

critical

medium

medium

medium

medium

high

medium

high

high

high

high

medium

medium

high

critical

medium

medium

high

medium

medium

high

critical

high

high

medium

high

high

high

high

medium

high

high

medium

critical

medium

medium

medium

high

medium