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

  - ksmbd：新增 FSCTL_DUPLICATE_EXTENTS_TO_FILE 的權限檢查 smb2_ioctl（） 的FSCTL_DUPLICATE_EXTENTS_TO_FILE臂透過 vfs_clone_file_range（） 覆寫目的地檔案的資料，既沒有共用層級KSMBD_TREE_CONN_FLAG_WRITABLE檢查，也沒有其他寫入承載臂所攜帶的每個控制點 fp->daccess 檢查。用戶端可以覆寫唯讀共用上的目的地資料，或僅以 FILE_WRITE_ATTRIBUTES 開啟的控點 （仍會產生FMODE_WRITE filp）。FILE_WRITE_ATTRIBUTES-only 目的地控制碼透過複製覆寫了檔案的資料。新增兩項檢查，以符合FSCTL_SET_SPARSE權限修正;需要FILE_WRITE_DATA，因為這會寫入資料。（CVE-2026-64399）

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

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

  - 輸入：mms114 - 拒絕過大的裝置封包大小 mms114_interrupt（） 會將觸控資料封包從裝置讀取到固定大小的堆疊緩衝區結構中，mms114_touch touch[MMS114_MAX_TOUCH];它保存 MMS114_MAX_TOUCH （10） 個 MMS114_EVENT_SIZE （8） 位元組的事件，即 80 位元組。從設備逐字讀取的 I2C 長度：packet_size = mms114_read_reg（數據，MMS114_PACKET_SIZE）;if （packet_size <= 0） goto out;...錯誤 = __mms114_read_reg（data， MMS114_INFORMATION， packet_size， （u8
    *）觸摸）;packet_size是單個設備暫存器位元組 （0x0F），唯一的檢查是下限 packet_size <= 0;它永遠不會受到 touch[] 大小的限制。故障、惡意或偽造的控制器（或篡改 I2C 匯流排的攻擊者）可以報告高達 255 的packet_size，因此 __mms114_read_reg（） 在 IRQ 執行緒堆疊上寫入最多 175 個位元組超過 touch[] 結束：堆疊越界寫入，可以覆蓋堆疊金絲雀、已儲存的暫存器和傳回位址。格式正確的裝置永遠不會報告超過緩衝區保留的數量，因此請拒絕過大的封包並捨棄報告，這與處理常式的其他錯誤路徑一致，而不是讀取緩衝區。（CVE-2026-64270）

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

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

  - ksmbd：將 WRITE_DAC/WRITE_OWNER 檢查新增至 SMB2 SET_INFO SECURITY 提交 cc57232cae23 （ksmbd：透過新增 FSCTL_SET_SPARSE 的權限檢查來修正 FSCTL 權限繞過） 向 fsctl_set_sparse 新增了 FP->DACCESS 閘道，並指出其他函式中也存在類似的控點層級檢查，但此處缺少。SMB2 SET_INFO SECURITY 部門是缺少的部門之一，也是與安全性最相關的部門：
    smb2_set_info_sec（） 呼叫 set_info_sec（），但沒有每個控制碼的存取檢查。set_info_sec（） （fs/smb/server/smbacl.c） 重新授權該檔案：它透過 notify_change（） 重寫所有者/群組/模式，透過 set_posix_acl（） 重寫 POSIX ACL，並在 KSMBD_SHARE_FLAG_ACL_XATTR 共用上透過 ksmbd_vfs_set_sd_xattr（） 移除並重寫 Windows 安全性描述元。同級處理常式 smb2_set_info_file（） 的所有其他持久性突變臂都會先檢查 fp->daccess （FILE_WRITE_DATA / FILE_DELETE / FILE_WRITE_EA / FILE_WRITE_ATTRIBUTES）;改變存取控制本身的 SECURITY 臂是唯一沒有閘門的臂。因此，用戶端可以僅使用 FILE_WRITE_ATTRIBUTES （無 FILE_WRITE_DAC / FILE_WRITE_OWNER） 開啟控點，並搭配 InfoType SMB2_O_INFO_SECURITY 使用 SMB2_SET_INFO 來重寫檔案的 DACL 和所有者，從而授予自己從未攜帶過控點 daccess 的存取權。與 FSCTL 資料臂不同，這是一個元資料/xattr 操作，因此沒有FMODE_WRITE VFS 備份，缺少的 fp->daccess 檢查是整個閘門。設定安全性描述元是WRITE_DAC/WRITE_OWNER作業，因此在重新許可檔案之前，至少需要控制碼上的其中一個描述元。-EACCES 會透過 smb2_set_info（） 對應至 STATUS_ACCESS_DENIED。（CVE-2026-64394）

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

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

  - 6lowpan：修正錯誤路徑上的 NHC 項目釋放後使用 lowpan_nhc_do_uncompression（） 在按住 lowpan_nhc_lock 時查詢 NHC 描述元。如果描述元沒有解壓縮回呼，則錯誤路徑會在列印 nhc->name 之前捨棄鎖定。lowpan_nhc_del（） 會移除相同鎖定下的描述元，然後依賴 synchronize_net（），然後才能卸載所屬模組。這只等待淨 RX RCU 讀取器。lowpan_header_decompress（） 也會匯出，並且可以從網路核心 RX 關鍵區段不一定涵蓋的呼叫端存取，例如藍牙 6LoWPAN L2CAP 接收路徑。這會留下爭用，其中一項任務將lowpan_nhc_lock丟棄在錯誤路徑中，另一項任務在 synchronize_net（） 傳回後取消註冊並釋放相符的描述元，然後第一個任務取消參照 nhc->name 以發出警告。隨著解鎖後視窗的擴大，KASAN 報告： 錯誤：KASAN：大小為 8 lowpan_nhc_do_uncompression lowpan_header_decompress 的 lowpan_nhc_do_uncompression+0x1f4/0x220 讀取中的 slab-use-after-free 來修正lowpan_nhc_lock此問題，以便在仍排除取消註冊時讀取描述元名稱。格式錯誤的封包仍會以
    -伊諾薩普。（CVE-2026-64452）

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

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

  - 已解決 Linux 核心中的下列弱點：fuse: avoid 32-bit prune notification count wrap FUSE_NOTIFY_PRUNE validates the nodeid payload length with: size - sizeof(outarg) != outarg.count * sizeof(u64) On 32-bit kernels, size_t is also 32 bits, so the daemon-controlled count multiplication can wrap. A prune notification with count 0x20000000 and no nodeid payload passes the check, enters the copy loop, and asks the device copy path to read nodeids that are not present in the userspace write buffer. In QEMU this reaches the fuse_copy_fill() BUG_ON(!err) path. Validate the payload length with array_size() instead. That accepts exactly the same valid messages, but avoids wrapping arithmetic before the copy loop consumes the count. (CVE-2026-64267)

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

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

  - 藍牙：ISO：避免 iso_conn_big_sync（） 中 conn 的 NULL 解除參照 iso_conn_big_sync（） 會刪除通訊端鎖定以呼叫 hci_get_route（），然後重新取得它，但之後取消參照 iso_pi（sk）->conn->hcon，而不重新檢查 conn 是否仍然有效。當鎖定被刪除時，可以在相同的通訊端鎖定下斷開連接：iso_disconn_cfm（） -> iso_conn_del（） -> iso_chan_del（） 將 iso_pi（sk）->conn 設定為 NULL（並且廣播拆卸路徑也可以自行清除 conn->hcon）。當 iso_conn_big_sync（） 重新取得鎖定並讀取 conn->hcon 時，conn 可能是 NULL，導致 NULL 指標解除參照 （hcon 是 struct iso_conn） 的第一個成員。此路徑可從 PA 同步廣播接收通訊端的 iso_sock_recvmsg（） 連線 （BT_SK_DEFER_SETUP |BT_SK_PA_SYNC），因此卸除鎖定視窗可能會與控制器事件所驅動的連線中斷爭用。重新取得通訊端鎖定後，重新驗證 iso_pi（sk）->conn 及其 hcon，並在連線消失時退出，就像在同級 iso_sock_rebind_bc（） 中已經完成的那樣。
    (CVE-2026-64404)

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

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

  - KVM：x86：在 PPR 更新時無條件重新計算 CR8 攔截 當客體的虛擬 TPR 低於指定臨界值時，VMX 會使用 VMCS 中的 TPR_THRESHOLD 欄位來誘導 VM 退出，從而允許 KVM 插入先前遮罩的中斷。KVM 會在 handle_tpr_below_threshold（） 中處理這些 VM 結束。
    提交 eb90f3417a0c （KVM： vmx：將 TPR 加速到閾值 vmexits 以下） 透過呼叫 apic_update_ppr（） 而不是引發 KVM_REQ_EVENT 來最佳化此函式。然後，apic_update_ppr（） 如果存在擱置中的可交付中斷，則會引發KVM_REQ_EVENT。但是，如果沒有新的中斷擱置中，則 apic_update_ppr（） 不會發出要求。因此，在 VM 進入之前不會呼叫 kvm_lapic_update_cr8_intercept（） 和 vmx_update_cr8_intercept（），這會導致高TPR_THRESHOLD過時。這是有問題的，因為SDM中的VM執行控制欄位中有 28.2.1.1 以下句子：如果使用TPR影子VM執行控制為1，而虛擬化APIC訪問和虛擬中斷傳遞VM執行控制均為0，則執行以下檢查：TPR閾值VM執行控制欄位的位 3:0 值不應大於VTPR的位值 7:4 。當 KVM 在裸機系統上執行時，通常不會觀察到此錯誤狀況，因為現代處理器支援 APICv，可啟用虛擬中斷傳遞，並且 KVM 會盡可能使用。這會導致處理器不再產生低於臨界值的 TPR 結束，也不再在進入時檢查TPR_THRESHOLD。但是，當在較舊的平台上執行時，或在不支援虛擬中斷傳遞並強制執行此檢查的虛擬化管理程式（例如 Hyper-V）上的巢狀虛擬化下執行時，這可能會導致 VM 進入失敗並0x7硬體錯誤，如 [1] 所示。如果 apic_update_ppr（） 找不到可交付的中斷 （因此不會引發 KVM_REQ_EVENT），則呼叫 kvm_lapic_update_cr8_intercept（）。移除以 apic_update_ppr（） 結束的路徑上對 kvm_lapic_update_cr8_intercept（） 的呼叫，因為它們現在會變得多餘。
    如此可確保任何更新客體 PPR 的路徑也會判斷 KVM 是否需要等待 TPR 變更 （在 VMX 上使用 TPR_THRESHOLD 或在 SVM 上攔截 CR8）。（CVE-2026-64513）

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

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

  - hwrng： virtio：在 copy_data（） 處 clamp device-reported used.len random_recv_done（） 會將裝置報告的 used.len 直接儲存到 vi->data_avail 中。然後，copy_data（） 使用 vi->data_idx （由先前的 copy_data（） 呼叫推進） 索引 vi->data[]，並發出 memcpy（），而無需根據張貼的緩衝區大小 sizeof（vi->data） （SMP_CACHE_BYTES 位元組，通常為 32 或 64） 重新驗證任一值。惡意或有錯誤的 virtio-rng 後端可以將 used.len 設定到 sizeof（vi->data） 之外，將 memcpy（） 引導到內嵌陣列的末尾進入相鄰的 kmalloc-1k slab 位元組。hwrng_fillfn（） 將這些位元組混合到客體 RNG 中，客體 root 也可以直接透過 /dev/hwrng 觀察它們。具體影響在客體內部：- 記憶體安全/強化：任何過度報告 used.len 的 virtio-rng 後端都會導致驅動程式將過去的 vi->data 讀取到不相關的 slab 內容中。hwrng_fillfn（） 是一個核心執行緒，一旦探測裝置就會運行;不需要客體使用者空間互動即可首次觸發 OOB。- 跨境洩漏 （機密運算威脅模型）：與惡意或遭入侵的客體根使用者空間合作的惡意虛擬化管理程式可以使用 /dev/hwrng 作為客體核心堆積資料的洩漏通道。主機設定一個大的 used.len，客體根目錄讀取 /dev/hwrng，傳回的位元組包含與 vi->data 相鄰的客體核心 slab 內容。實際上，機密計算客體 （SEV-SNP、TDX） 通常會完全停用 virtio-rng，因此此路徑很窄，但該修復仍然值得攜帶，因為基礎記憶體安全錯誤會污染任何主機上的客體 RNG。KASAN 確認 7.1-rc4 客體上的 OOB，其 virtio-rng 後端已修補以報告 used.len = 0x10000： 錯誤： KASAN：virtio_read+0x394/0x5d0 中的 slab-out-of-bounds 由任務 hwrng/52 在 addr ffff88800ae0ba20 讀取大小 64 呼叫追蹤：__asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 由任務 1 分配：
    probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 錯誤位址屬於 ffff88800ae0b800 處的物件，該物件屬於大小為 1024 的快取 kmalloc-1k 錯誤位址位於分配的 544 位元組區域右側 0 位元組處 [ffff88800ae0b800， ffff88800ae0ba20） 與提交 c04db81cd028 相同類別的錯誤 （net/9p：修正 USB 傳輸層中的緩衝區溢位）， 這針對 USB 9p 傳輸中未檢查的裝置報告長度強化了 usb9pfs_rx_complete（）。在使用點使用夾具並放置 array_index_nospec（） 後，相同的線束會乾淨地啟動：copy_data（） 會針對虛假報告傳回零，data_idx後裝置提供的位元組會遭到捨棄，驅動程式會發出新的要求。
    (CVE-2026-64456)

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

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

  - coresight：ultrasoc-smb：修正 smb_sync_perf_buffer（） 中的 OOB 寫入當 SMB 接收器用作 perf AUX 接收器時，smb_update_buffer（） 會呼叫 smb_sync_perf_buffer（） 將硬體追蹤資料複製到效能 AUX 環形緩衝區頁面。它從 @head 派生 pg_idx = head >> PAGE_SHIFT，即 handle->head，並索引 dst_pages[pg_idx]。pg_idx %= nr_pages正規化只會在第一次迴圈反覆運算之後套用。
    這會使初始頁面索引未從緩衝區大小衍生，當磁頭超過 AUX 緩衝區大小時，可能會導致越界寫入。dst_pages[] 在派生頁面索引和偏移量之前，將頭模 AUX 緩衝區大小標準化，鏡像 tmc_etr_sync_perf_buffer（）。（CVE-2026-64402）

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

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

  - netfilter： ebtables：在 find_table_lock（） 之前終止表名 update_counters（） 和 compat_update_counters（） 將使用者提供的 32 位元組表名轉送至 find_table_lock（），而無需 NUL 終止它。在查閱未命中時，find_inlist_lock（） 會呼叫 try_then_request_module（...， %s%s， ebtable_， name），而 vsnprintf（） 會讀取 name 欄位和堆疊物件，直到它達到零位元組為止。錯誤：KASAN：字串中的堆疊越界 （lib/vsprintf.c：648 lib/vsprintf.c：730） 透過任務 exploit/147 在 addr ffff8880119dfb20 讀取大小 1 呼叫追蹤：...字串 （lib/vsprintf.c：648， lib/vsprintf.c：730） vsnprintf （lib/vsprintf.c：2945） __request_module （kernel/module/kmod.c：150） do_update_counters.isra.0 （net/bridge/netfilter/ebtables.c：371， net/bridge/netfilter/ebtables.c：380） update_counters （net/bridge/netfilter/ebtables.c：1440） do_ebt_set_ctl （net/bridge/netfilter/ebtables.c：2573） nf_setsockopt （net/netfilter/nf_sockopt.c：101） ip_setsockopt （net/ipv4/ip_sockglue.c：1424） raw_setsockopt （net/ipv4/raw.c：847） __sys_setsockopt （net/socket.c：2393） ...compat_do_replace（） 透過 compat_copy_ebt_replace_from_user（） 共用相同的未終止名稱;也在那裡終止它，以便所有 find_table_lock（） 呼叫者的行為都相似。其他呼叫端已經在複製之後終止名稱。CVE-2026-64411

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

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

  - 輸入：elan_i2c - 防止除以零和算術反向溢位 Elan I2C 觸控板驅動程式會查詢裝置的實體尺寸和追蹤計數，以計算裝置解析度和寬度。
    不過，如果裝置韌體或裝置樹狀結構為x_traces或y_traces提供無效的零值，則會導致嚴重的除以零例外狀況，進而導致裝置探查期間發生核心錯誤。在執行除法之前，新增檢查以確保這些參數為非零。如果偵測到無效的追蹤值，請回復為安全預設值 1。此外，防止觸控報告邏輯中的算術溢位。以前，如果計算的寬度或後援寬度小於 ETP_FWIDTH_REDUCE （90），則減法會下溢，導致向使用者空間報告大量無正負號整數。將調整後的寬度限制為最小值 0，以安全地處理小型實體維度和後援案例。
    使用安全後援值完成探查可確保建立 sysfs 節點，並保持韌體更新路徑完整，以便將復原韌體快閃記憶體到裝置。（CVE-2026-64275）

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

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

  - smb： client：修正 receive_encrypted_standard（） 中的下一個緩衝區洩漏 receive_encrypted_standard（） 在檢查複合 PDU 數量是否已達到 MAX_COMPOUND 之前分配next_buffer。如果限制檢查失敗，函數會立即傳回，並且新分配的next_buffer不會分配給 server->smallbuf/server->bigbuf，從而使其洩露。在配置next_buffer之前移動MAX_COMPOUND檢查。（CVE-2026-64381）

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

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

  - smb： client：強化 POSIX SID 長度剖析 posix_info_sid_size（） 讀取 SID[1] 以取得子授權單位計數，但其現有邊界檢查仍接受僅剩下一個位元組的緩衝區。讀取 sid[1] 之前需要兩個位元組，以便重複使用協助程式的所有用戶端路徑安全地拒絕截斷的 POSIX SID。
    (CVE-2026-64380)

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

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

  - ksmbd：修正SMB2_LOCK延遲鎖定取消中結構file_lock的 UAF 當FILE_LOCK_DEFERRED路徑中延遲阻塞位元組範圍鎖定要求時，ksmbd 會透過 setup_async_work（） 將非同步工作註冊到連線的async_requests清單中。取消回呼 smb2_remove_blocked_lock（） 會保留對羊群的參照。如果鎖定等候程式隨後被喚醒，但工作狀態不再KSMBD_WORK_ACTIVE （例如，由於並行取消） ，則清理路徑會呼叫 locks_free_lock（flock），而不會將工作從async_requests清單中除名。同時，smb2_cancel（） 遍歷 conn->request_lock 下的清單並叫用取消回呼，然後取消參照已經釋放的「flock」。這會導致內部__wake_up_common釋放後使用板。透過在背景工作者從 ksmbd_vfs_posix_lock_wait（） 返回後重組清理邏輯來修正此問題。將 list_del（&smb_lock->llist） 和 release_async_work（work） 移至清理區塊的頂端。這可確保在呼叫 locks_free_lock （flock） 之前，非同步工作會在 conn->request_lock 下完全出列並序列化，使任何並行 smb2_cancel（） 都無法連線 flock。
    (CVE-2026-64396)

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

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

  - ksmbd：在更新工作階段金鑰之前驗證 NTLMv2 回應 ksmbd_auth_ntlmv2（） 會在驗證 NTLMv2 回應之前，先將 NTLMv2 工作階段金鑰衍生至 sess->sess_key。然後，即使 ksmbd_auth_ntlmv2（） 失敗，ksmbd_decode_ntlmssp_auth_blob（） 仍會繼續進入 KEY_XCH。使用 SMB3 多通道繫結時，失敗的驗證會在現有的工作階段上運作，且工作階段設定錯誤路徑不會使繫結工作階段過期。用戶端可以傳送具有錯誤 NT 校訂和KEY_XCH的繫結工作階段設定，但仍會在傳回 STATUS_LOGON_FAILURE之前修改 sess->sess_key。相關路徑：smb2_sess_setup（） -> conn->binding = true -> ntlm_authenticate（） -> session_user（） -> ksmbd_decode_ntlmssp_auth_blob（） -> ksmbd_auth_ntlmv2（）
    -> calc_ntlmv2_hash（） -> hmac_md5_usingrawkey（...， sess->sess_key） -> crypto_memneq（） 傳回不相符的 -> KEY_XCH arc4_crypt（...， sess->sess_key， ...） -> out_err 而不使繫結工作階段過期 將基工作階段金鑰衍生到本機緩衝區中，只有在校訂相符後才將其複製到 sess->sess_key。驗證失敗時立即傳回，因此只有在驗證成功之後才會處理KEY_XCH。
    (CVE-2026-64389)

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

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

  - vfio：在釋放 devres 之前移除裝置 debugfs 使用 debugfs_create_devm_seqfile（） 建立的 VFIO 裝置 debugfs 檔案會將配置的 devres debugfs_devm_entry儲存為 inode 私有資料。
    vfio_unregister_group_dev（） 目前在 vfio_device_debugfs_exit（） 之前呼叫 vfio_device_del（），但 device_del（） 會釋放 devres。這可能會使 debugfs 項目與過時的 inode 私有資料一起可見，而取消註冊會等待使用者空間參照排空。在 vfio_device_del（） 之前移除每個裝置的 debugfs 樹狀結構。debugfs 檢視僅是診斷性，因此在取消註冊開始時遺失它比保留其備份儲存可能已釋放的項目更可取。移除之後，清除每個裝置的 debugfs 根目錄，以完成拆卸。這符合全域 debugfs 根清除，並防止未來的使用者在取消註冊的剩餘時間內將已移除的 dentry 誤認為是即時 debugfs 樹狀結構。（CVE-2026-64473）

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

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

  - netfilter：ebtables：零鏈堆疊陣列 Sashiko 報告：查看 ebtables 表轉換，稀疏cpu_possible_mask會導致未初始化的指標釋放嗎？如果 cpu_possible_mask 是稀疏的 （例如，CPU 0 和 CPU 2 是可能的，但 CPU 1 不是） ，則配置迴圈會略過 CPU 1。如果 vmalloc_node（） 在 CPU 2 處失敗，清理迴圈將盲目遞減並呼叫 newinfo->chainstack[1] 上的 vfree（）。這不是一個現實世界的錯誤，預計這種分配一開始就不會失敗。
    (CVE-2026-64413)

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

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

  - 已解決 Linux 核心中的下列弱點：rust_binder: use a u64 stride when cleaning up the offsets array Allocation's Drop walks the offsets array (binder_size_t = u64 entries), cleaning up the objects, but it used usize instead of u64 for both the stride and the per-entry read. On 64-bit kernels (usize == u64) this is harmless, but on 32-bit kernels it walks the 8-byte entries in 4-byte steps, iterating an N-entry array 2N times, and reads the always-zero high word as offset 0, cleaning up the object at offset 0 N extra times. As a result the referenced node or handle ends up with a lower reference count than it actually has (a refcount over-decrement), and binder's reference accounting is corrupted; for example, the owner can be notified of a strong reference release (BR_RELEASE) even though references still remain. Change the stride to u64, and read each entry as a u64, narrowing it to usize with try_into(). On 32-bit ARM, when this over-decrement would drive a count below zero, the driver's existing refcount guard refuses it and fires: rust_binder: Failure: refcount underflow! (CVE-2026-64467)

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

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

  - Bluetooth： bnep：netdev 註冊期間的 pin L2CAP 連線 bnep_add_connection（） 讀取 L2CAP 連線而不保留通道鎖定，然後將其 HCI 裝置傳遞至 register_netdev（）。控制器拆卸可以同時清除和釋放該連線，讓網路裝置註冊路徑取消參照釋放的父裝置。在按住通道鎖定的同時，參照 L2CAP 連線。保留它，直到 register_netdev（） 取得父裝置參照為止。（CVE-2026-64408）

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

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

  - 已解決 Linux 核心中的下列弱點：ALSA: usx2y: us144mkii: fix work UAF on disconnect tascam_disconnect() cancels capture_work and midi_in_work before usb_kill_anchored_urbs() kills the capture/MIDI-in URBs. Those URBs self-resubmit, and their completion handlers reschedule the work. A URB that completes in the small window between cancel_work_sync() and usb_kill_anchored_urbs() therefore re-arms the work after its only cancel. Nothing cancels it again before snd_card_free() frees the card-private tascam structure, so the work handler then runs on freed memory. Kill the anchored URBs before cancelling the work; once the work is cancelled no remaining URB can complete to re-arm it.
    (CVE-2026-64491)

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

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

  - RDMA/rtrs-srv：將 RDMA-Write 長度繫結為區塊大小 （以 rdma_write_sg 為單位） 當伺服器回應 RTRS READ 時，rdma_write_sg（） 會為將資料傳回給對等體的IB_WR_RDMA_WRITE建立來源分散/收集項目。其長度直接取自線路描述元：plist->length = le32_to_cpu（id->rd_msg->desc[0].len）;rd_msg指向遠端對等體透過 RDMA-WRITE-WITH-IMM （rtrs_srv_rdma_done（） -> process_io_req（） -> process_read（）） 填入的區塊緩衝區，因此 desc[0].len 受攻擊者控制，在此變更之前，只有在零時才被拒絕。來源位址是固定區塊起始 （dma_addr[msg_id]），來源 lkey 是 PD 寬local_dma_lkey，與區塊的 MR 映射無關，因此動詞層不會將傳輸長度限制為 max_chunk_size。msg_id 和 off 是針對 rtrs_srv_rdma_done（） 中的 queue_depth 和 max_chunk_size 的界限，但 desc[0].len 是一個單獨的欄位，未針對區塊大小進行檢查。通告大於 max_chunk_size 的 desc[0].len 的對等體可以使張貼的 RDMA 寫入讀取通過區塊的映射區域。產生的行為取決於 IOMMU 配置：在沒有 IOMMU 或處於直通模式的情況下，讀取可能會擴展到與區塊相鄰的記憶體並返回給對等體，這可能會洩露主機記憶體;使用轉換 IOMMU 時，超出範圍的存取預期會出錯並中止連線。在任一情況下，傳輸都超出了通訊協定允許的範圍，並且由遠端對等體驅動。拒絕超過 max_chunk_size 的描述元長度，以鏡像 rtrs_srv_rdma_done（） 中現有的 off >= max_chunk_size界限。合法用戶端不會超過它：用戶端將 desc[0].len 設定為其 MR 長度，其上限為協商的max_io_size （max_chunk_size - MAX_HDR_SIZE）。（CVE-2026-64269）

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

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

  - 暫存：rtl8723bs：修正 OnAssocRsp（） IE 迴圈中的 OOB 讀取 OnAssocRsp（） 中的 IE 剖析迴圈每次反覆運算都會前進 （pIE->length + 2），但只會保護 i < pkt_len。當惡意 AP 傳送 AssocResponse 時，其最後一個 IE 在框架中只剩下一個位元組 （element_id 位元組位於 pkt_len-1） ，迴圈會從 pframe[pkt_len] 讀取 pIE->length ，這比配置的接收緩衝區多一個位元組。此外，即使標頭位元組在邊界內，pIE->length 本身也可以將資料視窗延伸至 pkt_len之外，以無訊息的方式將截斷的 IE 傳遞至處理常式函式。在迴圈主體的頂端新增兩個保護： 1. 如果剩餘的位元組少於 sizeof（*pIE） 位元組，則中斷 （無法讀取標頭）。2. 如果 IE 宣告的資料超出 pkt_len，則中斷。（CVE-2026-64444）

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

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

  - userfaultfd：對 pte_present（） userfaultfd_must_wait（） 和 userfaultfd_huge_must_wait（） 進行門must_wait可寫性檢查，而不使用頁面表格鎖定讀取 PTE，然後對其套用 pte_write（） / huge_pte_write（）。這些存取子只會從目前的編碼解碼位;在交換或移轉項目上，它們會讀取碰巧共用相同位置的偏移位元，並傳回未定義的結果。檢查的目的是這個故障是否仍然被 WP 阻止？非標記交換項目表示頁面正在傳輸中 -- 原始錯誤傳遞的使用者錯誤內容不再相同，如果使用者空間仍需要處理，交換或移轉完成路徑將重新傳遞新的錯誤。最壞的情況是，在當前代碼下，垃圾寫入位說等待，並且線程保持睡眠狀態，直到可能永遠不會到達的UFFDIO_WAKE。對 pte_present（） 進行可寫性檢查，以便無鎖定重新檢查僅在項目實際存在時檢查 present-PTE 位元。不存在、非標記的案例傳回 Don't Wait，並讓錯誤路徑重試。（CVE-2026-64514）

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Keep dynamic inner array lookups nullable An ARRAY_OF_MAPS can use an array created with BPF_F_INNER_MAP as its inner map template. A concrete inner array with a different max_entries value can then replace the template. After a successful outer map lookup, the verifier represents the resulting map pointer using the inner map template. Const-key lookup nullness elision consequently uses the template max_entries even though the runtime helper uses the concrete inner map max_entries. Do not elide lookup result nullness for maps marked with BPF_F_INNER_MAP, because the template max_entries does not prove that the key is in bounds for the concrete runtime map. (CVE-2026-64353)

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

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

  - udf：根據分割區長度驗證可用區塊範圍 udf_free_blocks（） 會針對分割區長度檢查邏輯區塊編號和計數，但會捨棄該最終界限的範圍偏移。當 logicalBlockNum + 位移 + 計數點經過分割區時，特製的範圍可以通過保護，稍後會編製索引經過空間點陣圖陣列。由此類範圍支援的檔案上的單一 ftruncate（2） 會可靠地使核心發生錯誤。這是本機可用性問題。在 UDisks/polkit 允許作用中使用者無需CAP_SYS_ADMIN的情況下掛載抽取式 UDF 媒體的桌面系統上，無特權的本機使用者可以提供特製的檔案系統，並透過截斷其上的可寫入檔案來觸發錯誤。需要 root 或 CAP_SYS_ADMIN 掛載映像的系統具有更高的先決條件。聲明不會對機密性或完整性造成影響：重現的原語是點陣圖指標插槽的越界讀取，後面接著核心錯誤。使用已計算的 logicalBlockNum + 偏移 + 計數值進行分割區長度檢查。此外，在建立 s_block_bitmap[]索引之前，也使 load_block_bitmap（） 拒絕超出範圍的區塊組，這樣損毀的呼叫端就無法經過彈性陣列。（CVE-2026-64324）

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

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

  - iio： accel： kxsd9：修正 write_raw（） 錯誤上的執行階段 PM 不平衡 kxsd9_write_raw（） 採用具有 pm_runtime_get_sync（） 的執行階段 PM 參照，但當要求具有非零整數部分的刻度時，會直接傳回 -EINVAL，跳過相符的 pm_runtime_put_autosuspend（）。這會在每次此類寫入時洩漏運行時間 PM 使用計數器參考，之後裝置就無法再自動暫停。設定錯誤代碼並下降到現有的放置，而不是提前返回。（CVE-2026-64503）

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

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

  - 藍牙：btnxpuart：修正 nxp_recv_fw_req_v3（） 中的越界韌體讀取 在 v3 韌體下載期間，控制器會傳送具有 32 位位位移和 16 位元 len 的v3_data_req。nxp_recv_fw_req_v3（） 只會檢查位移的下限，然後從該位移傳送韌體。
    nxpdev->fw_dnld_v3_offset = 位移 - nxpdev->fw_v3_offset_correction;
    serdev_device_write_buf（nxpdev->serdev， nxpdev->fw->data + nxpdev->fw_dnld_v3_offset， len）;沒有任何檢查 fw_dnld_v3_offset + len 是否保持在 nxpdev->fw->size 內，因此要求超出韌體映像的位移或長度的控制器會讓驅動程式讀取 nxpdev->fw->data 的結尾，並透過 UART 將該記憶體傳回。nxp_recv_fw_req_v1（） 已經限制了相同的寫入。將對等檢查新增至 v3 路徑，當要求超出韌體映像時拒絕要求，並在錯誤路徑上將零 len，以便 free_skb 時的fw_v3_prev_sent簿記保持一致。（CVE-2026-64407）

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

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

  - USB： gadget： composite：修正 USB_DT_OTG 處理常式中的死空檢查 當未選取任何選項時，composite_setup（） 的 OTG 分支會回復到第一個組態：if （cdev->config） config = cdev->config;else config = list_first_entry（&cdev->configs， struct usb_configuration， list）;if （！config） goto done;...
    memcpy（req->buf， config->descriptors[0]， value）;list_first_entry（） 從不傳回 NULL。在空白清單上，它會傳回清單標頭的 container_of（）。因此，if （！config） 檢查已失效。當 cdev->configs 為空時，配置指向結構usb_composite_dev內的頭部。config->descriptors[0] 會讀取位於該偏移量的任何內容。memcpy 會將最多 w_length 位元組複製到回應緩衝區中。cdev->configs 在兩種情況下可以是空的。一種是關於小工具的拆解競賽，並在飛行中進行控制轉移。另一個是在新增配置之前設定is_otg的驅動程式。將 cdev->configs 保留為空白的重新生產程式會在此分支中觸發 KASAN 錯誤。使用 list_first_entry_or_null（） 以便現有檢查完成其工作。
    (CVE-2026-64347)

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

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

  - nvmet-auth：根據傳輸長度驗證回覆訊息負載邊界 nvmet_auth_reply（） 使用攻擊者控制的 HL （雜湊長度） 和 dhvlen （DH 值長度） 欄位存取可變長度 rval[] 陣列，而不驗證它們是否適合配置的 tl 位元組緩衝區。惡意 NVMe-oF 啟動程式可製作傳輸長度較小但 hl/dhvlen 值較大的 DHCHAP_REPLY 訊息，進而在目標處理 DH 公開金鑰 （rval + 2*hl） 或執行主機回應 memcmp 時造成越界堆積讀取。設定 DH 驗證後，OOB 指標會直接傳遞至 sg_init_one（） 並由 crypto_kpp_compute_shared_secret（） 讀取，最多可達緩衝區 526 位元組。這是可利用的預先驗證。新增邊界驗證，確保在存取可變長度欄位之前，確保 sizeof（*data） + 2*hl + dhvlen <= tl。由 Atuin 發現 - 自動化漏洞發現引擎。
    (CVE-2026-64319)

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

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

  - mm：使用正確的掛載 idmap 進行檔案擁有權檢查 自從引入 idmap 掛載以來，mincore（） 和 madvise（MADV_PAGEOUT） 中的 inode 擁有權檢查（用於旁路保護）都是針對 nop_mnt_idmap 進行的，這完全忽略了檔案掛載的 idmap。這會導致奇怪的邊緣情況，例如：
    1） 使用 idmap userA：userB：1 掛載/綁定掛載 2） userB 對 userA 在磁碟上/記憶體中擁有但在 idmap 轉換後由 userB 擁有的檔案執行 owner_or_capable（） 檢查 3） owner_or_capable（） 因未提供正確的 idmap 而神秘失敗 在 mincore/madvise MADV_PAGEOUT的情況下，這通常是良性的， 因為 file_permission（file， MAY_WRITE） 可能會成功，因為它在內部使用正確的 idmap，但在例如 0444 檔案上，即使是所有者本身也沒有寫入它的權限，因此不需要如此。由於這顯然不是一件容易的事，因此引入一個可以攜帶正確語義的 file_owner_or_capable（），並將 mm 中的各種用戶切換到它。
    該問題是透過手動程式碼檢查和與 Jan Kara 的清單外討論發現的。（CVE-2026-64294）

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

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

  - 輸入：touchwin - 重置每個完整封包的資料包索引 tw_interrupt（） 將每個非零序列位元組累積到一個固定的三位元組緩衝區中，該緩衝區具有運行索引，該索引僅在收到完整封包後重設，*並且*設備的兩個 Y 位元組一致：tw->data[tw->idx++] = data;if （tw->idx == TW_LENGTH & tw->data[1] == tw->data[2]） { ...tw->idx = 0;} 重設在 tw->data[1] == tw->data[2] 上，這是裝置控制的值。惡意、失靈或偽造的 Touchwindow 周邊裝置可以串流第 2 位元組和第 3 位元組不同的非零位元組：索引在沒有相等持有的情況下達到 TW_LENGTH，永遠不會重設，並且不斷增長，因此 tw->data[tw->idx++] 從三位元組陣列的末尾和堆積分配結構 tw 的其餘部分走出，一次一個攻擊者選擇的位元組 -- 一個不受限制的 裝置驅動堆積越界寫入。重設每個已完成封包的索引，並僅在兩個 Y 位元組相符時報告事件，就像其他 serio 觸控螢幕驅動程式一樣。CVE-2026-64271

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

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

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

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

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

  - module： decompress：檢查 module_extend_max_pages（） 的傳回值 module_extend_max_pages（） 在內部呼叫 kvrealloc（），並在分配失敗時傳回 -ENOMEM。永遠不會檢查傳回值。如果初始配置失敗，info->pages 會維持為 NULL，而 info->max_pages 仍為 0。對 module_get_next_page（） 的後續呼叫將嘗試透過呼叫 module_extend_max_pages（info， 0） 來動態增長陣列，因為 info->used_pages 為 0。這會導致 kvrealloc（NULL， 0） 傳回 ZERO_SIZE_PTR，這會被視為成功，導致 ZERO_SIZE_PTR 解除參照和核心 oops。修正：在 module_extend_max_pages（） 之後新增缺少的錯誤檢查，並在失敗時立即返回。這與模組載入路徑中所有其他 kvrealloc（） 呼叫者使用的模式相符。[Sami：更正了提交訊息中的分析。（CVE-2026-64297）

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

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

  - USB：serial： keyspan_pda：修正資訊洩漏 write（） 回呼應該傳回接受的字元數或負 errno。不過，由於新增寫入 FIFO 支援，如果寫入 urb 尚未使用，keyspan_pda 實作會傳回提交至裝置的字元數。如果此數字大於傳遞給 write（） 的字元數，則行紀律會繼續從 tty 寫入緩衝區之外寫入資料。透過確保 keyspan_pda_write_start（） 如預期成功時傳回零來修正資訊洩漏。（CVE-2026-64336）

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

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

  - HID：多點觸控：修正mt_io_flags mt_io_flags上的越界位元存取是單一無符號長，但 mt_process_slot（）、mt_release_pending_palms（） 和 mt_release_contacts（） 將其用作由插槽編號索引的每個插槽點陣圖。該插槽號碼僅由 td->maxcontacts 限制，其取自裝置的 ContactCountMaximum 功能報告，最多可以是 255，而不是BITS_PER_LONG。因此，通告大量接觸人數的多點觸控裝置會使 set_bit（）/clear_bit（） 在mt_io_flags字之外運行，並破壞結構mt_device的相鄰成員。粘手指釋放計時器是實現這一目標的最簡單方法。mt_release_contacts（） 執行於 （i = 0; i < mt->num_slots; i++） clear_bit（i， &td->mt_io_flags）;使用 num_slots == maxcontacts。對於 250 左右的 maxcontacts，迴圈會清除與 td->applications.next 重疊的位，將該清單頭歸零，然後緊隨其後的 list_for_each_entry（） 取消參照 NULL。核心從計時器 （softirq） 上下文中發生錯誤。在 KASAN 構建中，這在 mt_release_contacts（） 中顯示為一般保護錯誤，偏移0x58處有一個 null-ptr-deref，即 offsetof（struct mt_application， num_received）。可從不受信任的 USB 或藍牙 HID 多點觸控裝置存取狀態;不需要本機權限。將每個插槽的作用中狀態儲存在個別配置的點陣圖中，大小為 maxcontacts，與已用於pending_palm_slots的相同模式，並只保留 MT_IO_FLAGS_RUNNING mt_io_flags。兩個mt_io_flags和MT_IO_SLOTS_MASK布防檢查變為bitmap_empty（td->active_slots、td->maxcontacts）。將MT_IO_FLAGS_RUNNING移回位元 0。它被相同的提交提升到位元 32，以將低位元組留給插槽位元;隨著插槽位的消失，它再次適合位元 0，這也使其保持在 32 位元的無符號長內。(CVE-2026-64364)

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

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

  - 已解決 Linux 核心中的下列弱點：HID: hid-goodix-spi: validate report size to prevent stack buffer overflow goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack buffer (tmp_buf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set hid_ll_driver.max_buffer_size and performs no bounds checking before copying the payload: memcpy(tmp_buf + tx_len, buf, len); A hidraw SET_REPORT ioctl with a report larger than ~116 bytes overflows the stack buffer. Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity. Discovered by Atuin - Automated Vulnerability Discovery Engine. (CVE-2026-64367)

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

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

  - NVMe：目標：RDMA：修正佇列連接 nvmet_rdma_queue_connect（） 呼叫 nvmet_rdma_find_get_device（） 上的 ndev 參照計數洩漏，該呼叫透過 kref_get（） 取得傳回 ndev 的參照。在超過主機佇列待辦事項且函式傳回 NVME_SC_CONNECT_CTRL_BUSY 的路徑上，未釋放 ndev 參照，導致 kref 洩漏。透過在提前返回之前將 goto 新增至現有put_device標籤來解決此問題。（CVE-2026-64321）

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

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

  - 已解決 Linux 核心中的下列弱點：crypto: ccp - Do not initialize SNP for SEV ioctls 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? sev_move_to_init_state() is called for ioctls requiring only SEV firmware:
    SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, and SEV_PDH_CERT_EXPORT. After the firmware command, it does SEV_SHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling __sev_platform_init_locked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVE_PA is not cleared. The previous code saved any SEV initialization firmware error to init_args.error and then threw it away and hardcoded the return value of INVALID_PLATFORM_STATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems. Note that it is still safe to call __sev_firmware_shutdown() directly: it calls __sev_snp_shutdown_locked(), which skips SNP shutdown if SNP was not initialized. (CVE-2026-64310)

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

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

  - iio：chemical：scd30：清理初始化並修正簽名擴展錯誤 包括 linux/bitfield.h 用於 FIELD_GET（）。建立用於位元操作的新巨集，並結合手動位元操作，並將其替換為 FIELD_GET（）。目前的變數宣告和初始化幾乎不可讀，並且在多行中使用逗號分隔。重構初始化，以便尾數和 exp 具有單獨的宣告，並且稍後會初始化符號。此外（由於清理的性質），修正了一個符號擴展錯誤，其中 float32 將按位元並使用 ~BIT（31）（這是 0xFFFFFFFF7FFFFFFF），這會損壞指數。（CVE-2026-64497）

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

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

  - 暫存：rtl8723bs：修正 HT_caps_handler（） 中的 OOB 寫入 HT_caps_handler（） 反覆運算 pIE >長度位元組並寫入 HT_caps.u.HT_cap[]，這是一個固定的 26 位元組陣列 （sizeof struct HT_caps_element）。由於 pIE->length 是來自無線 802.11 AssocResponse 框架的原始 u8，並且從未經過驗證，因此惡意 AP 可以將其設定為 255，導致結構mlme_ext_info的相鄰欄位中出現多達 229 位元組的越界寫入。使用 umin（） 將迭代計數截斷為 HT_caps.u.HT_cap 的大小，以便無訊息地忽略來自比預期更長的 IE 的資料，而不是越界寫入，從而保持與填充元素的 AP 的互通性。考慮過過大 IE 的早期返回，但被拒絕：它會繞過迴圈之前的 pmlmeinfo->HT_caps_enable = 1 分配，靜默地停用將額外位元組附加到 HT 功能 IE 的 AP 的 HT 模式。（CVE-2026-64440）

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

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

  - FFmpeg 已 8.1.2修正在認可8670835中，在 LCL/ZLIB 視訊解碼器中包含資訊洩漏弱點，可讓攻擊者提供有效的 zlib 資料流程，以膨脹到比預期畫面大小少的位元組，以暴露未初始化的堆積記憶體。lcldec.c 中的 zlib_decomp（） 函式會將短解壓縮視為非重大解壓縮，並繼續執行 RGB24 轉換路徑，這會使用原始框架維度從配置緩衝區複製完整框架的資料列，導致未初始化的堆積內容 （包括指標衍生的配置器位元組） 複製到攻擊者可觀察的 AVFrame 輸出中，並可能在長期媒體處理服務中擊敗 ASLR。（CVE-2026-66038）

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

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

  - Qt XML 4.0.06.11 中的 QDom 註解、CDATA 及處理指令序列化中的不當輸出無效化 （XML 插入） 允許應用程式序列化到這些節點的不受信任文字插入任意 XML 標記，因為節點終止符不會在預設 InvalidDataPolicy （AcceptInvalidChars） 下逸出。在 Qt 6.12中修復。（CVE-2026-15037）

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

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

  - 大括號擴充 5.0.7 容易因記憶體耗盡而遭受拒絕服務。expand（） 函式會使用 max 選項 （預設值 100,000） 限制結果數目，但不會限制每個結果字串的長度。藉由鏈結多個大括號群組，攻擊者可將結果計數保持在限制之下，同時使每個結果逐漸變長，因此總記憶體會隨著計數和字串長度而調整，直到處理程序遇到致命的、無法擷取的記憶體不足錯誤為止。大約 7.5 KB 的輸入 （'{a，b}'.repeat（1500）） 使預設Node.js處理程序當機。任何將受攻擊者影響的字串傳遞至 brace-expansion.expand（） 的應用程式 （直接或透過小型比對/大括號模式轉移） 都可能因小請求而當機。透過 5.0.8 新增 maxLength 選項 （預設為 4,000,000） 來固定累積輸出和中間陣列。（CVE-2026-14257）

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

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

  - FFmpeg 7.0 透過 8.1.2在提交 4da9812 中修正，在 vf_quirc 篩選器中包含堆積越界寫入弱點，攻擊者可藉由提供畫面尺寸不相符的特製 PGS/SUP 字幕檔案來損毀堆積記憶體。攻擊者可以提供一個字幕文件，其第二個簡報的尺寸比第一個簡報更大，導致 av_image_copy_plane（） 將超過初始分配大小的資料複製到尺寸過小的 libquirc 灰階影像緩衝區中，從而導致堆積損毀和進程崩潰，並可能執行程式碼。（CVE-2026-66041）

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

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

  - FFmpeg 透過 8.1.2在提交 5d7112c 中修正，在 IAMF 解復用器中包含一個不受控制的資源消耗弱點，該弱點允許未經驗證的攻擊者透過提供特製的 count_label 欄位，從 17 位元組的輸入檔造成數 GB 記憶體配置。libavformat/iamf_parse.c 中的 mix_presentation_obu（） 函式會在驗證可用的 OBU 資料之前，使用攻擊者控制的值呼叫 av_calloc（count_label， sizeof（*language_label）），從而使每個輸入位元組的分配放大約為 126,000,000,000 個位元組，從而耗盡處理程序記憶體或在格式探測期間觸發 OOM 終止。
    (CVE-2026-66037)

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

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

  - FFmpeg 至版本 8.1.2 為止（已在提交 aafb5c6 中修復），其 MACE6 音訊解碼器中存在一個有符號整數溢出漏洞，攻擊者可透過提供一個包含惡意 bytes_per_packet 值的特製 CAF 檔案，來破壞堆記憶體。攻擊者可製作一個 CAF 檔案，在 desc 區塊中將 bytes_per_packet 和 frames_per_packet 的值設定為過大，藉此在 mace_decode_frame() 函式進行輸出樣本計數計算時觸發整數溢位，導致緩衝區分配過小，進而引發堆記憶體越界寫入，可能導致程式碼執行。（CVE-2026-66039）

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

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

  - Knot Resolver before 6.4.1 允許透過 DoQ （DNS-over-QUIC） 接收路徑中的堆積型緩衝區溢位執行遠端程式碼。（CVE-2026-66374）

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

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

  - FFmpeg 8.1.2 版（已在提交 b506faf 中修復）的原生 PNG 和 APNG 編碼器中存在堆記憶體越界寫入漏洞，遠端攻擊者可透過提供包含惡意 eXIf 區塊的特製 PNG 圖片，來破壞堆記憶體。攻擊者可構建一個 eXIf 區塊，其中多個 IFD 條目皆引用相同的大型值載荷，導致規範序列化將輸出擴展至遠超出由 add_exif_profile_size() 估算的不足分配大小，進而使 png_write_chunk() 在緩衝區邊界之外寫入數萬位元組的資料，從而引發可預測的堆記憶體損毀、程序當機，並可能導致任意程式碼執行。（CVE-2026-66040）

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

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

  - FFmpeg 至版本 8.1.2 為止（已在提交 5d7112c 中修復），其 vf_hqdn3d 濾波器中存在一項堆記憶體越界寫入漏洞，攻擊者若透過 -reinit_filter  0 選項停用濾波器圖重新初始化功能，並提供一則經特殊設計的影片（該影片的幀解析度在相鄰幀之間會增加），即可導致堆記憶體遭篡改。攻擊者可提供惡意影片輸入，使 vf_hqdn3d.config_input() 根據初始幀寬度分配出各平面線性歷史緩衝區容量不足的情況；隨後較大的幀會導致 denoise_spatial() 寫入超出分配邊界，進而引發堆記憶體損壞。
    (CVE-2026-66036)

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

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

  - drm/amd/display：驗證 dc_process_dmub_aux_transfer_async 中的負載長度和link_index [Why&How] dc_process_dmub_aux_transfer_async（） 將負載>長度位元組複製到 16 位元組堆疊緩衝區 （dpaux.data[16]） 中，僅由 ASSERT（） 保護，這在發行版本中是無操作的。如果調用端傳遞長度> 16，則會導致透過 memcpy 的堆疊緩衝區溢位。此外，link_index 用於取消參照 dc->links[]，而不對 dc->link_count進行邊界檢查，從而存在越界存取的風險。
    將 ASSERT 替換為硬式執行階段檢查，當 payload->length 超過目的地緩衝區大小時傳回 false，並在使用之前新增 link_index 的邊界檢查。（從提交 ba4caa9fecdf7a38f98c878ad05a8a64148b6881 中挑選）（CVE-2026-64219）

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

ID	名稱	嚴重性
329776	Linux Distros 未修補弱點：CVE-2026-64399	critical
329775	Linux Distros 未修補弱點：CVE-2026-64270	high
329774	Linux Distros 未修補弱點：CVE-2026-64394	high
329773	Linux Distros 未修補弱點：CVE-2026-64452	high
329772	Linux Distros 未修補弱點：CVE-2026-64267	medium
329771	Linux Distros 未修補弱點：CVE-2026-64404	medium
329770	Linux Distros 未修補弱點：CVE-2026-64513	high
329769	Linux Distros 未修補弱點：CVE-2026-64456	high
329768	Linux Distros 未修補弱點：CVE-2026-64402	high
329767	Linux Distros 未修補弱點：CVE-2026-64411	high
329766	Linux Distros 未修補弱點：CVE-2026-64275	medium
329765	Linux Distros 未修補弱點：CVE-2026-64381	high
329764	Linux Distros 未修補弱點：CVE-2026-64380	high
329763	Linux Distros 未修補弱點：CVE-2026-64396	high
329762	Linux Distros 未修補弱點：CVE-2026-64389	high
329761	Linux Distros 未修補弱點：CVE-2026-64473	high
329760	Linux Distros 未修補弱點：CVE-2026-64413	high
329759	Linux Distros 未修補弱點：CVE-2026-64467	high
329758	Linux Distros 未修補弱點：CVE-2026-64408	high
329757	Linux Distros 未修補弱點：CVE-2026-64491	medium
329756	Linux Distros 未修補弱點：CVE-2026-64269	critical
329755	Linux Distros 未修補弱點：CVE-2026-64444	high
329754	Linux Distros 未修補弱點：CVE-2026-64514	high
329753	Linux Distros 未修補弱點：CVE-2026-64353	medium
329752	Linux Distros 未修補弱點：CVE-2026-64324	high
329751	Linux Distros 未修補弱點：CVE-2026-64503	high
329750	Linux Distros 未修補弱點：CVE-2026-64407	high
329749	Linux Distros 未修補弱點：CVE-2026-64347	medium
329748	Linux Distros 未修補弱點：CVE-2026-64319	critical
329747	Linux Distros 未修補弱點：CVE-2026-64294	medium
329746	Linux Distros 未修補弱點：CVE-2026-64271	high
329745	Linux Distros 未修補弱點：CVE-2026-64382	high
329744	Linux Distros 未修補弱點：CVE-2026-64297	medium
329743	Linux Distros 未修補弱點：CVE-2026-64336	medium
329742	Linux Distros 未修補弱點：CVE-2026-64364	high
329741	Linux Distros 未修補弱點：CVE-2026-64367	high
329740	Linux Distros 未修補弱點：CVE-2026-64321	medium
329739	Linux Distros 未修補弱點：CVE-2026-64310	medium
329738	Linux Distros 未修補弱點：CVE-2026-64497	high
329737	Linux Distros 未修補弱點：CVE-2026-64440	high
329734	Linux Distros 未修補弱點：CVE-2026-66038	high
329733	Linux Distros 未修補弱點：CVE-2026-15037	medium
329732	Linux Distros 未修補弱點：CVE-2026-14257	high
329731	Linux Distros 未修補弱點：CVE-2026-66041	high
329730	Linux Distros 未修補弱點：CVE-2026-66037	high
329729	Linux Distros 未修補弱點：CVE-2026-66039	high
329728	Linux Distros 未修補弱點：CVE-2026-66374	high
329727	Linux Distros 未修補弱點：CVE-2026-66040	high
329726	Linux Distros 未修補弱點：CVE-2026-66036	high
329714	Linux Distros 未修補弱點：CVE-2026-64219	high

偵測

Nessus 的 Misc. 系列

critical

high

high

high

medium

medium

high

high

high

high

medium

high

high

high

high

high

high

high

high

medium

critical

high

high

medium

high

high

high

medium

critical

medium

high

high

medium

medium

high

high

medium

medium

high

high

high

medium

high

high

high

high

high

high

high

high