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

  - riscv：無條件修正錯誤 compat_riscv_gpr_set（） 呼叫 cregs_to_regs（） 時未初始化 creg 的暫存器損毀，即使 user_regset_copyin（） 失敗也是如此。由於 cregs 是未初始化的堆疊變數，因此 copyin 失敗會導致未初始化的堆疊資料被寫入目標任務的pt_regs中，從而損壞其暫存器狀態並可能洩露核心堆疊內容。
    compat_restore_sigcontext（） 也有同樣的問題：即使 __copy_from_user（） 失敗，它也會呼叫 cregs_to_regs（），導致錯誤時訊號傳回任務的暫存器狀態同樣損毀。只有在使用者複製成功時才呼叫 cregs_to_regs（）。（CVE-2026-64082）

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

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

  - cgroup/rstat：在 css_rstat_cpu（） 存取 css_rstat_updated（） 公開為 BPF kfunc 並接受呼叫端提供的 CPU 引數之前，先驗證 CPU。此函式使用 cpu 進行 per-cpu rstat 查詢，而不檢查它是否參照有效的可能 CPU。具有 CAP_BPF 和 CAP_PERFMON 的 BPF iter/cgroup 程式可能會傳遞無效的 cpu 值。在未固定的 UBSCAN_BOUNDS 測試核心上，cpu == 0x7fffffff 觸發： UBSAN： array-index-out-of-bounds 在 kernel/cgroup/rstat.c：31：9 索引中，2147483647超出類型「long unsigned int [64]」的範圍 呼叫追蹤： css_rstat_updated bpf_iter_run_prog cgroup_iter_seq_show bpf_seq_read 將 cpu 驗證新增至面向 BPF 的 css_rstat_updated（） kfunc，並將通用實作移至
    __css_rstat_updated（） 用於核心內呼叫端。（CVE-2026-64036）

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

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

  - netfs：修正 netfs_read_folio（） 以等候回寫 修正 netfs_read_folio（） 以等待進行中的回寫完成，以便它可以信任已變更旗標以及附加至 Folio->private 的任何內容 （Folio->private 可能會在清除回寫旗標之前被收集器清除）。（CVE-2026-64058）

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

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

  - ksmbd：修正溢位時 set_posix_acl_entries_dacl（） 中的 SID 記憶體洩漏 提交 299f962c0b02 （ksmbd：使用 check_add_overflow（） 來防止 u16 DACL 大小溢位） 新增了 check_add_overflow（） 防護，當累積的 DACL 大小換行超過 65535 時，這些保護會突破 set_posix_acl_entries_dacl（） 中的 ACE 建置迴圈。然而，每次迭代都會透過迴圈頂部的 kmalloc_obj（） 分配一個結構smb_sid，並依賴迴圈主體末尾的 kfree（sid） 調用（第一個迴圈中的 'pass_same_sid' 標籤，以及第二個迴圈尾部的顯式 kfree）來釋放它。新引入的 'break' 語句繞過了這些 kfree（） 調用，每次偵測到溢位時都會洩漏 sid 緩衝區。具有足夠 POSIX ACL 項目以觸發溢位檢查的惡意或格式錯誤的檔案，會在每個接觸檔案 DACL 的要求上洩漏一或多個結構smb_sid配置，從而提供微不足道的核心記憶體耗盡向量。在脫離迴路以堵塞洩漏之前釋放 sid。（CVE-2026-64139）

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

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

  - ipv6： exthdrs：在遍歷 IPv6 TLV 時，處理 NH 中的 HAO 選項 ip6_parse_tlv（） 快取 skb_network_header（skb） 後重新整理 nh。 ipv6_dest_hao（） 可能會針對複製的 skb 呼叫 pskb_expand_head（），這可能會移動 skb 頭並使快取的網路標頭指標失效。在 ipv6_dest_hao（） 傳回後重新整理 nh，以便從目前的 skb 頭剖析任何尾端填充或 TLV。這符合 ip6_parse_tlv（） 中可以修改 skb 標頭儲存的協助程式之後使用的現有模式。（CVE-2026-63922）

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

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

  - drm/virtio：使用不中斷的 resv 鎖進行平面更新 virtio_gpu_cursor_plane_update（） 和 virtio_gpu_resource_flush（） 透過 virtio_gpu_array_lock_resv（） 鎖定影像緩衝區 BO 的dma_resv，並忽略其傳回值。函式可能會因 dma_resv_lock_interruptible（） 的 -EINTR （鎖定等候期間的訊號） 或來自 dma_resv_reserve_fences（） 的 -ENOMEM （柵欄插槽配置） 而失敗，而未保留 resv 鎖定。然後，佇列路徑遍歷物件陣列並呼叫 dma_resv_add_fence（），這需要持有鎖定;啟用 lockdep 後，此行程 dma_resv_assert_held（）： 警告：drivers/dma-buf/dma-resv.c：296 在 dma_resv_add_fence+0x71e/0x840 呼叫追蹤：virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl 在 WARN 之外，在沒有鎖定的情況下變異dma_resv柵欄清單會與並行讀取器/寫入器爭用，並可能損毀清單。這兩個呼叫站點都在.atomic_update平面回呼中執行，DRM 不可部分完成協助程式不允許失敗 （當它執行時，提交已簽核到使用者空間，並且沒有乾淨的復原路徑）。拒絕將鎖定取得移至 .prepare_fb，因為更廣泛的鎖定範圍會針對相同不可部分完成確定中的其他 BO 鎖定路徑鎖死。引入使用 dma_resv_lock（） 而不是 dma_resv_lock_interruptible（） 的 virtio_gpu_lock_one_resv_uninterruptible（）。這消除了 -EINTR 故障模式——現實的 syzbot 觸發器
    -- 而不在提交中延伸鎖定保留。協助程式鎖定單一 BO 並拒絕具有 -EINVAL > 1 的 nents;兩個修正網站都只鎖定一個 BO。從 virtio_gpu_cursor_plane_update（） 和 virtio_gpu_resource_flush（） 使用它;檢查傳回值以處理 dma_resv_reserve_fences（） 中剩餘的 -ENOMEM 案例，方法是釋放 objs 並跳過該框架的平面更新。此處觸及的影像緩衝區 BO 不會與其他內容共用，而且鎖定爭用預期會很短暫，因此訊號中斷性的損失是可以接受的。virtio_gpu_array_lock_resv（） （ioctl 路徑） 的其他呼叫端會繼續使用可中斷的變體。該錯誤是由 syzbot 報告的，它是透過DRM_IOCTL_MODE_CURSOR路徑上的錯誤插入 （fail_nth） 觸發的，這會強制在 dma_resv_reserve_fences（） 中使用 -ENOMEM 分支。（CVE-2026-64098）

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

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

  - hwmon：（lm90） 在釋放 hwmon 裝置之前停止工作 Sashiko 報告： 在 lm90_probe（） 中，取消 alert_work 和 report_work （lm90_restore_conf） 的 devm 動作在呼叫 devm_hwmon_device_register_with_info（） 之前在 lm90_init_client（） 中註冊。由於 devm 會在模組解除綁定或探查失敗期間以相反的順序執行清理動作，因此會先取消註冊並釋放 hwmon 裝置。如果 lm90_alert_work（） 或 lm90_report_alarms（） 在釋放 hwmon 裝置和取消延遲工作之間的視窗中運行，則 lm90_update_alarms（） 將在此處取消參照釋放的資料>hwmon_dev。在註冊 hwmon 裝置之後、註冊中斷處理常式之前，分別取消背景工作角色，以修正此問題。這可確保在停用中斷之後、釋放 hwmon 裝置之前取消背景工作角色。新增關機旗標以指示裝置關機正在進行中，以防止背景工作者被重新武裝。（CVE-2026-64038）

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

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

  - ksmbd：在 ACL 繼承期間驗證父安全性描述元中的 SID 引入 smb_validate_ntsd_sid（） 協助程式，以安全地驗證從父目錄擷取的 NT 安全性描述元 （smb_ntsd） 內的擁有者 SID 和群組 SID。（CVE-2026-64138）

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

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

  - 藍牙：hci_sync：設定裝置關閉時的HCI_CMD_DRAIN_WORKQUEUE由於現在可以在重置路徑期間呼叫hci_dev_close_sync（），因此我們也應該設定HCI_CMD_DRAIN_WORKQUEUE。這可避免在清空 hdev 工作佇列時佇列逾時。（CVE-2026-63974）

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

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

  - KVM： SEV：忽略長度為「0」的連接埠 I/O 要求 明確忽略長度為「0」（或計數為「0」）的連接埠 I/O 要求，以便設定軟體暫存區域 （和其他程式碼） 不必擔心長度下溢，並允許在嘗試使用 len==0 配置暫存區域時發出警告。
    (CVE-2026-63940)

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

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

  - batman-adv： tp_meter：修正接收器關機中的tp_vars參照洩漏 接收器關機計時器處理常式 batadv_tp_receiver_shutdown（） 負責釋放它所持有的tp_vars參照。然而，將此版本與 batadv_tp_stop_all（） 協調的現有邏輯存在缺陷。timer_shutdown_sync（） 保證計時器在傳回後不會再次觸發，但只有在呼叫時計時器處於擱置狀態時，才會傳回非零。如果計時器已經過期（並且 batadv_tp_stop_all（） 會嘗試重新武裝自己，則 batadv_tp_stop_all（） 會跳過其 batadv_tp_vars_put（），並且 batadv_tp_receiver_shutdown（） 也無法放置自己的引用。透過引入一個新的原子變數接收來解決這個問題，當接收器被初始化並由先聲明它的一方使用 atomic_xchg（） 以原子方式清除時，該變數設定為 1。只有觀察到 1 到 0 轉換的一方才負責釋放tp_vars計時器參考，從而消除不確定性。（CVE-2026-64092）

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

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

  - net/sched：當重複開啟時，修正 netem 上的封包迴圈 當 netem 複製封包時，它會在根 qdisc 上重新將副本排入佇列。如果樹狀結構中存在另一個 netem，則可以再次複製副本，重複執行，直到堆疊或記憶體耗盡為止。原始重複防護暫時將重新排入佇列的 q->duplicate 歸零，但這並不能涵蓋所有情況，因為它是在所有並行排入佇列路徑之間共用的 per-qdisc 狀態，如果沒有額外的鎖定，則不安全。使用先前修補程式中引入的 skb tc_depth欄位： - 在重新排入佇列之前在重複項上將其遞增 - 對於任何tc_depth已經非零的 skb，跳過重複。這會標示封包本身，而不是改變 qdisc 狀態，因此無論樹狀結構拓撲或並發性如何，它都是安全的。（CVE-2026-63983）

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

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

  - netfs：修正零點更新，其中 i_size > remote_i_size 當頁面快取中除了要發行的作品集之外還有未提交的資料，但伺服器上的 EOF 在此作品集 （即 i_size > remote_i_size） 中時，修正 netfs_release_folio（） 對零點 [*] 的更新。更新需要將zero_point限制為remote_i_size，而不是i_size，因為i_size是一種本地現象，反映了本地對頁面緩存所做的更新，而不是寫入服務器的內容。remote_i_size會追蹤伺服器的i_size。[*]零點是檔案位置，我們可以從中假設伺服器只會傳回零，因此我們可以避免產生讀取。請注意，netfs_invalidate_folio（） 可能不需要修復，因為zero_point應該在截斷或 fallocate 後由 setattr 更新。找到：fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops 使用下列內容作為 junk.fsxops： 使用預設快取選項截斷0x0 0x1bbae 0x82864寫入0x3ef2e 0xf9c8 0x1bbae寫入0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copy_range 0x5d3d 0x10329 0x54fac 0x7495f寫0x64710 0x1c2b 0x7495f入 mapread 0x64000 0x1000 0x7495f。如果 netfs_perform_write（） 中註釋掉FMODE_READ檢查，它會顯示對開本0x64上的讀取間隙，這些讀取因短讀取而失敗（即命中 EOF）：if （//（file->f_mode &; FMODE_READ） || netfs_is_cache_enabled（ctx）） { 且沒有 fscache。這最初是在 generic/522 xfstest 中發現的。（CVE-2026-64159）

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

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

  - KVM：arm64：vgic-its：拒絕具有超出範圍的還原 DTE num_eventid_bits使用者空間可以還原 ITS 裝置資料表項目，其 Size 欄位編碼的 EventID 位元數量超過虛擬 ITS 支援的 EventID 位元。即時 MAPD 路徑會拒絕該狀態，但 vgic_its_restore_dte（） 會接受該狀態，並將超出範圍的值儲存在 dev->num_eventid_bits 中。在配置裝置之前，請先拒絕具有 num_eventid_bits > VITS_TYPER_IDBITS 還原的 DTE。這反映了 MAPD 檢查並防止還原狀態達到 vgic_its_restore_itt（），其中未檢查的值可以轉換為過大的 scan_its_table（） 範圍。（CVE-2026-64106）

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

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

  - drm/msm/adreno：修正 a6xx_gpu_init（） 中的參照洩漏 在 a6xx_gpu_init（） 中，節點是透過 of_parse_phandle（） 取得的。雖然在通用路徑的末端有一個手動 of_node_put（），但幾個早期的錯誤傳回會繞過此調用，從而導致參照洩漏。透過使用
    __free（device_node） 清除處理常式，以在變數超出範圍時釋放參照。
    拼湊 https://patchwork.freedesktop.org/patch/700661/ ：（CVE-2026-64154）

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

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

  - erofs：修正 inode xattr 初始化提交 bb88e8da0025 （erofs：將中繼緩衝區用於 xattr 作業） 中的 metabuf 洩漏，已將 xattr 作業轉換為使用堆疊上erofs_buf執行個體。
    erofs_init_inode_xattrs（） 在讀取內嵌 xattr 標頭和共用 xattr id 陣列時使用此類 metabuf。erofs_read_metabuf（） 之後的某些錯誤路徑會通過 out_unlock 離開，而不會刪除 metabuf，因此對開本參照可能會洩露。在out_unlock合併清理作業。如果未取得任何對開本，則 erofs_put_metabuf（） 是無操作，這會保留單一清理網站涵蓋EROFS_I_BL_XATTR_BIT之後的所有路徑。（CVE-2026-64146）

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

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

  - netfilter： bridge： eb_tables：關閉模組 init 爭用 sashiko 報告不相關的修補程式： ebtables.c 中的核心 ebtables 初始化是否遭受類似的爭用？一旦 nf_register_sockopt（） 完成，sockopts 就會全域公開。sockopt 必須最後註冊，就像在 ip/ip6/arptables 中一樣。
    (CVE-2026-64076)

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

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

  - net/smc：拒絕符合空白 ism_dev 插槽的 CHID-0 ACCEPT 在 SMC-D 用戶端上，ini->ism_dev[]/ini->ism_chid[] 的插槽 0 保留給 SMC-Dv1 裝置。 smc_find_ism_v2_device_clnt（） 會填入從索引 1 開始的 V2 項目，因此未選取 V1 裝置時，插槽 0 會保留其 kzalloc（） 的狀態，且為 ism_dev[0] == NULL 且 ism_chid[0] == 0。 smc_v2_determine_accepted_chid（） 接著會符合對等體的CHID 針對從索引 0 開始的陣列，僅使用 CHID 。以 d1.chid == 0 回覆僅限 SMC-Dv2 提案的惡意對等體符合空白插槽，ini->ism_selected 變為 0，後續的 smc_conn_create（） 錯誤 ism_dev[0]->lgr_lock 解除參照 offsetof（struct smcd_dev， lgr_lock） == 0x68： 錯誤： KASAN：_raw_spin_lock_bh+0x79/0xe0 中的 null-ptr-deref 在 add 0000000000000068 r 處寫入大小為 4 的寫入，由任務 exploit/144 呼叫追蹤： _raw_spin_lock_bh smc_conn_create （net/smc/smc_core.c：1997） __smc_connect （net/smc/af_smc.c：1447） smc_connect （net/smc/af_smc.c：1720）
    __sys_connect __x64_sys_connect do_syscall_64 在接受 CHID 相符專案之前，要求 ism_dev[i] 為非 NULL。（CVE-2026-64048）

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

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

  - netfilter： x_tables：在互斥 arp/ip（6）t_register_table（） 下分配鉤子操作時，通過 xt_register_table（） 將表添加到 per-netns 列表中，然後再通過 kmemdup_array（） 分配 per-netns hook 操作副本。
    這會留下一個視窗，其中表格在 ops=NULL 的清單中可見。如果 pernet 退出同時執行，則 pre_exit 回呼會透過 xt_find_table（） 找到該表，並將 NULL 操作指標傳遞給 nf_unregister_net_hooks（），從而導致 NULL 解除參照： nf_unregister_net_hooks+0xbc/0x150 中的一般保護錯誤 RIP：nf_unregister_net_hooks （net/netfilter/core.c：613） 呼叫追蹤：
    ipt_unregister_table_pre_exit iptable_mangle_net_pre_exit ops_pre_exit_list cleanup_net 透過將操作分配移動到 xtables 核心來修正，這樣如果沒有有效的操作，該表永遠不會出現在清單中。另請確定資料表在錯誤解除之前不再處理封包。nf_register_net_hooks可能至少發布了一個鉤子;如果發生錯誤，請呼叫 synchronize_rcu（）。審核日誌登錄訊息會延遲到所有作業都通過為止，這可避免在發生錯誤回復時需要發出另一個 UREG 訊息。基於 Tristan Madani 的早期補丁。（CVE-2026-64079）

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

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

  - 安全性/金鑰：修正查詢時遺漏的 RCU 讀取部分 Nicholas Carlini 報告說，金鑰環程式碼在 find_key_to_update（） 中呼叫 assoc_array_find（），而不持有 RCU 讀取鎖定，而 assoc_array_gc（） 程式碼實際上是圍繞著從樹中刪除節點，然後在 RCU 寬限期後釋放它而設計的。一般金鑰處理不會看到此問題，因為保留金鑰環號誌會隱藏任何存留期問題，但持續性金鑰處理會使用不同的模型。無需延長鑰匙圈鎖定，只需執行 assoc_array 設計的簡單 RCU 鎖定即可。（CVE-2026-64015）

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

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

  - net/handshake：將固定檔案參照移交給 accept_doit handshake_req_next（） 會從 per-net 擱置清單中移除請求，並在 handshake_nl_accept_doit（） 讀取 req->hr_sk->sk_socket 並取消參照 sock->file 之前刪除hn_lock （在 FD_PREPARE（） 中一次，在 get_file（） 中再次）。在該視窗中，消費者執行 tls_handshake_cancel（），然後執行 sockfd_put（） （svc_sock_free） 或 __fput_sync（） （xs_reset_transport） 會釋放 sock->file。然後sock_release（） 執行 sock_orphan（），將sk_socket歸零，並釋放結構通訊端。接受端程式碼會透過sk_socket讀取 NULL，或追蹤釋放的記憶體。
    提交端 sock_hold（） 不會阻止這種情況發生。sk_refcnt保護 struct sock，但 struct 通訊端和 sock->file 會透過消費者擁有的檔案描述元獨立參照。釘選 sk 會使 sock 和 sock->file 不受保護。在提交時釘選的 req->hr_file 重新定位接受端取消參照，而不是 req->hr_sk->sk_socket->file。僅釘選是不夠的：在 handshake_req_next（） 傳回和到達 FD_PREPARE（） 之間取消accept_doit消費者會採用 handshake_req_cancel（） 中的 ！remove_pending（） 分支，並在接受端採用自己的引用之前刪除hr_file。在 hn_lock 下的 handshake_req_next（） 內移交一個額外的檔案參照，以便接受端對任何並行 handshake_req_cancel（） 都無法撤銷的參照進行操作。FD_PREPARE（） 會耗用該移交的參照，方法是將它傳輸至 fd_publish（） 中的新 fd，或在錯誤時將其放入清理析構函式中;因此，先前平衡 FD_PREPARE（） 的明確 get_file（） 是多餘的，並且會消失。更新 handshake_req_cancel_test2 和 _test3，以使用 fput（） 模擬 FD_PREPARE（） 消耗，以便 kunit 檔案計數判斷提示保持平衡。（CVE-2026-63979）

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

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

  - bpf， skmsg：修正使用 ktls rx sk_psock_strp_data_ready（） 爭用 sk_data_ready 的判定，當存在 TLS RX 上下文時，已檢查 tls_sw_has_ctx_rx（） 並推遲到 psock->saved_data_ready，避免與 TLS strparser 對接收佇列的所有權發生衝突 （提交 e91de6afa81c， bpf：使用 ktls 修正正在執行的 sk_skb 程式類型）。sk_psock_verdict_data_ready（） 沒有對等的防護。在配置 RX 之前將通訊端插入 sockmap （BPF_SK_SKB_VERDICT） 時TLS tls_sw_strparser_arm（） 會將sk_psock_verdict_data_ready儲存為 rx_ctx->saved_data_ready。資料到達時：tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready（） = sk_psock_verdict_data_ready（） -> tcp_read_skb（） 透過 __skb_unlink（） 耗盡sk_receive_queue而不呼叫 tcp_eat_skb（），因此不會提前copied_seq。然後，tls_strp_msg_load（） 會找到 tcp_inq（） >= full_len （過時），在現在為空的佇列上呼叫 tcp_recv_skb（），命中 WARN_ON_ONCE（！first），然後返回指向 psock 擁有 （可能已釋放） skb 的 rx_ctx->strp.anchor.frag_list。tls_decrypt_sg（） 隨後會執行該frag_list：釋放後使用。
    套用與 sk_psock_strp_data_ready（） 相同的修正：如果存在 TLS RX 上下文，請呼叫 psock->saved_data_ready （sock_def_readable） 以喚醒 recv（） 等候者並立即返回，讓接收佇列保持不變。TLS保留佇列的唯一所有權，並透過 tls_sw_recvmsg（） 正常解密記錄。（CVE-2026-64025）

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

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

  - USB： typec： tcpm/tcpci_maxim：針對 RX_BYTE_CNT 驗證標頭 NDO 損毀/惡意連接埠可以傳輸 CRC 有效框架，其標頭最多通告七個資料物件，但其內文承載的數量少於此值。
    檢查這一點，並正確地拒絕訊息，而不是從未初始化的堆疊記憶體讀取。
    (CVE-2026-63959)

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

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

  - wifi： iwlwifi： mvm：修正舊設備上驅動程式設定的 TX 速率 在舊設備（例如 7265D）上，速率仍以版本 1 格式編碼，該格式不使用 CCK/OFDM 速率索引 （0-3/0-7），而是使用其 PLCP 值（例如 10 表示 1 Mbps CCK 速率）。在引入 v3 速率的同時，我將驅動程式從內部處理 v1 速率並轉換為 v2，更改為內部處理 v3 並根據韌體轉換為 v1 或 v2。因此，我更改了 iwl_mvm_mac80211_idx_to_hwrate（） 中的程式碼，使不同的 API 不再具有不同的值。這是正確的。然而，我後來恢復了這部分更改，因為據報導我破壞了信標速率，導致了 FW 斷言/崩潰。這會導致TX_CMD費率設定不正確，當裝置報告為已使用時，可能會導致警告。透過單獨處理信標範本命令中嵌入的TX_CMD中的信標速率來解決此問題（希望現在正確）。還原 iwl_mvm_mac80211_idx_to_hwrate（） 以僅傳回速率指數，而不傳回 PLCP 值，修正實際TX_CMD。CVE-2026-64176

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

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

  - drm/amdkfd：修正 kfd 偵錯工具 get_queue_ids（） 計算 array_size = num_queues * sizeof（uint32_t） 中整數溢位的弱點，這在 32 位元size_t組建上可能會溢位。改用 array_size（），它會在溢位時飽和到SIZE_MAX。（從提交 2d57a0475f085c08b49312dfd8edcb461845f285 中挑選）（CVE-2026-63881）

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

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

  - ethtool： module：在模組快閃記憶體錯誤時呼叫 ethnl_ops_complete（） 當 validate（） 失敗時，即使我們已經呼叫了 ethnl_ops_begin（），我們也會跳過 ethnl_ops_complete（）。（CVE-2026-63998）

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

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

  - wifi：mac80211：在網格重複使用 skb->cb 之前捕獲快速 RX 速率 ieee80211_invoke_fast_rx（） 透過 IEEE80211_SKB_RXCB（skb） 讀取 RX 狀態，該別名是 ieee80211_rx_mesh_data（） 重複用作 IEEE80211_TX_INFO 的相同 skb->cb 儲存。在單播轉發路徑中，mesh_data執行以下動作： info = IEEE80211_SKB_CB（fwd_skb）;memset（info， 0， sizeof（*info））;在同一個 skb 上，呼叫者仍透過 rx->skb 命名，然後將 skb 排入 TX 佇列 （成功） 或 kfree_skb（） 的 IT（無路由），然後再返回 RX_QUEUED。然後，呼叫端的RX_QUEUED臂會在清零 （成功路徑） 或釋放 （無路由路徑） 的記憶體上呼叫 sta_stats_encode_rate（狀態）。後者是 ieee80211_prepare_and_rx_handle 的 KASAN 板釋放後使用。透過在叫用 ieee80211_rx_mesh_data（） 之前對狀態的速率進行編碼來修正，因此RX_QUEUED臂會消耗在狀態仍由有效記憶體支援時擷取的值。（CVE-2026-64117）

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

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

  - ethtool： rss：修正 get_rxfh 失敗時的 indir_table 和 hkey 洩漏 rss_prepare_get（） 透過 rss_get_data_alloc（） 分配間接表和雜湊金鑰緩衝區，然後呼叫 ops->get_rxfh（） 來填入它們。如果 get_rxfh（） 失敗，則函式會傳回錯誤，而不會釋放分配。（CVE-2026-63999）

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

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

  - batman-adv： tp_meter：在清理時直接關閉計時器 batadv_tp_sender_cleanup（） 調用 timer_delete_sync（），然後調用 timer_delete（），以防止計時器處理常式在兩次調用之間重新布防。這種雙重刪除黑客攻擊依賴於將發送狀態設置為 0 來抑制重新布防。將這兩個呼叫替換為單一 timer_shutdown_sync（）。此函式既會等待任何正在執行的計時器回呼完成 （如 timer_delete_sync（）），又會永久撤防計時器，使其之後無法重新布防，因此可以無條件地防止重新布防並自我記錄。re-arming 屬性也是必需的，因為否則： 1. 上下文 0 （batadv_tp_recv_ack（）） 檢查 batadv_tp_reset_sender_timer（），如果 sending 仍為 1 ->則為 2。上下文 1 將 batadv_tp_sender_shutdown（） 發送更改為 0，在此過程中強制 kthread 停止 batadv_tp_sender_cleanup（） 3 中的計時器。上下文 0 繼續在 batadv_tp_reset_sender_timer（） 中並重新武裝計時器
    ->，但它的引用已經消失了 （CVE-2026-64093）

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

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

  - lsm：保留 lsm_set_self_attr（） 的 cred_guard_mutex，就像 proc_pid_attr_write（） 在呼叫 LSM 鉤子之前所做的那樣。這僅對 SELinux 和 AppArmor 重要，它們會檢查是否正在追蹤處理程序，如果是，是否允許轉換。（CVE-2026-64111）

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

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

  - drm/amd/display：在反覆運算之前驗證 GPIO 針腳 LUT 表格大小 [Why&How] get_gpio_i2c_info（） 和 bios_parser_get_gpio_pin_info（） 中的 GPIO 針腳表剖析器會從 VBIOS table_header.structuresize 欄位衍生元素計數，然後反覆運算 gpio_pin[] 項目。但是，GET_IMAGE（） 僅驗證表格標頭本身是否適合 BIOS 映像。如果 VBIOS 報告的結構大小大於實際對應的數據，則迴圈會讀取超過 BIOS 映像的結尾，造成越界讀取。在兩個函式中進入迴圈之前，呼叫 bios_get_image（） 來驗證可在 BIOS 映像中存取完整的宣告結構大小，以修正此問題。（從提交 ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3 中挑選）（CVE-2026-64097）

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

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

  - drm/amdgpu：修正amdgpu_hmm_range_get_pages通知程式序列只能讀取一次，否則我們可能會處理無效的頁面。同時還修復了編碼樣式，例如刪除預先初始化的傳回值並使用 2G 範圍的通用定義。（從提交 c08972f555945cda57b0adb72272a37910153390 中挑選）（CVE-2026-63879）

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

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

  - netfs：修正重試新增子要求時缺少的鎖定 修正 netfs_retry_read_subrequests（） 和 netfs_retry_write_stream（） 以在將額外的子要求新增至 stream->subrequests 時採取適當的鎖定。（CVE-2026-64068）

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

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

  - netfs：修正 netfs_write_begin（） 錯誤處理中要求的洩漏 修正 netfs_write_begin（） 以在收到 netfs_wait_for_read（） 錯誤時不會洩露要求上的參照。（CVE-2026-64060）

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

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

  - netfs：修正無鎖定存取 stream->subrequests 時遺失的屏障 附加到 stream->subrequests 的子請求清單由 netfs_collect_read_results（） 和 netfs_collect_write_results（） 在沒有鎖定的情況下存取，然後它們在從清單中取得 subreq 指標後，無需使用屏障即可存取 subreq->flags。相關地說，建置清單的函式在建構清單時不會使用任何類型的寫入屏障，以確保在未採取鎖定的情況下，會先設定NETFS_SREQ_IN_PROGRESS旗標。透過以下方式解決此問題： （1） 新增一個 list_add_tail_release（） 函式，該函式使用釋放屏障將指標設定為清單的新成員。（2） 新增一個 list_first_entry_or_null_acquire（） 函數，該函數使用 acquire 屏障讀取指向清單中第一個成員的指標（或傳回 NULL）。（3）將子q新增到->subrequests時，使用list_add_tail_release（）。
    （4）在最初存取清單前面時使用list_first_entry_or_null_acquire（）（當一個項目被移除時，在同一鎖定下取得指向新前面iterm的指標）。（CVE-2026-64067）

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

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

  - ALSA：pcm：oss：修正 proc 寫入錯誤 snd_pcm_oss_proc_write（） 上的安裝清單 UAF，在複製任務名稱之前，將新配置的安裝項目連結到 OSS 設定清單中。如果任務名稱配置失敗，錯誤路徑會釋放已連結的項目，並保留setup_list指向已釋放的記憶體。隨後開啟的 OSS 裝置可以遍歷 snd_pcm_oss_look_for_setup（） 中的過時清單項目並取消參照釋放的記憶體。配置任務名稱並初始化設定項目，然後再將項目發佈到 setup_list。
    此外，只有在獲取setup_mutex之後才獲取初始 proc 讀取迭代器，因此所有setup_list遊走都遵循相同的清單存留期規則。（CVE-2026-64001）

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

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

  - USB： typec： tcpm：驗證 Discover Identity ACK 處理常式中的 VDO 計數 調用 svdm_consume_identity（） 或 svdm_consume_identity_sop_prime（） 時，請正確驗證從裝置傳遞的計數，因為裝置控制的值可能會從靜態陣列中編出索引，進而可能洩漏資料。（CVE-2026-63963）

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

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

  - KVM：arm64：客體虛擬化管理程式提供的正確上限ZCR_EL2 ZCR_EL2 VHE 客體虛擬化管理程式可以使用 ZCR_EL2 （設陷） 或 ZCR_EL1 （不設陷） 進行更新。KVM 以不同的方式處理兩者： - 在ZCR_EL2陷阱上，ZCR_EL2。LEN 會立即上限為 VM 自己的 VL 限制。這有可能破壞依賴完整 LEN 欄位以設定狀態的現有軟體。- 在ZCR_EL1訪問方面，我們完全不做任何事情。在還原 L2 客體的 SVE 內容時，我們直接將客體虛擬化管理程式的ZCR_EL2檢視還原到實體ZCR_EL2中。如果訪客的暫存器檢視已使用 ZCR_EL2 存取器更新，則值已清理 （有上述警告）。但是，如果客體使用ZCR_EL1，原始值會寫入硬體，而 L2 客體現在可以存取不應該存取的 VL。透過將 VL 上限移至還原點來修正上述所有問題，確保： - 硬體一律使用上限值進行程式設計，而不論使用何種存取子，- ZCR_EL2。LEN 欄位一律是完全可設定狀態的，不論使用何種存取子。此外，將ZCR_EL2移至已清理的暫存器，確保只有 LEN 欄位實際上是可設定狀態的。這需要對 RES0 遮罩進行一些創造性的建構，因為 sysreg 產生指令碼尚未產生 RAZ/WI 欄位。[馬茲：
    重寫提交訊息，整理 access_zcr_el2（）] （CVE-2026-63941）

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

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

  - rxrpc： 透過將資料複製到 recvmsg 中的緩衝區，修正 DATA 解密與 splice（） 這改善了 的修正 CVE-2026-43500。透過消除 I/O 執行緒中的封包共用，並無條件地將封包內容擷取到解密緩衝區的反彈緩衝區中，修正因就地解密 splice（） 在 splice（） 本地傳輸的 DATA 封包而導致的頁面快取損毀。然後，recvmsg（） （或核心對等項目） 會將資料從退回緩衝區複製到目的地緩衝區。然後，sk_buff會保持不變。這還有一個額外的優點，因為封包會以加密演算法直接處理所需的正確對齊方式排列在緩衝區中。加密貨幣的性能似乎確實快了一些，而且令人驚訝的是，未加密的性能似乎沒有太大變化
    - 可能是因為移除了 I/O 執行緒的複雜性。另一個優點是 I/O 執行緒不必複製封包，這會減慢封包分發、ACK 產生等速度。緩衝區屬於調用，一開始配置為 2K，足夠大以容納整個巨型子封包，但如果需要，緩衝區的大小會增加。但是，要進行這項工作，MSG_PEEK可能會導致後續封包被解密到緩衝區中，在這種情況下，較早的封包將需要為後續的 recvmsg（） 重新解密。請注意，rx_pkt_offset現在可能會合法地將 0 視為有效的偏移，因此請切換為使用 USHRT_MAX 來指示無效的偏移。另請注意，我通常更願意用大小合適的新 kmalloc'd 緩衝區替換當前sk_buff的緩衝區，放棄舊數據和片段，因為這樣可以更輕鬆地處理MSG_PEEK並消除重新解密問題，但這看起來是一件相當複雜的事情要實現。skb_morph（） 看起來與我想要的有一半，但我不想分配新的sk_buff。（CVE-2026-64026）

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

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

  - netfilter： nf_tables：修正相同暫存器作業中的 DST 損毀 對於 lshift 和 rshift，移位作業會在 32 位元字的迴圈中執行。迴圈計算移位值並將其寫入 dst，然後立即從 src 讀取以計算下一次迭代的進位。因為 src 和 dst 可能指向相同的記憶體位置，所以使用新修改的 dst 值而不是原始 src 值來正確計算進位。在寫入 dst 之前新增暫存本機變數以快取原始值，並將其用於進位計算，即可解決問題。此外，控制平面會拒絕包含位元組順序在內的所有作業的部分重疊。這是用以下位元組碼測試的： 表 test_table ip 旗標 0 使用 1 處理 1 ip test_table test_chain 使用 3 類型 filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = （ reg 1 << 0x08000000 ） ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = （ reg 1 << 0x08000000 ） ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ] （CVE-2026-64006）

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

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

  - 藍牙：HIDP：修正 hidp_input_report（） 中缺少的長度檢查 hidp_input_report（） 會從 skb 讀取鍵盤和滑鼠負載資料，而無需先驗證 skb->len 是否包含足夠的資料。
    hidp_recv_intr_frame（） 會在分派至 hidp_input_report（） 之前提取 1 位元組的 HIDP 標頭。如果配對裝置傳送截斷的封包，處理常式會讀取超出有效 skb 資料，導致 skb 資料越界讀取。OOB 位元組可能會解譯為虛擬按鍵或虛假滑鼠移動。將開放編碼長度追蹤和指標算術取代為 skb_pull_data（） 呼叫。
    如果請求的位元組不存在，skb_pull_data（） 傳回 NULL，從而無需手動大小變數和單獨的 skb->len 保護。（CVE-2026-63947）

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

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

  - USB： gadget： f_fs：僅複製短 EP0 讀取時收到的位元組 ffs_ep0_read（） 在 Setup 封包的 Length 值處使用 kmalloc（） （不是 kzalloc） 分配其控制 OUT 資料緩衝區，然後將該完整 len 複製到使用者空間，而不管實際收到多少位元組： data = kmalloc（len， GFP_KERNEL）;...
    ret = __ffs_ep0_queue_wait（ffs， data， len）;if （（ret > 0） &; &; （copy_to_user（buf， data， len））） ret =
    -EFAULT;__ffs_ep0_queue_wait（） 傳回 req->actual，在短控制 OUT 傳輸時嚴格小於 len。copy_to_user（） 呼叫仍會複製 len 位元組，因此在短 OUT 時，kmalloc（） 緩衝區的最後 （len - ret） 位元組 （未初始化的 slab 殘留） 會傳遞至 FunctionFS 守護程式。
    短 ep0 OUT 完成是指定的 USB 控制傳輸行為，由樹狀結構內 UDC 產生： * dwc2 繼續執行 ep0 DATA OUT 的 req->actual < req->length （short-not-ok 是唯一的 ep0-OUT 停止路徑）。* aspeed_udc 在 ep->ep.maxpacket 上結束 ep0 OUT rx_len <。* renesas_usbf記錄 ep0 短封包並完成請求。* dwc3 在短 IN 上停止，但在短 OUT 上不會停止。因此，短 ep0 OUT 不是 UDC 損壞的證據;這是f_fs必須應對的正常情況。drivers/usb/gadget/legacy/inode.c 中的同級 gadgetfs 實作已經透過 copy_to_user（） 之前的 min（len， dev->req->actual） 正確執行此操作。此補丁使 f_fs.c 具有相同的安全模式，而不是在防禦層進行修剪。此錯誤是從 FunctionFS 裝置節點連線的，在實際部署中，該節點由特權小工具常駐程式 （adbd、UMS、複合小工具服務等） 所擁有;無法從無特權的使用者空間存取它。Linux 主機堆疊通常會在短 wLength 控制 OUT 到達小工具之前拒絕它們，因此重現此動作需要繞過主機端檢查的組建。
    繞過就位後，64 位元組安裝程式上的 1 位元組承載會在精靈的讀取緩衝區中產生 63 位元組的非金絲雀板殘留。透過僅將 ret （實際收到） 位元組複製到使用者空間來修正。
    (CVE-2026-63895)

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

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

  - test_kprobes：在測試執行之間清除 kprobes 執行兩次 kprobes 可用性測試會使所有測試失敗，並最終使核心當機。[root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # 總計：通過：5 失敗：0 跳過：0 總計：5 ok 1 kprobes_test [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # test_kprobe： lib/tests/test_kprobes.c：64 的預期失敗 預期 0 == register_kprobe（&kp），但 register_kprobe（&kp） == -22 （0xffffffffffffffea） ... 無法處理核心分頁要求... 測試套件會將數個 kprobes 和 kretprobes 定義為在測試執行中保留的靜態變數。在register_kprobe和unregister_kprobe之後，kprobe 包含一些剩餘資料，必須先清除這些資料，才能再次註冊 kprobe。測試設定symbol_name以定義探測位置。必須清除位址和旗標。現有的程式碼會在後續測試之間清除某些探查，但不會在兩次測試執行之間清除。先前測試執行的剩餘資料會使註冊在下次執行中失敗。將所有 kprobe 的清理移至 kprobes_test_init，此函式會在每次測試之前呼叫 （包括測試執行的第一次測試）。（CVE-2026-64163）

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

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

  - netfilter： ebtables：移至兩階段移除方案 與之前的 x_tables 修補程式一樣，在 ebtables 中遵循相同的模式。我們無法重複使用 xt 協助程式：ebt_table結構佈局不相容。table->ops 分配現在已完成，同時仍保留 EBT 互斥，以確保我們永遠不會暴露部分填充的表結構。（CVE-2026-64077）

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

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

  - netfilter： x_tables：新增並使用 xtables_unregister_table_exit 先前已新增的變更 xtables_unregister_table_pre_exit，以將表格與封包路徑分離，並將其與作用中表格清單取消連結。在 rmmod 的情況下，為此表執行 set/getsockopt 的使用者空間將無法重新實例化該表： 1. 幼蟲表已被移除 2.現有的實例化表格不再位於 XT Pernet 表格清單上。這會新增第二階段協助程式：從垂死清單取消表格連結、釋放勾點操作 （如果有） 並執行稽核通知。它取代了 xt_unregister_table（）。
    (CVE-2026-64078)

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

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

  - powerpc/hv-gpci：修正 sysfs 顯示路徑中的搶佔計數洩漏 hv-gpci 中的四個 sysfs show（） 回呼採用 get_cpu_var（hv_gpci_reqb）（呼叫 preempt_disable（）），但僅呼叫「out：」標籤下錯誤路徑上相符的 put_cpu_var（）。每次成功讀取都會洩漏一個 preempt_disable（）：
    processor_bus_topology_show（） processor_config_show（） affinity_domain_via_virtual_processor_show（） affinity_domain_via_domain_show（） （affinity_domain_via_partition_show（） 已經正確了。在 CONFIG_PREEMPT=y 核心上，重複讀取會引發preempt_count，並最終返回使用者空間，且搶佔功能仍處於停用狀態。下一個使用者模式頁面錯誤隨後命中 faulthandler_disabled（） == 1，被迫執行 SIGSEGV，並且產生的核心轉儲在 -> wait_for_completion_state -> schedule 中跳閘call_usermodehelper_exec「BUG：atomic時排程」： BUG：atomic 時排程：
    <task>/<pid>/0x00000004 ... __schedule_bug+0x6c/0x90 __schedule+0x58c/0x13a0 schedule+0x48/0x1a0 schedule_timeout+0x104/0x170 wait_for_completion_state+0x16c/0x330 call_usermodehelper_exec+0x254/0x2d0 vfs_coredump+0x1050/0x2590 get_signal+0xb9c/0xc80 do_notify_resume+0xf8/0x470 新增一個out_success標籤，在傳回位元組計數之前呼叫 put_cpu_var（），鏡像 affinity_domain_via_partition_show（）。
    (CVE-2026-64070)

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

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

  - VSOCK/virtio：在填充 ZeroCopy SKB 之前綁定 UAR virtio_transport_send_pkt_info（） 會在進入發送迴圈之前配置或重複使用 ZeroCopy UARG，但 virtio_transport_alloc_skb（） 在繼承該 UAR 之前仍會填充 SKB。當固定緩衝區向量零副本命中MAX_SKB_FRAGS時，io_sg_from_iter（） 可能會部分附加受管理片段並傳回 -EMSGSIZE。回滾路徑呼叫 kfree_skb（） 以釋放攜帶 SKBFL_MANAGED_FRAG_REFS但沒有 uarg 的 skb，因此 skb_release_data（） 會變成普通片段 unref。將 uarg 傳遞至 virtio_transport_alloc_skb（） 中，並在 virtio_transport_fill_skb（） 之前綁定它。這樣可以保持控制或無負載 skb 不變，同時確保成功和復原共享一個生命週期規則。（CVE-2026-63970）

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

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

  - rbd：消除取消映射時 lock_dwork 耗盡中的爭用 鑑於 rbd_lock_add_request（） 和 rbd_img_exclusive_lock（） 的編寫方式，lock_dwork 可能會（重新）排隊的次數超過其實際需要：例如，如果當我們代表另一個 I/O 請求在 rbd_acquire_lock（） 中間時收到新的 I/O 請求。這是預期的，並且使用 rbd_release_lock（） 先發制人地取消lock_dwork在正常操作下是良性的。一個更有問題的例子是 maybe_kick_acquire（）： if （have_requests || delayed_work_pending（&rbd_dev->lock_dwork）） { dout（%s rbd_dev %p kicking lock_dwork\n， __func__， rbd_dev）; mod_delayed_work（rbd_dev->task_wq， &rbd_dev->lock_dwork， 0）; }lock_dwork在 delayed_work_pending（） 傳回 true 後立即被取消，並且 mod_delayed_work（） 無論如何都會將其重新排隊，這並非不切實際。這是一場經典的 TOCTOU 比賽。在取消映射圖像時，有一個隱含的假設，即在 rbd_dev_image_unlock（） 的返回點之後沒有自我啟動的排他鎖定活動，如果碰巧被持有，則解鎖鎖定。此解鎖被認為是最終的，並且lock_dwork（以及所有其他獨佔鎖定任務，實際上）預計不會再次排入佇列。
    但是，lock_dwork僅在 cancel_tasks_sync（） 中被取消（即在取消映射序列的後面），並且最重要的是取消實際上可以被 maybe_kick_acquire（） 無效。這可能會導致 rbd_acquire_lock（） 在 rbd_dev_device_release（） 和 rbd_dev_image_release（） 執行後執行，並釋放和/或重設一堆東西。其中一種可能的故障模式是違反rbd_assert（rbd_image_format_valid（rbd_dev->image_format））;在 rbd_dev_header_info（） 中，它是透過 rbd_post_acquire_action（） 的 rbd_dev_refresh（） 呼叫的。重做排他鎖定任務清空，以提供更合理的語意，並嘗試符合 rbd_dev_image_unlock（） 周圍的假設。（CVE-2026-64112）

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

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

  - netfs：修正 netfs_read_to_pagecache（） 以在子請求失敗時暫停 修正 netfs_read_to_pagecache（），以便在已發出的子請求失敗時暫停產生新的子請求。（CVE-2026-64066）

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

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

  - blk-mq：如果快取的請求可用，則彈出 當向 blk-mq 提交 bio 時，如果任務在查看快取請求後應該休眠，但在彈出它之前，plug 會刷新並呼叫 blk_mq_free_plug_rqs，從而釋放cached_rqs。這會產生釋放後使用的錯誤。如果適合使用，請在任何可能的封鎖呼叫之前彈出快取的要求，以修正此問題。先彈出此要求會保留佇列參考，因此請避免任何佇列凍結的序列化爭用，並可以安全地繼續將該要求分派給驅動程式。這可能會增加從驅動程式想要凍結其佇列到停止分派要求的計時視窗。不過，這種情況不在快速路徑上，驅動程序無論如何都需要在凍結請求期間適當地處理請求。缺點是當我們執行生物插頭合併時，需要單獨釋放彈出的元素。無論如何，緩存的請求稍後都必須釋放，但此補丁在構建插件列表時進行內聯操作，而不是在刷新它之後。
    (CVE-2026-64017)

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

ID	名稱	嚴重性
327959	Linux Distros 未修補弱點：CVE-2026-64082	high
327958	Linux Distros 未修補弱點：CVE-2026-64036	high
327957	Linux Distros 未修補弱點：CVE-2026-64058	high
327956	Linux Distros 未修補弱點：CVE-2026-64139	medium
327955	Linux Distros 未修補弱點：CVE-2026-63922	critical
327954	Linux Distros 未修補弱點：CVE-2026-64098	high
327953	Linux Distros 未修補弱點：CVE-2026-64038	medium
327952	Linux Distros 未修補弱點：CVE-2026-64138	high
327951	Linux Distros 未修補弱點：CVE-2026-63974	high
327950	Linux Distros 未修補弱點：CVE-2026-63940	critical
327949	Linux Distros 未修補弱點：CVE-2026-64092	medium
327948	Linux Distros 未修補弱點：CVE-2026-63983	medium
327947	Linux Distros 未修補弱點：CVE-2026-64159	high
327946	Linux Distros 未修補弱點：CVE-2026-64106	critical
327945	Linux Distros 未修補弱點：CVE-2026-64154	high
327944	Linux Distros 未修補弱點：CVE-2026-64146	high
327943	Linux Distros 未修補弱點：CVE-2026-64076	high
327942	Linux Distros 未修補弱點：CVE-2026-64048	high
327941	Linux Distros 未修補弱點：CVE-2026-64079	medium
327940	Linux Distros 未修補弱點：CVE-2026-64015	high
327939	Linux Distros 未修補弱點：CVE-2026-63979	critical
327938	Linux Distros 未修補弱點：CVE-2026-64025	critical
327937	Linux Distros 未修補弱點：CVE-2026-63959	medium
327936	Linux Distros 未修補弱點：CVE-2026-64176	high
327935	Linux Distros 未修補弱點：CVE-2026-63881	high
327934	Linux Distros 未修補弱點：CVE-2026-63998	medium
327933	Linux Distros 未修補弱點：CVE-2026-64117	high
327932	Linux Distros 未修補弱點：CVE-2026-63999	medium
327931	Linux Distros 未修補弱點：CVE-2026-64093	high
327930	Linux Distros 未修補弱點：CVE-2026-64111	high
327929	Linux Distros 未修補弱點：CVE-2026-64097	high
327928	Linux Distros 未修補弱點：CVE-2026-63879	high
327927	Linux Distros 未修補弱點：CVE-2026-64068	critical
327926	Linux Distros 未修補弱點：CVE-2026-64060	medium
327925	Linux Distros 未修補弱點：CVE-2026-64067	critical
327924	Linux Distros 未修補弱點：CVE-2026-64001	medium
327923	Linux Distros 未修補弱點：CVE-2026-63963	high
327922	Linux Distros 未修補弱點：CVE-2026-63941	high
327921	Linux Distros 未修補弱點：CVE-2026-64026	high
327920	Linux Distros 未修補弱點：CVE-2026-64006	high
327919	Linux Distros 未修補弱點：CVE-2026-63947	high
327918	Linux Distros 未修補弱點：CVE-2026-63895	high
327917	Linux Distros 未修補弱點：CVE-2026-64163	medium
327916	Linux Distros 未修補弱點：CVE-2026-64077	high
327915	Linux Distros 未修補弱點：CVE-2026-64078	high
327914	Linux Distros 未修補弱點：CVE-2026-64070	high
327913	Linux Distros 未修補弱點：CVE-2026-63970	high
327912	Linux Distros 未修補弱點：CVE-2026-64112	high
327911	Linux Distros 未修補弱點：CVE-2026-64066	critical
327910	Linux Distros 未修補弱點：CVE-2026-64017	high

偵測

Nessus 的 Misc. 系列

high

high

high

medium

critical

high

medium

high

high

critical

medium

medium

high

critical

high

high

high

high

medium

high

critical

critical

medium

high

high

medium

high

medium

high

high

high

high

critical

medium

critical

medium

high

high

high

high

high

high

medium

high

high

high

high

high

critical

high