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

  - ALSA：asihpi：修正讀取快取 find_control（） 時潛在的 OOB 陣列存取，以擷取快取的資訊盲目存取具有指定索引的陣列，這可能會導致 OOB 陣列存取。新增健全性檢查以避免這種情況。（CVE-2026-64133）

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

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

  - 已解決 Linux 核心中的下列弱點：l2tp: use list_del_rcu in l2tp_session_unhash An unprivileged local user can pin a host CPU indefinitely in l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace suffices; on any host that has l2tp_core loaded the trigger is reachable from a standard `unshare -Urn` sandbox. l2tp_session_unhash() removes a session from tunnel->session_list with list_del_init(), but that list is walked by l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under rcu_read_lock_bh(). list_del_init() leaves the deleted entry's next/prev self-pointing; a reader that has loaded the entry and then advances pos->list.next reads &session->list, container_of()s back to the same session, and list_for_each_entry_rcu() never reaches the list head. The CPU stays in strcmp() inside the walker, with BH and preemption disabled, so RCU grace periods on the host stall behind it and the wedged thread cannot be killed (SIGKILL is delivered on syscall return). Use list_del_rcu() to match the existing list_add_rcu() in l2tp_session_register(); the deleted session remains visible to in-flight walkers with consistent next/prev pointers until kfree_rcu() in l2tp_session_free() releases it. tunnel->session_list has exactly one list_del_init() call site; the list_del_init (&session->clist) at l2tp_core.c:533 operates on the per-collision list, which is not walked under RCU. list_empty(&session->list) is not used anywhere in net/l2tp/ after the unhash point, so dropping the post-delete self-init is safe; the fix has no userspace-visible behavior change. (CVE-2026-64119)

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

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

  - Crypt：:P assword 版本通過 0.28 Perl 容易受到定時攻擊。check_password 方法使用內建的 eq 運算子。這允許使用時間差異來猜測基礎哈希。（CVE-2026-6656）

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

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

  - 已解決 Linux 核心中的下列弱點：netfs: Fix early put of sink folio in netfs_read_gaps() Fix netfs_read_gaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITER_BVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps. The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket: BUG: KASAN: use-after-free in
    _copy_to_iter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID:
    1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x17f/0x4f1 kasan_report+0x100/0x1e0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x3c/0x60
    _copy_to_iter+0x48a/0xa20 __skb_datagram_iter+0x2c9/0x430 skb_copy_datagram_iter+0x6e/0x160 tcp_recvmsg_locked+0xce0/0x1130 tcp_recvmsg+0xeb/0x300 inet_recvmsg+0xcf/0x3a0 sock_recvmsg+0xea/0x100 cifs_readv_from_socket+0x3a6/0x4d0 [cifs] cifs_read_iter_from_socket+0xdd/0x130 [cifs] cifs_readv_receive+0xaad/0xb10 [cifs] cifs_demultiplex_thread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210 (CVE-2026-64061)

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

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

  - 在 kronosnet 的網路封包碎片整理引擎中發現弱點 （受影響的版本 <= 1.34）。內部重組程式碼無法正確驗證傳入承載片段的序號。攻擊者可以透過傳輸具有損毀序列參數的格式錯誤的封包來利用這種缺乏驗證的情況。在特定情況下，這會迫使封包處理層剖析內部記憶體結構指定邊界之外的數據，從而導致越界記憶體存取或堆積損毀。此行為可能會導致應用程式突然當機或系統不穩定。
    (CVE-2026-15813)

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

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

  - 已解決 Linux 核心中的下列弱點：netfs, afs: Fix write skipping in dir/link writepages Fix netfs_write_single() and afs_single_writepages() to better handle a write that would be skipped due to lock contention and WB_SYNC_NONE by returning 1 from netfs_write_single() if it skipped and making afs_single_writepages() skip also. If a skip occurs, the inode must be re-marked as the VFS may have cleared the mark. This is really only theoretical for directories in netfs_write_single() as the only path to that is through afs_single_writepages() that takes the ->validate_lock around it, thereby serialising it. (CVE-2026-64156)

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

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

  - drm/amdkfd：修正 svm_range_set_attr 中的 NULL 指標錯誤 如果使用者在呼叫 kfd_ioctl_svm 之前未呼叫 kfd_ioctl_acquire_vm，則process_info可能為 NULL。（從提交 83a26c812e0529eb040d31a76f73e33e637243d4 中挑選）（CVE-2026-63882）

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

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

  - tcp：修正過時的 per-CPU tcp_tw_isn洩漏，啟用 ISN 預測 Blamed commit 將 TIME_WAIT 衍生的 ISN 從 skb 控制區塊移至 per-CPU 變數，假設寫入該值的相同封包一律會由 tcp_conn_request（） 耗用。生產者 （tcp_v{4,6}_rcv（） 中的 __this_cpu_write（tcp_tw_isn， isn）） 和消費者 （tcp_conn_request（）） 之間的多個丟棄路徑違反了這一假設： - min_ttl/min_hopcount檢查 - xfrm 策略檢查 - tcp_inbound_hash（） MD5/AO 不相符 - tcp_filter（） eBPF/SO_ATTACH_FILTER 丟棄 - th->syn & th->fin 丟棄 tcp_rcv_state_process（） TCP_LISTEN - tcp_v{4,6}_do_rcv（） 中的 psp_sk_rx_policy_check（） -tcp_v{4,6}_do_rcv（） 中的 tcp_checksum_complete（） - tcp_v{4,6}_cookie_check（） 傳回 NULL 當封包丟棄在任何這些路徑上時，tcp_tw_isn會保持設定狀態。然後，在相同 CPU 上處理的下一個 SYN 會耗用 tcp_conn_request（） 中的非零值，並接收可能可預測的 ISN。此修補程式tcp_tw_isn移回 skb->cb[]，刪除了 per-cpu 變數。請注意，tcp_v{4,6}_fill_cb（） 不會設定它。對整體程式碼大小/複雜性的影響非常小： $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove： 0/0 增長/縮小： 2/1 上/下： 8/-15 （-7） 函數 舊的新 delta tcp_v6_rcv 3038 3042 +4 tcp_v4_rcv 3035 3039 +4 tcp_conn_request 2938 2923 -15 總計：之前=24436060，之後=24436053，chg -0.00% （CVE-2026-64024）

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

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

  - Bluetooth： btmtk：修正錯誤路徑中的 urb->setup_packet 洩漏 如果控制 urb 失敗或提交的 urb 終止usb_submit_urb則不會釋放控制 urb 的setup_packet。在這兩條路徑中新增免費。（CVE-2026-64144）

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

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

  - USB：typec：tcpm： altmode_desc[] bound per iteration in svdm_consume_modes（） svdm_consume_modes（） 在迴圈計數之前針對陣列大小檢查一次 pmdata->altmodes，但忘記在迴圈中的每個點檢查邊界。在行為良好的 SVDM 發現流程中，這是無害的，因為最多SVID_DISCOVERY_MAX每個 SVID 都以最多MODE_DISCOVERY_MAX模式做出貢獻，恰好填滿altmode_desc[ALTMODE_DISCOVERY_MAX]。但 tcpm_pd_svdm（） 中的 CMDT_RSP_ACK 處理常式不會將傳入的 ACK 與連接埠實際傳送的任何要求相關聯。設定 port->partner 之後，系統會無條件地使用主動的「探索模式」ACK。因此，損毀或惡意連接埠夥伴可透過一般流程將 altmode 驅動至 ALTMODE_DISCOVERY_MAX - 1，然後傳送一個包含 7 個 VDO 的額外探索模式 ACK。
    由於前迴圈檢查通過，因此迴圈最多可以寫入五個項目 altmode_desc[]。mode_data_prime結構tcpm_port中的下一個欄位是 partner_altmode[] 指標陣列，然後接收合作夥伴選擇的 SVID/VDO 位元組。將繫結檢查移動到迴圈內，這樣無論合作夥伴提供多少個 VDO 或如何達到函數，陣列都永遠無法索引超過 ALTMODE_DISCOVERY_MAX。（CVE-2026-63962）

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

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

  - USB：類型C：UCSI：驗證 ucsi_connector_change（） 中的連接器號碼 UCSI CCI 通知中的連接器號碼是 PPM 提供的 7 位元欄位。ucsi_connector_change（） 使用它來索引 ucsi->connector[] 陣列，而不根據 PPM 在初始化時報告的連接器數量進行檢查，因此有錯誤或惡意的 PPM（EC 韌體，或 ccg / stm32g0 / glink 傳輸上的 I2C 連接的 UCSI 控制器）可以驅動記憶體上的 schedule_work（） 超過陣列的末端。在取消參照陣列之前，拒絕零或超過 cap.num_connectors 的連接器編號。（CVE-2026-63958）

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

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

  - bonding：拒絕從屬 CAN 裝置 syzbot 報告 net/can/af_can.c 內的 can_rx_unregister（） 中的核心分頁請求崩潰。發生當機的原因是虛擬 CAN 裝置 （vxcan） 被綁定主機從屬。在奴役過程中，綁定驅動程式會改變和修改網路裝置狀態，以符合類似乙太網路的聚合模型。然而，CAN 設備在完全不同的第 2 層架構上運行，依賴 CAN 中層私有資料結構 （can_ml_priv） 而不是標準乙太網路結構。由於綁定不會初始化或維護這些 CAN 結構，因此在半從屬介面上的後續操作（例如透過 isotp_release 關閉關聯的通訊端）會導致存取 CAN 接收器清單時出現 null 指標解除參照。綁定 CAN 介面在架構上是無效的，因為 CAN 缺乏 MAC 位址、ARP 功能和標準乙太網路鏈路層機制。雖然通用環回裝置在 net/core/dev.c 中被全域封鎖，但虛擬 CAN 裝置會繞過此檢查，因為它們不帶有 IFF_LOOPBACK 標誌，儘管充當本地軟體環回。透過在 bond_enslave（） 的開頭明確阻止 ARPHRD_CAN 類型的網路裝置被奴役來解決此問題。這可以防止非法狀態突變，消除由此產生的 KASAN 崩潰，並避免不完整的通訊端清理造成的潛在記憶體洩漏。由於 CAN 支援是在綁定後很長一段時間才添加的，因此 Fixes-tag 指出引入了需要在 bonding_main.c 中進行特定處理的ARPHRD_CAN。（CVE-2026-63990）

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

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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 已解決 Linux 核心中的下列弱點：ksmbd: fix SID memory leak in set_posix_acl_entries_dacl() on overflow Commit 299f962c0b02 (ksmbd: use check_add_overflow() to prevent u16 DACL size overflow) added check_add_overflow() guards that break out of the ACE-building loops in set_posix_acl_entries_dacl() when the accumulated DACL size would wrap past 65535. However, each iteration allocates a struct smb_sid via kmalloc_obj() at the top of the loop and relies on the kfree(sid) call at the end of the loop body (the 'pass_same_sid' label in the first loop, and the explicit kfree at the tail of the second loop) to release it. The newly introduced 'break' statements bypass those kfree() calls, leaking the sid buffer every time an overflow is detected. A malicious or malformed file with enough POSIX ACL entries to trip the overflow check will leak one or more struct smb_sid allocations on every request that touches the file's DACL, providing a trivial kernel memory exhaustion vector. Free sid before breaking out of the loops to plug the leak. (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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 已解決 Linux 核心中的下列弱點：batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is responsible for releasing the tp_vars reference it holds. However, the existing logic for coordinating this release with batadv_tp_stop_all() was flawed. timer_shutdown_sync() guarantees the timer will not fire again after it returns, but it returns non-zero only when the timer was pending at the time of the call. If the timer had already expired (and batadv_tp_stop_all() would unsucessfully try to rearm itself), batadv_tp_stop_all() skips its batadv_tp_vars_put(), and batadv_tp_receiver_shutdown() fails to put its own reference as well. Fix this by introducing a new atomic variable receiving that is set to 1 when the receiver is initialized and cleared atomically with atomic_xchg() by whichever side claims it first. Only the side that observes the transition from 1 to 0 is responsible for releasing the tp_vars timer reference, eliminating the uncertainty. (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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 已解決 Linux 核心中的下列弱點：wifi: iwlwifi: mvm: fix driver-set TX rates on old devices On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.) While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer have different values for different APIs. This was correct. However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TX_CMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used. Fix this (hopefully correctly now) by handling beacon rates in the TX_CMD that's embedded in the beacon template command separately.
    Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate index, not PLCP value, fixing the real 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 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
327978	Linux Distros 未修補弱點：CVE-2026-64133	high
327977	Linux Distros 未修補弱點：CVE-2026-64119	medium
327976	Linux Distros 未修補弱點：CVE-2026-6656	high
327975	Linux Distros 未修補弱點：CVE-2026-64061	critical
327974	Linux Distros 未修補弱點：CVE-2026-15813	medium
327973	Linux Distros 未修補弱點：CVE-2026-64156	medium
327965	Linux Distros 未修補弱點：CVE-2026-63882	medium
327964	Linux Distros 未修補弱點：CVE-2026-64024	critical
327963	Linux Distros 未修補弱點：CVE-2026-64144	medium
327962	Linux Distros 未修補弱點：CVE-2026-63962	medium
327961	Linux Distros 未修補弱點：CVE-2026-63958	high
327960	Linux Distros 未修補弱點：CVE-2026-63990	medium
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	medium
327946	Linux Distros 未修補弱點：CVE-2026-64106	critical
327945	Linux Distros 未修補弱點：CVE-2026-64154	medium
327944	Linux Distros 未修補弱點：CVE-2026-64146	medium
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	high
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	high
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

偵測

Nessus 的 Misc. 系列

high

medium

high

critical

medium

medium

medium

critical

medium

medium

high

medium

high

high

high

medium

critical

high

medium

high

high

critical

medium

medium

medium

critical

medium

medium

high

high

medium

high

critical

critical

high

high

high

medium

high

high

high

high

high

high

critical

medium

critical

medium

high

high