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

  - net：wwan： iosm：修正 ipc_imem_init（） 中潛在的記憶體洩漏 ipc_protocol_init（） 中配置的記憶體不會在 ipc_imem_init（） 中後續的錯誤路徑上釋放。藉由呼叫錯誤路徑中對應的發行函式 ipc_protocol_deinit（） 來修正此問題。（CVE-2026-64179）

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

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

  - thunderbolt： property：在 __tb_property_parse_dir（） 中限制遞迴深度 DIRECTORY 項目的值欄位會用作遞迴呼叫 __tb_property_parse_dir（） 且沒有深度計數器的dir_offset。將 DIRECTORY 項目鏈結至反向參照迴圈的特製對等會驅動剖析器，直到核心堆疊耗盡且防護頁面觸發為止。任何到達PROPERTIES_REQUEST控制平面交換的不受信任的 XDomain 對等體 （纜線、擴充座、內嵌檢查器、相鄰主機） 都可以在不進行驗證的情況下觸發此觸發。透過 tb_property_parse（） 和 __tb_property_parse_dir（） 執行深度計數器，並拒絕超過 TB_PROPERTY_MAX_DEPTH = 8 的區塊。這比任何觀察到的合法 XDomain 佈局都大得多。不需要 XDomain 主機對主機探索的操作員可以使用核心命令列上的 thunderbolt.xdomain=0 完全停用路徑。（CVE-2026-63891）

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

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

  - batman-adv：bla：避免bla.num_requests雙倍遞減 當沒有進行request_sent時，bla.num_requests會增加。並在各地遞減（收到公告，清除骨幹，定期工作）。但是檢查 request_sent 是否實際上設定為特定狀態，並且 atomic_dec/_inc 不安全，因為它們不是不可部分完成的 （TOCTOU），並且多個此類程式碼部分可以同時執行。同時，需要對request_sent（狀態）和bla.num_requests進行原子修改。否則，batadv_bla_send_request（） 可能會將 request_sent 設為 1 並中斷。
    然後，batadv_handle_announce（） 可以將request_sent設回 0，並在 batadv_bla_send_request（） 遞增之前遞減num_requests。因此，必須鎖定這兩個作業。由於狀態 （request_sent） 和 wait_periods 只能在此鎖內訪問，因此可以將它們轉換為更簡單的資料類型。為了避免bla.num_requests在 batadv_bla_purge_backbone_gw（） 運行後被具有有效backbone_gw參照的並行運行上下文所觸及，需要第三個狀態 stopped 來正確發出信號，表明backbone_gw處於正在清理的狀態。（CVE-2026-64095）

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

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

  - batman-adv： tt：修正報告 VLAN 的 TOCTOU 爭用 本機 TT 型 TVLV 是透過先檢查至少具有一個 TT 項目的 VLAN 數目來產生的。然後會配置一個具有正確 VLAN 大小的新緩衝區。只有這樣，VLAN的清單才會用於填充緩衝區中的VLAN項目。在此期間，舉行meshif_vlan_list_lock。但是，在此期間，每個VLAN的實際TT條目數量仍可能增加，只是清單中的VLAN數量不會增加。但是，緩衝區大小計算中使用的預過濾器仍可能導致需要儲存的 VLAN 數量增加。僅僅是因為 VLAN 現在可能突然至少有一個條目，而它在預先配置檢查中沒有條目，然後需要佔用未配置的空間。最好在開始時高估緩衝區大小，然後僅使用不為空的 VLAN 填充緩衝區。（CVE-2026-64091）

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

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

  - USB：序列：mct_u232：修正小型端點的記憶體損毀 驅動程式會覆寫特定裝置的最大傳輸大小，該裝置僅接受其 32 位元組大量端點的 16 位元組封包。請確定切勿增加傳輸大小上限，以防止在惡意裝置報告的端點封包大小上限小於預期時損毀。（CVE-2026-63898）

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

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

  - 已解決 Linux 核心中的下列弱點：net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop When mirred redirects to ingress (from either ingress or egress) the loop state from sched_mirred_dev array dev is lost because of 1) the packet deferral into the backlog and 2) the fact the sched_mirred_dev array is cleared. In such cases, if there was a loop we won't discover it. Here's a simple test to reproduce: ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10 (CVE-2026-63982)

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

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

  - drm/v3d： 修正錯誤路徑上 CPU 工作查詢陣列的釋放後使用 CPU 工作 ioctl 的失敗標籤會在 v3d_job_cleanup（） 之後呼叫 cpu_job 的時間戳記和效能查詢陣列上的 kvfree（），這會刪除工作的最後一個參照並釋放cpu_job。在這一點上閱讀cpu_job是釋放後的使用。此外，在早期的 v3d_job_init（） 故障路徑上，它是 NULL 解除參照，因為 v3d_job_deallocate（） 將本機指標歸零。在成功路徑中，陣列會從排程器的.free_job回呼釋放，但在錯誤路徑上，會手動釋放陣列，因為從未將工作推送至排程器。雖然成功路徑可以正確處理此問題，但失敗路徑卻沒有。最重要的是，手動 kvfree（） 調用僅釋放陣列存儲;它們不會drm_syncobj_put （） v3d_timestamp_query_info_free（） 和 v3d_performance_query_info_free（） 在成功路徑上釋放的每個查詢 syncobj。因此，觸發釋放後使用的相同失敗路徑也會為每個查詢洩漏一個 syncobj 參考。將 CPU 工作拆解統一到 CPU 工作的 kref 析構函式中，鏡像 v3d_render_job_free（）。排程器的.free_job插槽會還原為一般 v3d_sched_job_free（），而失敗標籤會捨棄手動 kvfree（） 呼叫，留下從排程器和 ioctl 錯誤路徑到達的單一拆卸路徑。這會依建構移除釋放後使用、空取消參照和 syncobj 洩漏。（CVE-2026-64099）

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

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

  - USB：typec：ucsi：ccg：拒絕沒有 '：' 記錄標頭的韌體映像 do_flash（） 找到第一個 .cyacd 記錄，其中 p = strnchr（fw->data， fw->size， '：'）;while （p < eof） { s = strnchr（p + 1， eof - p - 1， '：'）; ... }如果韌體映像不包含 '：' 位元組，strnchr（） 會傳回 NULL。NULL 會比較小於有效核心指標 eof，因此迴圈主體會執行，並以 p + 1 == （void *）1 和大約 （無符號 long）eof 的長度呼叫 strnchr（），從而導致奇妙的崩潰。do_flash（） 中的 not_signed_fw fallthrough 和 ccg_fw_update_needed（） 中的晶片狀態分支允許未簽名的 blob 到達此迴圈，因此可以在 /lib/firmware 下放置特製檔案並寫入 do_flash sysfs 屬性的 root 使用者可以觸發 oops。當初始 strnchr（） 傳回 NULL 時，使用 -EINVAL 救助。
    (CVE-2026-63964)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns
    -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only. Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are complementary and can land in either order. (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a) (CVE-2026-63880)

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

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

  - 已解決 Linux 核心中的下列弱點：net: ti: icssm-prueth: fix eth_ports_node leak in probe The error path on of_property_read_u32() failure inside icssm_prueth_probe() returns without putting eth_ports_node, which was acquired before the for_each_child_of_node() loop. Drop it before returning. (CVE-2026-64161)

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

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

  - batman-adv： mcast：修正 orig_node RCU 版本中的釋放後使用 batadv_mcast_purge_orig（） 會從受 RCU 保護的 hlist 中移除項目，但不會等待 RCU 寬限期後再返回。並行 RCU 讀取器仍可在移除時存取這些項目的參照。受 RCU 保護的讀取器嘗試對 orig->mcast_want_all_ipv6_node 等條目進行操作，然後將存取已釋放的記憶體。
    透過在 call_rcu（） 叫用之前將 batadv_mcast_purge_orig（） 移至 batadv_orig_node_release（） 來修正此問題。這可確保在清除時作用中的 RCU 讀取器在回收 orig_node 記憶體之前已耗盡。（CVE-2026-64096）

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

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

  - hwmon：（pmbus/adm1266） 在讀取緩衝區中包含 PEC 位元組 pmbus_block_xfer adm1266_pmbus_block_xfer（） 以 .buf = data->read_buf、.len = ADM1266_PMBUS_BLOCK_MAX + 2 設定讀取事務，但結構adm1266_data中的 read_buf 宣告為 u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1];對於最大長度區塊回應 （長度位元組 = 255 + 最多 1 個 PEC 位元組），i2c 控制器被告知將 257 個位元組寫入 256 位元組緩衝區，將一個位元組放在 read_buf 結尾之後。如果 （crc ！= msgs[1].buf[msgs[1].buf[0] + 1]） 讀取超出陣列的一個位元組，則相同的回應也會使後續的 PEC 進行比較。將 read_buf 宣告提升為 ADM1266_PMBUS_BLOCK_MAX + 2，讓緩衝區可以保留長度位元組、最多 255 個承載位元組，以及 i2c_msg 長度已考慮的 PEC 位元組。（CVE-2026-64086）

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

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

  - 已解決 Linux 核心中的下列弱點：spi: ep93xx: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. (CVE-2026-64169)

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

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

  - net： tls：修正包裝sk_msg環的sg_chain條目計數中的差一 當 sk_msg 散佈清單環環環換行 （sg.end < sg.start） 時，tls_push_record（） 使用 sg_chain（） 將環的尾部鏈結到頭部。sg 陣列中為此保留了一個額外的項目： struct sk_msg_sg { [...] /* 額外的兩個元素： * 1） 用於在清單變為 * 分割時鏈結前面和部分（例如結束<開始）。加密 API 需要 * 鏈結;* 2） 在訊息之後鏈結 tailer SG 項目。*/ 結構散點表資料[MAX_MSG_FRAGS + 2];目前程式碼使用 MAX_SKB_FRAGS + 1 作為戒指大小：
    sg_chain（&msg_pl->sg.data[msg_pl->sg.start]， MAX_SKB_FRAGS - msg_pl->sg.start + 1， msg_pl->sg.data）;這會將鏈結指標放在 sg_chain（data[start]， （MAX_SKB_FRAGS - msg_start + 1） .. = &data[start] + （MAX_SKB_FRAGS - msg_start + 1） - 1 = data[start + （MAX_SKB_FRAGS - start + 1） - 1] = data[MAX_SKB_FRAGS] 而不是真正的最後一個項目。這可能是因為修正項下的提交爭用接近提交 031097d9e079 （bpf：sk_msg，psock down 時出現 zap 輸入佇列） 轉換為 ARRAY_SIZE 並刪除 data[start] / - start （如 Sabrina 建議）。（CVE-2026-64047）

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

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

  - USB： serial： keyspan：修正缺少的 indat 傳輸健全性檢查 新增缺少的 usa49wg indat 傳輸大小的健全性檢查，以避免剖析過時或未初始化的 slab 資料。（CVE-2026-63900）

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

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

  - memfd：在暗示 SEAL_WRITE 時拒絕可寫入映射 當新增 SEAL_EXEC 時，暗示SEAL_WRITE 使 W^X。但是隱含的密封是在檢查之後設定的，以確保 memfd 不能有任何可寫入的對應。這表示可以使用 SEAL_EXEC 來套用SEAL_WRITE，同時具有可寫入的對應。這破壞了 SEAL_WRITE 提供的合約，攻擊者可以使用它來傳遞看似寫入密封但仍可以任意修改的 memfd。透過在呼叫 mapping_deny_writable（） 之前新增隱含的密封來修正此問題。（CVE-2026-63952）

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

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

  - USB：serial： cypress_m8：修正具有小型端點的記憶體損毀 請確定中斷輸出端點的最大封包大小至少為 8 個位元組，以避免使用者控制的 slab 損毀或 NULL 指標解除參照 （如果惡意裝置報告較小的大小）。（CVE-2026-63956）

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

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

  - ixgbevf：修正 VEPA 多點傳播來源修剪 ixgbevf_clean_rx_irq（） 中的釋放後使用，透過釋放 skb 並繼續下一個描述dev_kfree_skb_irq元，修剪來源 MAC 符合 VF 自身位址的幀 （VEPA 多點傳播變通方法）;繼續;skb 指標在 while 迴圈外部宣告，並在反覆專案之間持續存在。因為 continue 會跳過迴圈底部的 skb = NULL 重設，所以下一個反覆運算會進入 else if （skb） 路徑，並在釋放的 skb 上呼叫 ixgbevf_add_rx_frag（），解除參照 skb_shinfo（skb）->nr_frags - NAPI softirq 上下文中的釋放後使用。同級驅動程式 iavf 已在繼續之前將指標設為 null，以正確處理此問題。在這裡套用相同的模式。
    我沒有 ixgbevf 硬體;該錯誤是通過靜態分析發現的（scan_drop_continue_loops.py + semgrep drop_continue_in_loop，掃描中得分最高的多工具佐證）。UAF 在 KASAN 下透過載入重現精確程式碼模式的測試模組來確認 （alloc skb， kfree_skb，然後讀取 skb_shinfo（skb）->nr_frags）： 錯誤： KASAN：ixgbevf_uaf_test_init+0x100/0x1000 中的 slab-use-after-free 由任務 insmod/30 在 addr 000000006163ae78 讀取大小 8 釋放的 208 位元組區域 [0000000006163adc0， 000000006163ae90） QEMU 模擬 igb （82576），但不模擬 ixgbe （82599）， 並且 igbvf VF 驅動程式不包含 VEPA 來源修剪路徑，因此無法使用模擬硬體進行完整的端到端重現。（CVE-2026-64113）

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

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

  - 已解決 Linux 核心中的下列弱點：net: devmem: reject dma-buf bind with non-page-aligned size or SG length net_devmem_bind_dmabuf() trusts dmabuf->size and sg_dma_len() to be PAGE_SIZE multiples without checking: - tx_vec is sized dmabuf->size / PAGE_SIZE, and net_devmem_get_niov_at() only bounds-checks virt_addr < dmabuf->size before indexing tx_vec[virt_addr / PAGE_SIZE]. With size = N*PAGE_SIZE + r (1 <= r < PAGE_SIZE), sendmsg() at iov_base = N*PAGE_SIZE passes the bound check and reads tx_vec[N] -- one past. - owner->area.num_niovs = len / PAGE_SIZE while gen_pool_add_owner() covers the full byte len, so a non-page-multiple non-final sg desyncs num_niovs from the gen_pool region for every later sg, on both RX and TX. dma-buf does not require page-aligned sizes, so the bind path has to enforce what its own indexing assumes. Reject both with -EINVAL. The size check is TX-only (only tx_vec is sized off dmabuf->size); the SG-length check covers both directions.
    (CVE-2026-64124)

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

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

  - mm/memory：修正取消對應 device-private/exclusive 頁面時的虛假警告 只有匿名對開本支援裝置私有和獨佔項目。使用folio_test_anon（） 在 __migrate_device_pages（） 和 make_device_exclusive（） 中測試此條件。不過，取消對應路徑會使用 vma_is_anonymous（） 來測試此假設。這是錯誤的，因為雖然匿名 VMA 只能包含 folio_test_anon（） 為 true 的對開本，但相反的關係不成立。folio_test_anon（） 為 true 的對開本並不表示 vma_is_anonymous（） 為 true。例如，如果對開本是私人檔案備份對應的一部分，則可能會發生這種情況。在此情況下，vma_is_anonymous（） 為 false，因為對應是檔案備份，但 folio_test_anon（） 可能是 true，因此允許裝置將對開本移轉至裝置私有記憶體。這可能會導致在處理程序拆卸期間出現以下虛假警告： [ 772.737706] ------------[ 切到這裡]------------ [ 772.739201] 警告：mm/memory.c：1754 at unmap_page_range.cold+0x26/0x18a， CPU#17： hmm-tests/2041 [ 772.742050] 連結的模組：test_hmm nvidia_uvm（O） nvidia（O） [ 772.743959] CPU：17 UID：0 PID：2041 Comm：hmm-tests Tainted：G W O 7.0.0+ #387 PREEMPT（full） [ 772.747104] Tainted：[W]=WARN， [O]=OOT_MODULE [ 772.748509] 硬體名稱： QEMU 標準 PC （Q35 + ICH9， 2009）， BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP：
    0010：unmap_page_range.cold+0x26/0x18a [ 772.753780] 代碼： 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP： 0018：ffff888112607550 EFLAGS： 00010286 [772.761310] RAX： ffff88811bbf4dc0 RBX： dffffc00000000000 RCX： ffffea03e9bfffd8 [ 772.763583] RDX：
    1ffff1102377e9c1 RSI：0000000000000008 RDI：ffff88811bbf4e08 [ 772.765914] RBP：0000000000000006 R08：
    ffff8881059f7448 R09： ffffed10224c0e68 [ 772.768184] R10： ffff888112607347 R11： 0000000000000001 R12：
    0000000000000001 [ 772.770461] R13： ffffea03e9bfffc0 R14： ffff888112607908 R15： ffffea03e9bfffc0 [772.772782] FS： 00007f327caa2780（0000） GS：ffff888427b7d000（0000） knlGS：0000000000000000 [ 772.775328] CS：
    0010 DS：0000 ES：0000 CR0：0000000080050033 [ 772.777187] CR2：00007f327ca89000 CR3：00000001994d5000 CR4：0000000000006f0 [ 772.779135] 呼叫追蹤：[ 772.779792] [ <TASK>772.780317] ？ dmirror_interval_invalidate+0x1a3/0x290 [test_hmm] [ 772.781873] ？ vm_normal_page_pud+0x2b0/0x2b0 [772.782992] ？ __rwlock_init+0x150/0x150 [ 772.784006] ？ lock_release+0x216/0x2b0 [ 772.785008] ？
    __mmu_notifier_invalidate_range_start+0x505/0x6e0 [ 772.786522] ？ lock_release+0x216/0x2b0 [ 772.787498] ？ unmap_single_vma+0xb6/0x210 [ 772.788573] unmap_vmas+0x27d/0x520 [ 772.789506] ？ unmap_single_vma+0x210/0x210 [ 772.790607] ？ mas_update_gap.part.0+0x620/0x620 [ 772.791834] unmap_region+0x19e/0x350 [ 772.792769] ？ remove_vma+0x130/0x130 [ 772.793684] ？ mas_alloc_nodes+0x1f2/0x300 [ 772.794730] vms_complete_munmap_vmas+0x8c1/0xe20 [ 772.795926] ？ unmap_region+0x350/0x350 [ 772.796917] do_vmi_align_munmap+0x36a/0x4e0 [ 772.798018] ?lock_release+0x216/0x2b0 [ 772.799024] ？ vma_shrink+0x620/0x620 [ 772.799983] do_vmi_munmap+0x150/0x2c0 [772.800939] __vm_munmap+0x161/0x2c0 [ 772.801872] ？ expand_downwards+0xd60/0xd60 [ 772.802948] ？ clockevents_program_event+0x1ef/0x540 [ 772.804217] ？ lock_release+0x216/0x2b0 [ 772.805158]
    __x64_sys_munmap+0x59/0x80 [ 772.805776] do_syscall_64+0xfc/0x670 [ 772.806336] ？ irqentry_exit+0xda/0x580 [ 772.806976] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 772.807772] RIP： 0033：0x7f327cbb2717 [772.808323] 代碼： 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ---truncated--- （CVE-2026-64131）

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

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

  - drm/msm：修正 iommu_map_sgtable（） 傳回值檢查並避免 WARN 提交 iommu：傳回來自 iommu_map_sg[_atomic]（） 的完整錯誤代碼，變更為 iommu_map_sgtable（） 在錯誤情況下傳回ssize_t值和負值，而不是size_t和零。將傳回值儲存在適當的類型中，如果發生錯誤，請傳回它，而不是 WARNing。拼湊： https://patchwork.freedesktop.org/patch/719685/(CVE-2026-64153）

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

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

  - 已解決 Linux 核心中的下列弱點：ethtool: cmis: require exact CDB reply length Malicious SFP module could respond with rpl_len longer than what cmis_cdb_process_reply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel. The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rpl_exp_len cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling: - cmis_cdb_validate_password() - cmis_cdb_module_features_get() - cmis_fw_update_fw_mng_features_get() so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong... Note that page_data->length (argument of kmalloc) comes from last arg to ethtool_cmis_page_init() which is rpl_exp_len. Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming.
    (CVE-2026-63996)

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

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

  - 已解決 Linux 核心中的下列弱點：ethtool: coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES ethnl_update_profile() walks the ETHTOOL_A_PROFILE_IRQ_MODERATION nest list with an index 'i' and writes new_profile[i++] without bounding i. The destination is kmemdup()'d at NET_DIM_PARAMS_NUM_PROFILES entries (5), but the Netlink nest count is entirely user-controlled. Netlink policies do not have support for constraining the number of nested entries (or number of multi-attr entries). (CVE-2026-63987)

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

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

  - 已解決 Linux 核心中的下列弱點：iommu: Handle unmap error when iommu_debug is enabled Sashiko noticed a latent bug where the map error flow called iommu_unmap() which calls iommu_debug_unmap_begin()/iommu_debug_unmap_end() however since this is an error path the map flow never actually established the original iommu_debug_map() it will malfunction. Lift the unmap error handling into iommu_map_nosync() and reorder it so the trace_map()/iommu_debug_map() records the partial mapping and then immediately unmaps it. This avoid creating the unbalanced tracking and provides saner tracing instead of a unmap unmatched to any map. (CVE-2026-64152)

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

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

  - net： mana：在拆卸路徑中新增 NULL 防護，以防止連接失敗時發生錯誤 當佇列配置中途失敗時，錯誤清除會釋放，並將 apc->tx_qp 和 apc->rxqs 設為 NULL。多個拆卸路徑 （例如 mana_remove（）、mana_change_mtu（） 復原和 mana_alloc_queues（） 中的內部錯誤處理，隨後可以呼叫取消參照這些指標的函數，而無需 NULL 檢查： - mana_chn_setxdp（） 取消參照 apc->rxqs[0]，導致 NULL 指標取消參照錯誤 （CR2：00000000000000000000000000000000000000000000000 在 mana_chn_setxdp+0x26）。- mana_destroy_vport（） 反覆運算 apc->rxqs，而不進行 NULL 檢查。- mana_fence_rqs（） 會反覆運算 apc->rxqs，而不進行 NULL 檢查。- mana_dealloc_queues（） 反覆運算 apc->tx_qp，而不進行 NULL 檢查。
    在 mana_fence_rqs（）、mana_destroy_vport（） 和 mana_chn_setxdp（） 呼叫之前為 apc->rxqs 新增 NULL 保護。在 mana_dealloc_queues（） 中為 apc->tx_qp 新增 NULL 防護，以在從未配置或已釋放 TX 佇列時跳過 TX 佇列清空。（CVE-2026-63973）

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

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

  - 1.3.9c 和 1.3.10rc3 之前的 ProFTPD 在 mod_sftp 模組的 SCP 大小記錄剖析器中包含一個帶正負號的整數溢位弱點，該弱點允許經過驗證的低權限攻擊者透過傳送特製的檔案大小值 UINT64_MAX 來繞過 ASLR，這會導致負off_t值。攻擊者可利用後續轉換為 uint32_t，造成大約 4 GB 的請求讀取長度，並迫使伺服器讀取超出 SSH 通道資料的結尾，並將過度讀取處理程序記憶體寫入上傳的檔案中。在測試的配置中，披露的數據包含足以衍生其隨機基地址的 libc、libcrypto 和 PIE 指標，從而繞過 ASLR 並能夠在同一過程中可靠地利用記憶體損毀漏洞。（CVE-2026-63091）

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

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

  - 已解決 Linux 核心中的下列弱點：netfs: Fix cancellation of a DIO and single read subrequests When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works. Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps: (1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it. (2) Make all three call netfs_queue_read() to do the queuing. (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don't know the length of the subreq at this point. (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq and then call netfs_read_subreq_terminated() to deal with it. This will pass responsibility off to the collector for dealing with it. (CVE-2026-64069)

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

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

  - 已解決 Linux 核心中的下列弱點：vfio/pci: Check BAR resources before exporting a DMABUF A DMABUF exports access to BAR resources and, although they are requested at startup time, we need to ensure they really were reserved before exporting. Otherwise, it's possible to access unreserved resources through the export. Add a check to the DMABUF-creation path. (CVE-2026-64042)

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

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

  - nfc： llcp：修正 nfc_llcp_recv_cc（） 中的釋放後使用爭用） NFC LLCP 連線狀態機器中存在爭用情形，其中連線接受封包 （CC） 可以與通訊端釋放同時處理。這可能會導致通訊端物件的釋放後使用。當 nfc_llcp_recv_cc（） 將通訊端從connecting_sockets清單移至通訊端清單時，它不會保留通訊端鎖定。
    如果 llcp_sock_release（） 同時執行，它可能已經取消連結通訊端並刪除其引用，這可能會導致 nfc_llcp_recv_cc（） 將釋放的通訊端連結到即時清單中。透過在狀態轉換期間按住 lock_sock（） 並在 nfc_llcp_recv_cc（） 中列出移動來解決此問題。取得鎖定之後，請檢查通訊端是否仍處於雜湊狀態，以確保通訊端尚未解除連結，並未被釋放路徑標記為銷毀。這會將鎖定模式與 recv_hdlc（） 和 recv_disc（） 對齊。（CVE-2026-64010）

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

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

  - 已解決 Linux 核心中的下列弱點：uio: uio_pci_generic_sva: fix double free of devm_kzalloc() memory uio_pci_sva allocates struct uio_pci_sva_dev with devm_kzalloc() in probe(), but then calls kfree(udev) both on the probe() error path (label out_free) and again in remove(). Because devm_kzalloc() allocations are devres-managed and are freed automatically when the device is detached (including after a failing probe() and during driver unbind), the explicit kfree() can lead to a double free. If probe() fails after devm_kzalloc(), the error path frees udev and devres cleanup will free it again when the core unwinds the partially bound device. On normal driver removal, remove() frees udev and devres will free it again when the device is detached. This issue was identified by a static analysis tool I developed and confirmed by manual review. Fix by removing the manual kfree() calls and dropping the now-unused label. (CVE-2026-63907)

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

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

  - net： tls：防止純文字中的鏈後鏈 SG Sashiko 指出，如果 end = 0 （start ！= 0），則目前程式碼將在環繞連結之後立即建立內容類型的鏈連結：這將建立一個鏈，其中環繞連結直接指向另一個鏈鏈。散佈清單 API sg_next迭代器不會以遞迴方式解析連續的鏈結。這意味著這是對加密貨幣的非法輸入。如果 end = 0，則不需要包裝連結。end 是最後一個使用的條目之後的條目，因此 end = 0 表示包裝後沒有推送任何內容：end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] 在此情況下，跳過換行。如果 end = 0，則 TLS 1.3 可以使用包裝槽進行鏈結。這避免了鏈條接連。
    在標記 END 和鏈結內容類型之前移動換行鏈結，這對我來說感覺更合乎邏輯的順序，但從功能的角度來看應該無關緊要。（CVE-2026-64046）

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

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

  - 輸入：atmel_mxt_ts - 修正mxt_prepare_cfg_mem中的邊界檢查 當設定檔提供的物件大小大於驅動程式已知的 mxt_obj_size （物件） 時，驅動程式會捨棄額外的位元組。迴圈使用 for （i = 0; i < size; i++） 反覆運算。在迴圈內，跳過處理額外位元組的條件為：if （i > mxt_obj_size（object）） continue;由於 i 是從 0 開始的索引，因此物件的有效索引為 0 到 mxt_obj_size（object） - 1。當 i == mxt_obj_size（object） 時，條件的結果為 false，程式碼會處理位元組而不是丟棄它。這會導致程式碼計算 byte_offset = reg + i - cfg->start_ofs 並將位元組寫入其中，僅覆蓋相鄰實例或物件的一個位元組。更新邊界檢查，以使用 >= 正確跳過額外的位元組。（CVE-2026-63908）

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

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

  - sysfs：更新失敗時不要移除現有目錄 當為具名群組呼叫 sysfs_update_group（） 並且 create_files（） 失敗 （例如 -ENOMEM） 時，internal_create_group（） 會呼叫群組目錄上的 kernfs_remove（kn）。在更新路徑中，kn 是透過 kernfs_find_and_get（） 取得的，指的是在此呼叫之前已經存在的目錄。移除它會以無訊息方式銷毀呼叫端未建立的 sysfs 群組。只有在我們自己建立目錄時才移除目錄。更新失敗時，目錄會保留，因為 create_files（） 內的 remove_files（） 會將其留空，但可以透過重試重新填入。
    (CVE-2026-64185)

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

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

  - net/handshake： 在 net 命名空間結束時清空擱置中的要求 handshake_net_exit（） 中 list_splice_init（） 的引數會反轉。呼叫會將本機空白要求清單移至 hn->hn_requests，讓本機清單留空，因此後續的清空迴圈會執行零反覆專案。當網路命名空間遭到破壞時，尚未接受的擱置交握要求不會被拆除;每一個都會在通訊端檔案和handshake_req配置上保留參照。以記錄的順序傳遞來源和目的地 （list_splice_init（list， head） 將清單移至 head），以便擱置清單會傳輸至本機暫存清單，並透過 handshake_complete（） 清空。修正拼接方向會暴露清單損毀爭用。拼接後，每個 req->hr_list 仍然具有非空連結指標，執行緒堆疊本機暫存清單而不是hn_requests。並行 handshake_req_cancel（） （例如，來自 sunrpc 在未採用 netns 參照的核心通訊端上的 TLS 逾時 — 透過 rhashtable 找到請求，呼叫 remove_pending（），並看到 ！list_empty（&req->hr_list）。然後，__remove_pending_locked（） 會在 drain 迭代時從暫存清單中list_del_init（） 一個項目，從而損壞它。在項目上執行 list_del（） 的排水迴圈之後到達的相同呼叫會改為命中 LIST_POISON。讓 remove_pending（） 檢查 hn_lock 下的HANDSHAKE_F_NET_DRAINING，並在提取進行時報告找不到。排水管已經擁有所有權;handshake_complete（） 在HANDSHAKE_F_REQ_COMPLETED上的現有test_and_set仍然在 drain 和 cancel 之間仲裁誰調用了消費者的hp_done。在排水管中使用 list_del_init（） 而不是 list_del（），以便在排水管釋放入口後 req->hr_list 不會攜帶LIST_POISON。remove_pending（） 中的 DRAINING 防護使 cancel 傳回 false，但 cancel 仍然在 HANDSHAKE_F_REQ_COMPLETED 上落入 test_and_set_bit 並刪除請求的hr_file參照。如果沒有另一個引腳，如果這是最後一個參照，則sk_destruct釋放請求，而請求仍連結在排空迴圈的本機清單上。在釋放清單之前，將每個要求的hr_file釘在hn_lock下，並在迴圈完成要求之後刪除該排空針腳。
    (CVE-2026-63978)

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

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

  - ksmbd：smb_check_perm_dacl（） ACE-walk 迴圈中的 OOB 讀取迴歸 提交 d07b26f39246 （ksmbd：在 smb_check_perm_dacl（）） 中要求最小 ACE 大小） 引入了轉置邊界檢查：if （offsetof（struct smb_ace， sid） + aces_size < CIFS_SID_BASE_SIZE） 由於 offsetof（..sid） 為 8，CIFS_SID_BASE_SIZE 為 8，則計算結果為「aces_size < 0」。因為「aces_size」一律是非負數，所以這個檢查會變成死代碼，而且永遠不會中斷迴圈。更糟糕的是，該提交刪除了舊的 4 位元組保護，這意味著即使 'aces_size' 是 0-3 位元組，循環現在也會讀取 'ace->size'（偏移量 2）。這會在後續SMB2_CREATE作業期間重新開啟 2 位元組堆積越界 （OOB） 讀取，越過 pntsd 配置。透過正確轉置比較以需要至少 16 個位元組 （8 位元組位移 + 8 位元組 SID 基數），以符合 smb_inherit_dacl（） 中使用的正確形式來解決此問題。（CVE-2026-63909）

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

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

  - 已解決 Linux 核心中的下列弱點：zram: fix use-after-free in zram_writeback_endio A crash was observed in zram_writeback_endio due to a NULL pointer dereference in wake_up. The root cause is a race condition between the bio completion handler (zram_writeback_endio) and the writeback task. In zram_writeback_endio, wake_up() is called on &wb_ctl->done_wait after releasing wb_ctl->done_lock. This creates a race window where the writeback task can see num_inflight become 0, return, and free wb_ctl before zram_writeback_endio calls wake_up(). CPU 0 (zram_writeback_endio) CPU 1 (writeback_store) ============================ ============================ zram_writeback_slots zram_submit_wb_request zram_submit_wb_request wait_event(wb_ctl->done_wait) spin_lock(&wb_ctl->done_lock);
    list_add(&req->entry, &wb_ctl->done_reqs); spin_unlock(&wb_ctl->done_lock); wake_up(&wb_ctl->done_wait);
    zram_complete_done_reqs spin_lock(&wb_ctl->done_lock); list_add(&req->entry, &wb_ctl->done_reqs);
    spin_unlock(&wb_ctl->done_lock); while (num_inflight) > 0) spin_lock(&wb_ctl->done_lock);
    list_del(&req->entry); spin_unlock(&wb_ctl->done_lock); // num_inflight becomes 0 atomic_dec(num_inflight); // Leave zram_writeback_slots // Free wb_ctl release_wb_ctl(wb_ctl); // UAF crash! wake_up(&wb_ctl->done_wait); This patch fixes this race by using RCU. By protecting wb_ctl with rcu_read_lock() in zram_writeback_endio and using kfree_rcu() to free it, we ensure that wb_ctl remains valid during the execution of zram_writeback_endio. (CVE-2026-63951)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/amdgpu/vcn: set no_user_fence for VCN v5.0.0 enc ring VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 49b1fbbb5a071197ee71e2d70959b1cb29bdc317) (CVE-2026-63850)

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

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

  - btrfs：追蹤點：在 btrfs_sync_file（） 中修正處於原子上下文時的睡眠 追蹤事件 btrfs_sync_file（） 在不可部分完成的上下文中調用 （所有追蹤事件都是），並且由於調用 dget_parent（） 而需要對 dput（） 的呼叫，可以休眠，從而觸發核心 splat。例如，啟用追蹤事件並從 fstests 執行 btrfs/056，即可重現此問題。dmesg 中顯示的 splat 如下： [53.919] 錯誤：從 fs/dcache.c：970 的無效內容呼叫休眠函式 [53.947] in_atomic（）：1， irqs_disabled（）：0，non_block：0，pid：32773，名稱：xfs_io [53.988] preempt_count：2，預期：0 [53.967] RCU 巢狀深度：0，預期：0 [53.943] 在以下位置停用搶佔：[53.944] [<0000000000000000>] 0x0 [54.078] CPU：0 UID：0 PID：32773 通訊：xfs_io 受污染： G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT（full） [54.070] Tainted： [W]=WARN [54.071] 硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] 呼叫追蹤： [54.074] [54.076] <TASK> dump_stack_lvl+0x56/0x80 [54.079] __might_resched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs] [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs] [54.087] ？ __handle_mm_fault+0x8ae/0xed0 [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs] [54.091] vfs_write+0x21f/0x450 [54.094]
    __x64_sys_pwrite64+0x8d/0xc0 [54.096] ？ do_user_addr_fault+0x20c/0x670 [54.099] do_syscall_64+0x60/0xf20 [54.092] ？ clear_bhb_loop+0x60/0xb0 [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e 因此，請停止使用 dget_parent（） 和 dput（），並以 dentry->d_parent 直接存取父 dentry。這也是 ext4 在其等效追蹤事件 ext4_sync_file_enter（） 中所做的。（CVE-2026-64164）

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

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

  - 已解決 Linux 核心中的下列弱點：ethtool: cmis: validate start_cmd_payload_size from module The CMIS firmware update code reads start_cmd_payload_size from the module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. The destination buffer is 112 bytes (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious module (or corrupted response) can cause a OOB write later on in cmis_fw_update_start_download(). Let's error out. If modules that expect longer LPL writes actually exist we should revisit. struct cmis_cdb_start_fw_download_pl's definition has to move, no change there. (CVE-2026-63995)

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

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

  - net/handshake：對 hn_lock nvmet_tcp_state_change（） 使用 spin_lock_bh，這是一種在 BH 上下文中運行的通訊端回呼，可以透過 nvmet_tcp_schedule_release_queue（） 和 tls_handshake_cancel（） 到達 handshake_req_cancel（）。handshake_req_cancel（） 會取得具有純 spin_lock（） 的 hn->hn_lock。如果當 softirq 叫用取消路徑時，相同 CPU 上的處理程序內容執行緒保留 hn->hn_lock，則鎖定嘗試會鎖死。這是唯一從 BH 上下文叫用 tls_handshake_cancel（） 的呼叫端;其他所有消費者都從進程內容呼叫它。將取消延遲到 NVMe 目標中的處理上下文並不簡單：nvmet_tcp_schedule_release_queue（） 必須自動調用 tls_handshake_cancel（），並將其狀態轉換為 DISCONNECTING。如果取消延遲，交握完成回呼可能會在取消執行之前在視窗中觸發、觀察非預期的狀態，並返回，而不會將其 kref 放在佇列上。重新設計該聯鎖比強化握手鎖更具侵入性。將所有 hn->hn_lock 獲取從 spin_lock/spin_unlock 轉換為 spin_lock_bh/spin_unlock_bh這樣就永遠不會在啟用 softirq 的情況下進行鎖定。（CVE-2026-63980）

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

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

  - bpf： sockmap：修正 bpf_msg_push_data 中的尾部片段偏移 當 bpf_msg_push_data（） 在散點清單項目中間插入資料時，它會將原始項目拆分為左側片段和右側片段。正確的片段位移量是頁面本機，但程式碼會使用「start」來推進它，這是訊息全域插入點。對於插入到非第一個 SG 項目中，這會過度推進偏移，並使分割配置不一致。將右側片段偏移量前推進片段本機增量「開始 - 偏移量」，該差異與從原始項目前面移除的長度相符。（CVE-2026-63926）

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

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

  - wifi： ath11k：修正某些 WMI WOW 呼叫中的錯誤路徑洩漏 修正我們過去直接傳回 ath11k_wmi_cmd_send（...） 結果的兩個實例。因為我們沒有檢查傳回值，所以我們也沒有釋放錯誤路徑中的 skb。（CVE-2026-64155）

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

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

  - 已解決 Linux 核心中的下列弱點：drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm() There is a unbalanced lock/unlock to gpusvm notifier lock: [ 931.045868] ===================================== [ 931.046509] WARNING: bad unlock balance detected! [ 931.047149] 6.19.0-rc6+xe-**************** #9 Tainted: G U [ 931.048150] ------------------------------------- [931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at: [ 931.049801] [<ffffffffa090c0d8>] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper] [ 931.050802] but there are no more locks to release! [ 931.051463] The drm_gpusvm_notifier_unlock() sits under err_free label and the first jump to err_free is just before calling the drm_gpusvm_notifier_lock() causing unbalanced unlock.
    (CVE-2026-63863)

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

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

  - drm/i915：修正 TTM 物件清除中潛在的 UAF TLDR：bo->ttm 物件可以透過呼叫 ttm_bo_validate（） 來更改，稍後將其轉換為 i915_tt 物件以實際取得正確的指標。一位使用者報告在 DG2 上大量使用時遇到了以下錯誤： [26620.095550] 哎呀：一般保護錯誤，可能是因為非規範位址 0xa56b6b6b6b6b6b8b：0000 1 SMP NOPTI [26620.095556] CPU：2 UID：0 PID：
    631 通訊：Xorg 未受 6.18.8 #1 污染 PREEMPT（lazy） [26620.095558] 硬體名稱：華擎 B850M Steel Legend WiFi/B850M Steel Legend WiFi，BIOS 3.50 09/18/2025 [26620.095559] RIP：0010：i915_ttm_purge+0x84/0x100 [i915] [26620.095604] 代碼：00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 <48> 8b 78 20 48c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP： 0018：ffffc90005fd7430 EFLAGS：00010282 [26620.095607] RAX：a56b6b6b6b6b6b6b6b RBX：ffff8881f46c3dc0 RCX：0000000000000000000 [26620.095608] RDX：000000000000000000 RSI：0000000000000246 RDI：00000000ffffffff [26620.095609] RBP：ffff888289610f00 R08：0000000000000001 R09：ffff88823b022000 [26620.095609] R10：ffff888103029b28 R11：ffff8881fc7f3800 R12：ffff88810b6150d0 [26620.095609] R13：
    ffff888289610f00 R14： 000000000000000000 R15： ffff8881f46c3dc0 [26620.095610] FS： 00007f1004d86900（0000） GS：ffff88901c858000（0000） knlGS：000000000000000000 [26620.095611] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [26620.095611] CR2： 00007f0fdf489000 CR3： 000000035b0c1000 CR4： 0000000000750ef0 [26620.095612] PKRU： 55555554 [26620.095612] 呼叫追蹤： [26620.095615] [26620.095615] <TASK> i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ？ ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ？ i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ？ preempt_count_add+0x64/0xa0 [26620.095673] ？
    _raw_spin_lock+0xe/0x30 [26620.095675] ？ _raw_spin_unlock+0xd/0x30 [26620.095675] ？ i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ？ init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ？
    _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ？ i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ？ alloc_debug_processing+0xd0/0x100 [26620.095787] ？ _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ？ i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ？ i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ？ alloc_debug_processing+0xd0/0x100 [26620.095954] ？ _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ？ i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ？ __wake_up_sync_key+0x32/0x50 [26620.095979] ？ i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ？ __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] decode_stacktrace.sh 的結果指向 i915 TTM 頁面向量容器的檔案指標欄位解除參照，該容器與逐出時要清除的物件相關聯。當物件標示為不再需要時，會採用該路徑。程式碼分析顯示，如果 i915 TTM 頁面向量容器仍然忙碌，則可能會被清除物件內容的函式內的新實例取代。透過更通用的函式間接呼叫該函式，該函式會變更物件的放置和快取原則 ---truncated--- （CVE-2026-63884）

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

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

  - 已解決 Linux 核心中的下列弱點：wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled When the TLC notification disables AMSDU for a TID, the MLD driver sets max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in iwl_mld_tx_tso_segment() checks for zero but not for this sentinel, allowing it to reach the num_subframes calculation: num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad) = (1 + 2) / (1534 + 2) = 0 This zero propagates to iwl_tx_tso_segment() which sets: gso_size = num_subframes * mss = 0 Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny segments from a single GSO skb. This floods the TX ring with ~1024 micro-frames (the rest are purged), creating a massive burst of TX completion events that can lead to memory corruption and a subsequent use-after-free in TCP's retransmit queue (refcount underflow in tcp_shifted_skb, NULL deref in tcp_rack_detect_loss). The MVM driver is immune because it checks mvmsta->amsdu_enabled before reaching the num_subframes calculation. The MLD driver has no equivalent bitmap check and relies solely on max_tid_amsdu_len, which does not catch the sentinel value.
    Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the existing check and falling back to non-AMSDU TSO segmentation. Also add a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth to catch any future code paths that produce zero through a different mechanism. (CVE-2026-64037)

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: SEV: Compute the correct max length of the in-GHCB scratch area When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer. The code was fine when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the *max* size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert). Opportunistically rename @len => @min_len to better reflect its role.
    (CVE-2026-63939)

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

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

  - ipv6：修正 rt6_fill_node（） 中可能的無限迴圈 Sashiko 報告了此問題 [1]。套用與提交 f8d8ce1b515a 相同的修正 （ipv6：修正 fib6_info_uses_dev（）） 中可能的無限迴圈）。持有tb6_lock的寫入器可以list_del_rcu（&rt->fib6_siblings），而無需等待 RCU 讀取器;rt->fib6_siblings.next 仍然指向舊環，並且此 softirq 側行者永遠不會到達 &rt->fib6_siblings，從而導致 CPU 停止。fib6_del_route（） 總是在 list_del_rcu（） 之前將 WRITE_ONCE（） 的 rt->fib6_nsiblings 為 0，因此環內檢查是可靠的分離信號。[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev （CVE-2026-63969）

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

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

  - 藍牙：ISO：在取得 lock_sock（sk） 之前，使用通訊端鎖定 iso_sock_close（） 呼叫 iso_sock_clear_timer（） 序列化iso_sock_clear_timer。iso_sock_clear_timer（） 在未持有通訊端鎖定的情況下讀取 iso_pi（sk）->conn 兩次：if （！iso_pi（sk）->conn） return;
    cancel_delayed_work（&iso_pi（sk）->conn->timeout_work）;同時，iso_conn_del（） 在 lock_sock（sk） 下執行並調用 iso_chan_del（），這會將 iso_pi（sk）->conn 設定為 NULL，並可能導致對連線的最終參照被丟棄： CPU0 CPU1 ---- ---- iso_sock_clear_timer（） if （conn ！= NULL） ...lock_sock（sk） iso_chan_del（） iso_pi（sk）->conn = NULL cancel_delayed_work（conn） /* NULL 解除參照或 UAF */ iso_pi（sk）->conn 在整個解鎖視窗中不穩定，導致 NULL 指標解除參照或釋放後使用。透過將通訊端鎖定 iso_sock_clear_timer（） 移動到 lock_sock（）/release_sock（） 內，與 iso_conn_del（） 和所有其他呼叫網站中使用的模式相符，以序列化通訊端鎖定。
    (CVE-2026-63945)

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

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

  - net/tcp-ao：修正del_async路徑中金鑰的釋放後使用 在 tcp_ao_delete_key（） 中，del_async路徑會跳過同步路徑中存在的current_key和rnext_key有效性檢查，假設這些指標在 LISTEN 通訊端上一律為 NULL。但是，如果在通訊端處於 CLOSE 狀態時以 set_current=1/set_rnext=1 新增金鑰，則在 listen（） 將通訊端轉換為 LISTEN 之後，current_key 和 rnext_key 將為非 NULL。當以 del_async=1 刪除此類金鑰時，hlist_del_rcu（） 和 call_rcu（） 釋放金鑰，而不清除懸空指標。在 RCU 寬限期過後，getsockopt（TCP_AO_INFO） 會從釋放的 slab 記憶體解除參照 current_key->sndid 和 rnext_key->rcvid。當current_key和rnext_key參照要刪除的金鑰時，清除del_async路徑中的它們。（CVE-2026-53389）

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

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

  - 9p：避免將 oldfid 放入 p9_client_walk（） 錯誤路徑 當呼叫 p9_client_walk（） 並將 clone 設定為 false 時，fid 會別名 oldfid。如果在傳送要求之後逐步執行失敗，錯誤路徑會跳至目前無條件呼叫 p9_fid_put （fid） 的 clunk_fid。這會刪除對 oldfid 的引用，即使 oldfid 的所有權仍屬於調用方。如果這是最後一個參照，則 oldfid 可能會被 clunk 並銷毀，而調用方仍期望它有效。稍後使用或放置 oldfid 可能會觸發釋放後使用或參照計數下溢。修正此問題，方法是僅在 fid 未別名 oldfid 時才將 fid 放入clunk_fid錯誤路徑中，以符合以下錯誤路徑中的現有防護。當多元件遍歷被分割成多個 p9_client_walk（） 呼叫並且隨後的非複製遍歷失敗時，可能會觸發此問題。可應要求提供重現器和參照計數警告日誌。（CVE-2026-63795）

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

ID	名稱	嚴重性
328257	Linux Distros 未修補弱點：CVE-2026-64179	medium
328256	Linux Distros 未修補弱點：CVE-2026-63891	medium
328255	Linux Distros 未修補弱點：CVE-2026-64095	high
328254	Linux Distros 未修補弱點：CVE-2026-64091	critical
328253	Linux Distros 未修補弱點：CVE-2026-63898	high
328252	Linux Distros 未修補弱點：CVE-2026-63982	medium
328251	Linux Distros 未修補弱點：CVE-2026-64099	high
328250	Linux Distros 未修補弱點：CVE-2026-63964	medium
328249	Linux Distros 未修補弱點：CVE-2026-63880	medium
328248	Linux Distros 未修補弱點：CVE-2026-64161	medium
328247	Linux Distros 未修補弱點：CVE-2026-64096	high
328246	Linux Distros 未修補弱點：CVE-2026-64086	high
328245	Linux Distros 未修補弱點：CVE-2026-64169	medium
328244	Linux Distros 未修補弱點：CVE-2026-64047	critical
328243	Linux Distros 未修補弱點：CVE-2026-63900	high
328242	Linux Distros 未修補弱點：CVE-2026-63952	high
328241	Linux Distros 未修補弱點：CVE-2026-63956	high
328240	Linux Distros 未修補弱點：CVE-2026-64113	critical
328239	Linux Distros 未修補弱點：CVE-2026-64124	high
328238	Linux Distros 未修補弱點：CVE-2026-64131	high
328237	Linux Distros 未修補弱點：CVE-2026-64153	high
328236	Linux Distros 未修補弱點：CVE-2026-63996	high
328235	Linux Distros 未修補弱點：CVE-2026-63987	high
328234	Linux Distros 未修補弱點：CVE-2026-64152	high
328233	Linux Distros 未修補弱點：CVE-2026-63973	medium
328232	Linux Distros 未修補弱點：CVE-2026-63091	high
328231	Linux Distros 未修補弱點：CVE-2026-64069	critical
328230	Linux Distros 未修補弱點：CVE-2026-64042	high
328229	Linux Distros 未修補弱點：CVE-2026-64010	high
328228	Linux Distros 未修補弱點：CVE-2026-63907	high
328227	Linux Distros 未修補弱點：CVE-2026-64046	critical
328226	Linux Distros 未修補弱點：CVE-2026-63908	medium
328225	Linux Distros 未修補弱點：CVE-2026-64185	medium
328224	Linux Distros 未修補弱點：CVE-2026-63978	critical
328223	Linux Distros 未修補弱點：CVE-2026-63909	high
328222	Linux Distros 未修補弱點：CVE-2026-63951	high
328221	Linux Distros 未修補弱點：CVE-2026-63850	high
328220	Linux Distros 未修補弱點：CVE-2026-64164	medium
328219	Linux Distros 未修補弱點：CVE-2026-63995	high
328218	Linux Distros 未修補弱點：CVE-2026-63980	high
328217	Linux Distros 未修補弱點：CVE-2026-63926	high
328216	Linux Distros 未修補弱點：CVE-2026-64155	high
328215	Linux Distros 未修補弱點：CVE-2026-63863	high
328214	Linux Distros 未修補弱點：CVE-2026-63884	high
328213	Linux Distros 未修補弱點：CVE-2026-64037	critical
328212	Linux Distros 未修補弱點：CVE-2026-63939	critical
328211	Linux Distros 未修補弱點：CVE-2026-63969	medium
328210	Linux Distros 未修補弱點：CVE-2026-63945	high
328209	Linux Distros 未修補弱點：CVE-2026-53389	high
328208	Linux Distros 未修補弱點：CVE-2026-63795	critical

偵測

Nessus 的 Misc. 系列

medium

medium

high

critical

high

medium

high

medium

medium

medium

high

high

medium

critical

high

high

high

critical

high

high

high

high

high

high

medium

high

critical

high

high

high

critical

medium

medium

critical

high

high

high

medium

high

high

high

high

high

high

critical

critical

medium

high

high

critical