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

  - net/mlx5： LAG，修正單 FDB 錯誤復原中的差一錯誤 當索引 i 失敗時，mlx5_lag_create_single_fdb（） 中的反向清理迴圈會從 i 開始，因此失敗的索引本身會復原。這可以在未初始化的狀態上運作，或雙重拆卸規則，add_one路徑已經自行復原。從 i - 1 開始回復，以便只復原成功安裝的項目。（CVE-2026-72345）

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

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

  - 提示：防止 CONN_ACK tipc_sk_conn_proto_rcv（） 上的snt_unacked下溢 從未簽名的 16 位元傳送計數器snt_unacked減去對等提供的連線確認計數，而不檢查它是否超過實際未完成的訊息數：TSK->snt_unacked -= msg_conn_ack（HDR）;msg_conn_ack（） 直接從收到的 CONN_MANAGER/CONN_ACK 訊息中讀取。如果確認計數大於 snt_unacked，則減法會換行到接近最大值，使 tsk_conn_cong（） 永久為真，並使連接無法進一步傳輸。在CONN_ACK區塊開始時驗證 ACK 計數，如果訊息確認的訊息多於未完成的訊息，則捨棄訊息。否則，對等 （或針對本機連線，連線的對等通訊端） 可以透過傳送過大的連線確認來楔入 TIPC 連線的傳送端。CVE-2026-74282

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

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

  - drm/panthor：修正 group_process_tiler_oom（） 中潛在的無效指標解除參照 如果 heaps 是 ERR_PTR（），則 panthor_heap_pool_put（） 將取消引用無效指標。在這種情況下，請確保我們將其設定為 NULL。
    (CVE-2026-72387)

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

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

  - Debian Linux - suricata-update - 無 Ubuntu Linux - [不明說明] （CVE-2026-63347）

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

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

  - afs：處理 CB。沒有伺服器記錄的 InitCallBackState3 要求 快取管理員回呼路徑現在會透過 rxrpc 對等的應用程式資料，將伺服器記錄附加至傳入呼叫。不保證每個回呼要求都存在此關聯，而且大部分的回呼處理常式已經容許這種情況。
    製作 CB。InitCallBackState3 會遵循相同的模式，方法是在使用伺服器記錄之前檢查是否已附加伺服器記錄。如果對等未對應至伺服器記錄，請追蹤要求並忽略它，以符合其他不相符回呼要求的現有行為。這可讓回呼處理常式與快取管理員服務的其餘部分保持一致，並避免依賴可能無法用於指定要求的對等狀態。（CVE-2026-74425）

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

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

  - seg6：在讀取固定欄位之前驗證 SRH 長度 seg6_validate_srh（） 會讀取固定的 SRH 欄位，例如 srh->type 和 srh->hdrlen，然後再檢查提供的長度是否涵蓋固定結構ipv6_sr_hdr欄位。BPF SEG6 封裝路徑使用 BPF 程式提供的指標和長度來達到此目的：
    bpf_lwt_push_encap（） 和 SEG6 本機 BPF END_B6和END_B6_ENCAP動作會呼叫 bpf_push_seg6_encap（），它會將長度轉送至 seg6_validate_srh（），沒有最小大小的保護。因此，2 位元組 SEG6 封裝標頭可以使驗證器在超出呼叫者提供的緩衝區的位移 2 處讀取 srh->type。在讀取任何欄位之前，拒絕短於 seg6_validate_srh（） 頂端固定 SRH 的長度。這會修正 BPF 協助程式路徑，並保持通用驗證器的健壯性。（CVE-2026-72400）

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

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

  - mtd： rawnand：修正 'nand_select_target（）' 中的條件，此處的 'cs' 必須在 [0：nanddev_ntargets[ 範圍內。
    (CVE-2026-72165)

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

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

  - wifi： brcmfmac： cyw：修正短驗證框架上的堆積溢位 brcmf_notify_auth_frame_rx（） 從韌體事件中獲取框架長度並複製框架主體，並減去管理標頭位移：u32 mgmt_frame_len = e->datalen - sizeof（struct brcmf_rx_mgmt_data）;...memcpy（&mgmt_frame->u， frame， mgmt_frame_len - offsetof（struct ieee80211_mgmt， u））;唯一的長度檢查是 e->datalen >= sizeof（*rxframe），因此mgmt_frame_len可以是 0 之間的任何值。offsetof（struct ieee80211_mgmt， u） 為 24。
    當mgmt_frame_len低於該值時，減法會以無符號值換行至非常長的長度。然後，memcpy 會遠遠超過 kzalloc'd 緩衝區。惡意或故障的 AP 可能會在外部 SAE 驗證交換期間使幀變短，因此這是遠端觸發的堆積溢位。拒絕複製前短於管理標頭位移的影格。CVE-2026-72003

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

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

  - accel/amdxdna：調整 copy_to_user（） 的大小傳回使用者空間的資料量應受到應用程式提供的緩衝區大小的限制。如果緩衝區小於資料大小，請只傳回適合的部分，而不是失敗。（CVE-2026-74419）

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

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

  - ASoC： tegra： tegra210_ahub： 在檢查 item[0] 是否在列舉項目範圍內之前，驗證寫入的列舉值 tegra_ahub_put_value_enum（） 會讀取 e->values[item[0]]。因此，現有檢查發生得太晚，無法防止超出範圍讀取值陣列。將檢查移至陣列存取之前。（CVE-2026-74292）

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

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

  - batman-adv：在 batadv_interface_rx（） 中的 RX pskb_may_pull（） 上潛在的 skb realloc 可以重新配置 skb 後面的緩衝區後，擷取 ethhdr。指向舊緩衝區的變數需要重新指派，以避免出現釋放後使用問題。對於VLAN報頭已正確完成此操作，但對於乙太網路報頭則遺漏，乙太網路報頭稍後用於TT和AP隔離處理。（CVE-2026-72235）

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

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

  - 由於缺少路徑遊走驗證，本機非特權使用者可以透過 systemd-oomd IPC API 終止任意本機處理程序。（CVE-2026-15059）

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

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

  - ASoC： SOF： 拓蹼：修正 snd_sof_load_topology 中的記憶體洩漏 當拓蹼檔名包含虛擬且tplg_cnt為 0 時，函數會直接傳回 -EINVAL，而不會釋放 kcalloc（） 在第 2497 行配置的tplg_files。這會在每次此類拓撲載入嘗試時洩漏記憶體。透過設定 ret = 來解決此問題
    -EINVAL 並跳轉到 out： 標籤，該標籤已經處理了 kfree（tplg_files） 清理。
    (CVE-2026-72263)

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

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

  - 已解決 Linux 核心中的下列弱點：ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6().
    However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs. (CVE-2026-72429)

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

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

  - qede：修正 build_skb 故障時 BD 環消耗中的差一錯誤 qede_rx_build_skb（） 和 qede_tpa_rx_build_skb（） 不檢查來自 qede_build_skb（） 的 NULL 傳回。當它在記憶體壓力下傳回 NULL 時，函數在傳回 NULL 之前仍會從環中消耗 BD。然後，呼叫端回收額外的 BD，導致消耗一個額外的 BD（差一）。這會使 BD 環不同步，進而損毀 DMA 頁面參照計數，並導致 SLUB 自由清單損毀。提交 4e910dbe3650 （qede：使用前確認已配置 skb） 在 qede_build_skb（） 內新增了 NULL 檢查以防止 NULL 指標解除參照，但未解決調用方中缺少的 NULL 檢查，因此可以實現此 off-by-one。透過在 qede_rx_build_skb（） 和 qede_tpa_rx_build_skb（） 中新增對 qede_build_skb（） 傳回值的 NULL 檢查來解決此問題，並在任何 BD 環操作之前立即傳回 NULL。（CVE-2026-72339）

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

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

  - net/tls：消耗 tls_sw_read_sock（） 中的空資料記錄 對等體可以傳送零長度的TLS application_data記錄;TLS 1.3 明確允許這些作為流量分析對策 （RFC 8446，部分 5.1）。解密後，此類記錄的 full_len == 0。tls_sw_read_sock（） 將其交給 read_actor，該沒有可消耗的負載並返回零。迴圈將零返回視為背壓（使用<= 0），在rx_list頭重新排隊 skb 並停止。rx_list在下一次呼叫中以頭優先方式提供服務，因此空白記錄會出列、以相同方式失敗，然後再次重新排入佇列;連線上的每個後續記錄都會在其後面封鎖。tls_sw_recvmsg（） 不會因此而停滯：零長度資料記錄不會複製任何內容，而是會落入 consume_skb（）。透過在執行者執行、使用並繼續之前識別空白資料記錄，在 read_sock（） 路徑中鏡像它。（CVE-2026-72330）

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

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

  - ice：修正 ice_reset_all_vfs（） 中的 FDIR CTRL VSI 資源洩漏 重設所有 VF 會導致啟用 FDIR 篩選器的 VF 上資源洩漏，因為 CTRL VSI 只會失效而不會釋放。使用 ice_vf_ctrl_vsi_release（） 而不是 ice_vf_ctrl_invalidate_vsi（） 來修正，這會使行為與 ice_reset_vf（） 函式保持一致。重現：echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset （CVE-2026-72425）

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

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

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: TC, skip peer flow cleanup when LAG seq is unavailable mlx5_lag_get_dev_seq() will return error when the peer isn't in the LAG or when no device is marked as master. Result bad memory access and kernel crash[1]. Hence, skip the peer when lookup fails. Note: In case there are peer flows, they are cleaned before LAG cleared the master mark. [1] RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0x3d/0x350 [mlx5_core] Call Trace: <TASK> mlx5e_tc_clean_fdb_peer_flows+0xc1/0x130 [mlx5_core] mlx5_esw_offloads_unpair+0x3a/0x400 [mlx5_core] mlx5_esw_offloads_devcom_event+0xee/0x360 [mlx5_core] mlx5_devcom_send_event+0x7a/0x140 [mlx5_core] mlx5_esw_offloads_devcom_cleanup+0x2f/0x90 [mlx5_core] mlx5e_tc_esw_cleanup+0x28/0xf0 [mlx5_core] mlx5e_rep_tc_cleanup+0x19/0x30 [mlx5_core] mlx5e_cleanup_uplink_rep_tx+0x36/0x40 [mlx5_core] mlx5e_cleanup_rep_tx+0x55/0x60 [mlx5_core] mlx5e_detach_netdev+0x96/0xf0 [mlx5_core] mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core] mlx5e_vport_rep_unload+0xdd/0x110 [mlx5_core] __esw_offloads_unload_rep+0x81/0xb0 [mlx5_core] mlx5_eswitch_unregister_vport_reps+0x1d7/0x220 [mlx5_core] mlx5e_rep_remove+0x22/0x30 [mlx5_core] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xe8/0x1b0 device_del+0x159/0x3c0 mlx5_rescan_drivers_locked+0xbc/0x2d0 [mlx5_core] mlx5_unregister_device+0x54/0x80 [mlx5_core] mlx5_uninit_one+0x73/0x130 [mlx5_core] remove_one+0x78/0xe0 [mlx5_core] pci_device_remove+0x39/0xa0 (CVE-2026-72344)

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

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

  - gue：驗證 REMCSUM 專用選項長度 GUE 專用旗標可以指出存在遠端總和檢查碼卸載 meta 資料。私有旗標欄位本身由 guehdr_flags_len（） 負責，但 guehdr_priv_flags_len（） 目前即使設定了 GUE_PFLAG_REMCSUM也傳回 0。這允許僅具有私有旗標欄位的封包通過 validate_gue_flags（），然後 gue_remcsum（） 和 gue_gro_remcsum（） 從以下位元組讀取缺少的 REMCSUM 開始/偏移欄位。當存在GUE_PFLAG_REMCSUM時，請考慮GUE_PLEN_REMCSUM，以便在選項驗證期間拒絕格式錯誤的封包。
    (CVE-2026-72351)

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

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

  - mm/compaction：在 compaction_free（） 中正確處理 free_pages_prepare（），free_pages_prepare（） 可能會失敗，但 compaction_free（） 無法處理失敗的情況。失敗的頁面不應新增回 cc->freepages 以供將來使用，因為它們可以是 PageHWPoison 或 free_page_is_bad（），並且可能會導致資料損毀。（CVE-2026-72027）

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

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

  - btrfs：修正 __btrfs_run_delayed_refs（） 中無效的指標解除參照 在迴圈開始時，如果 'locked_ref' 目前為 NULL，我們嘗試透過呼叫 btrfs_select_ref_head（） 來取得鎖定的延遲參照頭，這可以傳回錯誤指標。如果錯誤指標是 -EAGAIN，我們執行 continue 並返回迴圈的開頭，這不會再次嘗試呼叫 btrfs_select_ref_head（），因為 'locked_ref' 不再是 NULL，而是 ERR_PTR（-EAGAIN），然後我們這樣做：
    spin_lock（&locked_ref->lock）;針對 ERR_PTR （-EAGAIN） 值，產生無效的指標解除參照。
    透過確保當 btrfs_select_ref_head（） 傳回 ERR_PTR（-EAGAIN） 時將 'locked_ref' 設定為 NULL 並同時遞增 'count' 來解決此問題，以防止無限迴圈。我們通過對循環的底部執行一個 goto 來做到這一點，該循環已經將 'locked_ref' 設定為 NULL 並執行 cond_resched（），並在 goto 之前遞增為 'count'。這些措施在提交 0110a4c43451 重構之前就已實施 （btrfs：重構__btrfs_run_delayed_refs迴圈），但在之後無意中遺失。
    (CVE-2026-74321)

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

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

  - fs/ntfs3：繫結的 DeleteIndexEntryAllocation 記憶體移動長度 在 do_action（） 的 DeleteIndexEntryAllocation 案例中，e->size 來自磁碟上的INDEX_BUFFER項目。當 e->size 使 e + e->size 點超越 hdr + hdr->used 時，PtrOffset（e1， Add2Ptr（hdr， used）） 傳回一個負ptrdiff_t，當傳遞給 memmove（） 時，該會無訊息地轉換為準無限size_t。然後，memmove 會經過目的地緩衝區。fslog.c：3540-3543 中的同級 DeleteIndexEntryRoot 案例已帶有對應的防護：if （PtrOffset（e1， Add2Ptr（hdr， used）） < esize ||Add2Ptr（e， esize） > Add2Ptr（lrh， rec_len） ||used + esize > le32_to_cpu（hdr->total）） { 轉到 dirty_vol; }將相同的圖形套用至分配路徑案例。也拒絕 esize == 0：memmove（e， e， ...） 是一個無操作，並且保持 hdr->used 不變，從現有的 check_index_header（） 遍歷中隱藏格式錯誤的項目。透過掛載特製的 NTFS 映像，在主線上的 UML+KASAN 8d90b09e6741 下重現：無人保護的 memmove 佔用 0xffffffffffffff00 的長度，核心在 do_action+0x36a2 框架上的 memmove+0x81/0x1a0 中出現。[almaz.alexandrovich@paragon-software.com：對更改進行了 clang 格式化]（CVE-2026-72197）

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

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

  - LoongArch： KVM：檢查 kvm_vcpu_ioctl_interrupt（） 中的 irq 有效性 可以從使用者空間呼叫函數 kvm_vcpu_ioctl_interrupt（），這裡在 kvm_vcpu_ioctl_interrupt（） 中新增 irq 有效性檢查。（CVE-2026-72294）

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

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

  - xen/gntdev：修正 ioctl 中的錯誤處理 當 gntdev_ioctl_map_grant_ref（） 在成功將映射新增至清單後，無法將操作結果複製回使用者空間時，錯誤路徑會傳回 -EFAULT，而不釋放 gntdev_alloc_map（） 取得的參照。對應會保留在參照計數為 1 的 priv->maps 中，造成記憶體洩漏和懸空清單項目。此外，gntdev_add_map（） 可能會修改 map->index 以避免與現有映射重疊。因此，必須在 gntdev_add_map（） 完成後取得傳回使用者空間的索引。透過跨 gntdev_add_map（） 保持互斥、擷取正確的索引和 copy_to_user（） 來解決此問題。如果 copy_to_user（） 失敗，請從清單中移除對應，並在仍保持鎖定的情況下釋放參照。透過正確處理所有錯誤案例來修正這些問題。（CVE-2026-72138）

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

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

  - KVM：arm64：nv：刪除虛假 WARN 以寫入 ZCR_EL2 客體完全有可能在巢狀內容中寫入 ZCR_EL2 sysreg 別名，因為如果將 FEAT_NV2 通告給 L1 hypervisor，這是預期的那樣。擺脫虛假的警告，由於此時安裝了炒作向量，因此具有hyp_panic的效果......（CVE-2026-72280）

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

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

  - HID： bpf：修正 hid_bpf_get_data（） 範圍檢查 hid_bpf_get_data（） 當呼叫端提供的位移和大小適合 ctx->allocated_size 內時，會傳回指向 HID-BPF 內容資料的指標。目前的檢查會先新增rdwr_buf_size和偏移，然後再將結果與 ctx->allocated_size 進行比較。由於這兩個值都是未帶正負號的，因此非常大的大小可以包裝 ctx->allocated_size 下方的總和，並使協助程式傳回指標，即使要求的範圍未包含在支援緩衝區中也一樣。使用 check_add_overflow（） 拒絕包裝的範圍結尾，然後再將請求的範圍結尾與 ctx->allocated_size 進行比較。
    (CVE-2026-72352)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei <n05ec@lzu.edu.cn>. (CVE-2026-72248)

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

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

  - accel/amdxdna：從 abo->mem.umap_list 移除物件之前，修正潛在的amdxdna_umap存留期爭用 amdxdna_umap_release（） 呼叫封鎖 mmu_interval_notifier_remove（）。如果 aie2_populate_range（） 同時執行，它可能會取得對正在發布的amdxdna_umap的參照，從而導致潛在的釋放後使用。取得參照時，在 aie2_populate_range（） 中使用 kref_get_unless_zero（）。如果參照計數已降至零，則釋放正在進行中，且會略過項目。（CVE-2026-72328）

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

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

  - 已解決 Linux 核心中的下列弱點：eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace:
    fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0
    __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0:
    kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede (CVE-2026-72393)

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

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

  - 已解決 Linux 核心中的下列弱點：cxl/region: Fix out-of-bounds access in cxl_cancel_auto_attach() In cxl_cancel_auto_attach(), it assumes cxled->pos is a valid index for accessing p->targets[]. However, cxled->pos can be set to negative errno in cxl_region_sort_targets() if cxl_calc_interleave_pos() fails. This causes the driver to use a negative index to access p->targets[], resulting in out-of-bounds access. Fix it by walking p->targets[] instead of using cxled->pos directly.
    (CVE-2026-74275)

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: fix WARN_ON for resident attribute in ntfs_map_runlist_nolock() When ntfs_map_runlist_nolock() needs to look up the attribute extent containing a target VCN (ctx_needs_reset == true), it calls ntfs_attr_lookup() and then expects the result to be a non-resident attribute, since only non-resident attributes have a mapping pairs array to decompress. A crafted NTFS image can place a resident attribute where a non-resident one is expected, causing ntfs_attr_lookup() to succeed but return a resident attribute record. Previously this was caught only by a WARN_ON(), which does not stop execution. The code then falls through to read a->data.non_resident.highest_vcn from what is actually a resident attribute, accessing the wrong union member and corrupting the VCN range check. The caller path triggering this warning during mount is:
    ntfs_map_runlist_nolock ntfs_empty_logfile load_system_files ntfs_fill_super In this path ctx is NULL, so ntfs_map_runlist_nolock() allocates a temporary search context internally and sets ctx_needs_reset = true.
    The existing resident-attribute guard in the ctx != NULL branch already returns -EIO silently for the same condition; make the ctx_needs_reset path consistent by replacing the WARN_ON() with the same -EIO error return. This causes the crafted image to be rejected with a mount error instead of triggering a kernel warning. (CVE-2026-72185)

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

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

  - NFSD：在 nfsd4_drop_revoked_stid（） nfsd4_drop_revoked_stid（） 中處理版面配置 stid 沒有SC_TYPE_LAYOUT情況，因此當用戶端為管理員撤銷的版面配置 stid 傳送FREE_STATEID時，預設分支會釋放 cl_lock 並返回，而不會取消雜湊或釋放 stid。stid 會保留在 IDR 和每個用戶端清單中，直到用戶端被銷毀為止。從每個用戶端清單中移除版面配置 stid 並呼叫 nfs4_put_stid（） 刪除建立參照。當參照計數達到零時，nfsd4_free_layout_stateid（） 會處理剩餘的清理作業：取消柵欄工作程式、從每個檔案清單中移除，以及釋放 slab 物件。（CVE-2026-74316）

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

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

  - bpf：透過在 bpffs 提交 4f375ade6aa9 中還原 RCU 延遲的 inode 釋放來修正 UAF （bpf：使用內部結構取消固定 htab 時避免 RCU 上下文警告） 將 inode 清理從 ->free_inode（） 移至
    ->destroy_inode（） 來避免調用 bpf_any_put（） 時在 RCU 上下文中休眠。然而，這消除了釋放 inode 本身和緩存的符號鏈接主體 （i_link） 時的 RCU 延遲，兩者都可以通過 RCU pathwalk（pick_link、may_lookup 等）訪問。當並發的 unlinkat（） 刪除最後一個 inode 參照並 destroy_inode（） 立即釋放 inode，而另一個任務仍在 RCU 模式下遍歷路徑並讀取 current_time（） -> is_mgtime（） 內的 inode->i_opflags（偏移量 +2），這會導致釋放後使用。KASAN 報告： 錯誤：KASAN：在 is_mgtime include/linux/fs.h：2313 在 addr ffff8880407e4282 讀取大小 2 （位移量 +2 = i_opflags） 規則（根據 Al Viro）：立即調用 ->destroy_inode（），可以休眠，用於阻止清理，例如 bpf_any_put（） ->free_inode（） 在 RCU 寬限期後調用，用於釋放 inode 和任何 RCU 可存取的內容，例如 i_link 修復： 正確地拆分這兩個問題： - 將 bpf_any_put（） 保留在 bpf_destroy_inode（） 中，因為它正在阻塞並且需要及時執行 - 引入 bpf_free_inode（） 以適當的 RCU 延遲處理 kfree（i_link） 和 free_inode_nonrcu（），從而防止 UAF （CVE-2026-74363）

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

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

  - wifi：mt76：在 mt76_put_vif_phy_link mt76_put_vif_phy_link（） 中使用 kfree_rcu 進行通道外連結會在 rcu_assign_pointer（NULL） 之後釋放帶有純 kfree（） 的通道外 mlink。但是，rcu_assign_pointer只會阻止未來的 RCU 讀取器取得指標 -- 它不會等待已經透過 rcu_dereference 持有指標的現有讀取器。TX 資料路徑 （例如 mt7996_mac_write_txwi） 會在 rcu_read_lock 下解除參照 mlink->wcid 和 mlink->idx。如果 TX softirq 在 NULL 指派之前透過 rcu_dereference 取得指標，則會在 kfree 之後取消參照釋放的記憶體。struct mt76_vif_link 已經包含一個在此免費網站上未使用的 rcu_head 欄位 -- 開發人員的疏忽，因為相鄰的 kfree_rcu_mightsleep 在同一函式中對rx_sc的呼叫顯示模式已被理解。將 kfree（mlink） 替換為 kfree_rcu（mlink， rcu_head）。（CVE-2026-74325）

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

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

  - dm-integrity：如果 bio 超出限制，則修正錯誤 如果 dm_integrity_check_limits 失敗，程式碼將以 DM_MAPIO_KILL 結束。然而，此時範圍已經被鎖定，並且不會解鎖，從而導致死鎖。讓我們將限制檢查上移，這樣當它結束時，不會洩漏任何資源。（CVE-2026-72100）

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

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

  - wifi： rtw88：修正 AER 處理常式中錯誤的pci_get_drvdata類型 rtw88 在探測時透過 pci_set_drvdata（） 儲存ieee80211_hw指標，但 io_error_detected（） 和 io_resume（） 會擷取它作為net_device指標。這會導致 netif_device_detach/attach 在ieee80211_hw結構上運行，以錯誤的位移讀取和寫入。請改用 ieee80211_stop_queues/wake_queues，與驅動程式中的所有其他佇列停止/啟動路徑一致。（CVE-2026-74412）

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

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

  - IIO：磁力計：AK8975：修正潛在的核心堆疊記憶體洩漏 目前在驅動程式中 AK8975 ，有四種可能發生未初始化核心堆疊記憶體洩漏的情況。如果 i2c_smbus_read_i2c_block_data_or_emulated（） 傳回的值小於緩衝區大小，則未初始化的位元組會保留在緩衝區中，稍後緩衝區會傳遞至 IIO 緩衝區，可能會將記憶體洩漏到使用者空間。藉由新增檢查函式的傳回值是否等於緩衝區的大小，以及隨後的值是否小於零，以與傳回的錯誤碼區分開來修正此問題。（CVE-2026-72481）

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

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

  - dibs： loopback：驗證 move_data（） 中的偏移和大小 回送 move_data（） 會對已註冊的 DMB 執行 memcpy，而不檢查偏移量 + 大小是否超過 DMB 長度。與原生強制執行記憶體區域界限的真實 ISM 硬體不同，軟體回送沒有此類保護。對等提供的越界位移或過大的寫入會導致 OOB 寫入超過配置的核心緩衝區。在 memcpy 之前新增明確的邊界檢查，以使用 -EINVAL 拒絕此類要求。
    (CVE-2026-72018)

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

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

  - net：ip6_gre：需要在裝置 netns 中CAP_NET_ADMIN，以便在最多兩個 netn 上運作 changelink ip6gre_changelink（） 和 ip6erspan_changelink（） 兩個 netn，即 dev_net（dev） 和通道連結 netns t->net。一旦裝置在執行要求的 netns 中建立或移動至 netns 以外的 netns，它們就會有所不同。rtnl changelink 路徑僅針對 dev_net（dev） 檢查CAP_NET_ADMIN，因此在 t->net 中具有權限但不在 t-net 中的呼叫者可以重寫位於 t->net 中的隧道。在剖析任何屬性之前，在頂部的 rtnl_dev_link_net_capable（） 上對這兩個操作進行門禁。（CVE-2026-72052）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint.
    Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN. (CVE-2026-72279)

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

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

  - USB：主機：MAX3421：修正 max3421_hub_control（） 中的越界移位 「max3421_hub_control（）」函式處理對虛擬根集線器的 USB 集線器類別要求。在 'ClearPortFeature' 和 'SetPortFeature' 切換陳述式的 'default' 分支中，它會透過將要求的 'value' 參數左移 1 來修改 'max3421_hcd->port_status'。不過，它不會驗證此移位是否會超過「port_status」的寬度。因此，如果透過 /dev/bus/usb/.../001 存取根集線器的惡意使用者空間任務發出 'wValue' 大於或等於 32 的USBDEVFS_CONTROL ioctl，則左移操作會叫用移位越界未定義行為。這會導致 'port_status' 的任意位損毀，包括通常不可變的變更位，這可能會繞過內部狀態檢查並混淆集線器狀態。在執行移位之前，請先拒絕其「值」超過移位寬度的要求，以修正此問題。此問題是使用我目前正在開發的核心驅動程式的基於 KLEE 的符號執行工具發現的。（CVE-2026-72483）

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

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

  - 裝置屬性：初始化 fwnode_init（） 中剩餘的 fwnode_handle 欄位 如果韌體節點是在堆疊 （例如：我們控制其生命週期的臨時軟體節點） 或堆積上分配的 （但使用非清零分配函數） 並使用 fwnode_init（） 進行初始化，則其輔助指標將包含未初始化的記憶體，該記憶體可能既不是 NULL 也不是 IS_ERR（），因此最終可能會被取消參照 （例如： 在 dev_to_swnode（）） 中。初始化時將 fwnode->secondary 設定為 NULL。同時：也初始化 struct fwnode_handle 的其餘字段以確保安全。[ 修正提交訊息中的錯別字。- 達尼洛 ] （）CVE-2026-68461

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

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

  - cifs： 修正 cifs_issue_read（） 中失敗時缺少的點數釋放 修正 cifs_issue_read（） 中失敗路徑中缺少的點數釋放，以免重試子索引只會覆寫點數值。
    (CVE-2026-72356)

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

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

  - net： microchip： vcap：修正共用 Super VCAP 區塊上的爭用 晶片上的 VCAP 執行個體不是獨立的，但它們是獨立鎖定的。在 sparx5 和 lan969x 上，IS0 和 IS2 執行個體由相同的 Super VCAP 硬體區塊支援，並共用其快取和命令暫存器：每次存取都會驅動共用VCAP_SUPER_CTRL暫存器，並透過共用快取暫存器移動資料。因此，存取一個執行個體會與存取另一個執行個體競爭。每個執行個體的 admin->lock 無法防止這種情況發生，因為每個執行個體都會採用不同的鎖定。鎖定問題主要被 vcap API 的核心用法在 rtnl 下執行這一事實所掩蓋。不過，debugfs 中的完整規則轉儲會直接從硬體解碼規則 （READ 命令後面接著快取讀取） 並在 rtnl 外部執行，因此它會爭用並行 tc-flower 規則寫入至另一個 Super VCAP 執行個體。除了損毀傾印之外，讀取還會在寫入器快取填滿與其寫入命令之間重新填入共用快取，因此寫入器會認可錯誤的數據，並損毀硬體項目。引入 vcap_lock（） 和 vcap_unlock（） 協助程式，並透過它們路由 VCAP API 中的每個規則鎖定網站及其 debugfs 程式碼。將每個執行個體的 admin->lock 替換為結構vcap_control中的單一互斥，以序列化對所有執行個體的存取權。協助程式會透過新的 admin->vctrl 反向指標來存取它，而用戶端會初始化並破壞控制鎖定，而不是每個執行個體的鎖定。沒有任何路徑保留多個執行個體鎖定，因此將它們收合到單一互斥上無法自行鎖死。
    (CVE-2026-72340)

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

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

  - 已解決 Linux 核心中的下列弱點：tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: if (needs_md5) { tcp_ao_destroy_sock(sk, false); } else if (needs_ao) {tcp_clear_md5_list(sk); kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); } Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves
    -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag] (CVE-2026-72139)

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

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

  - vduse：在開放路徑中保持 IDR 查詢的 vduse_lock，vduse_dev_open（） 透過 IDR 查詢結構vduse_dev，然後僅在刪除 vduse_lock 後才取得 dev->lock。這會留下一個窗口，讓並行VDUSE_DESTROY_DEV可以從 IDR 中移除相同的物件，並在開放路徑鎖定裝置之前釋放它，從而導致釋放後使用。在開啟路徑中取得 dev->lock 之前，保留 vduse_lock 來關閉此爭用，以符合銷毀路徑已使用的鎖定順序。
    (CVE-2026-74313)

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

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

  - sunrpc：當取消輸掉爭用時，等待正在進行的TLS握回呼 當 svc_tcp_handshake（） 中的 wait_for_completion_interruptible_timeout（） 傳回 0 （逾時） 或 -ERESTARTSYS （訊號），然後 tls_handshake_cancel（） 傳回 false 時，handshake_complete（） 已贏得取消爭用：它已設定 HANDSHAKE_F_REQ_COMPLETED 並即將叫用 svc_tcp_handshake_done（） 時， 但回調對 xpt_flags 和 SVSK->sk_handshake_done 的副作用尚未生效。目前的程式碼會立即讀取xpt_flags，以判斷會話是否成功。結果是兩場比賽。如果回呼已執行 set_bit（XPT_TLS_SESSION），但尚未執行 clear_bit（XPT_HANDSHAKE），則 svc_tcp_handshake（） 會看到會話、將傳輸排入佇列，然後傳回。然後svc_xprt_received（） 清除XPT_BUSY，背景工作執行緒挑選傳輸，svc_handle_xprt（） 中的分派器觀察到XPT_HANDSHAKE仍然設定，並再次叫用xpo_handshake。該 svc_tcp_handshake（） 呼叫 init_completion（&svsk->sk_handshake_done），而原始回呼同時呼叫其上的 complete_all（），從而損壞了嵌入的swait_queue。如果回呼已設定HANDSHAKE_F_REQ_COMPLETED但尚未輸入 svc_tcp_handshake_done（），則 svc_tcp_handshake（） 會將 XPT_TLS_SESSION 讀取為清除，並中斷連線，即使交握即將成功。等待回呼提交後再檢查xpt_flags。完成保證會觸發，因為 handshake_complete（） 會在設定HANDSHAKE_F_REQ_COMPLETED後無條件叫用 svc_tcp_handshake_done（）。（CVE-2026-72221）

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

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

  - xprtrdma： 剖析之後清理回覆信用額度授與 rpcrdma_reply_handler（） 中的out_norqst結束程式在信用限制之前分支，因此不符合任何擱置要求的回覆會到達out_post攜帶從網路剖析的原始信用值。rpcrdma_post_recvs（） 不綁定其 @needed 參數：重新填充迴圈分配並鏈結接收 WR，直到計數滿足或分配失敗。因此，傳送格式正確的回覆，其中包含未知的 XID 和誇大的信用授予，會驅動代表配置，並在每個此類回覆上過re_max_requests接收過帳。將限制移至剖析 credit 欄位之後，在第一個可以到達 out_post 的分支之前，以便每個稍後的消費者都會看到已清理的值。cwnd 更新會保留在相符的要求路徑上。
    (CVE-2026-72465)

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

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

  - netfs：修正回寫錯誤處理 修正 writeback_iter（） 迴圈中的錯誤處理。如果發生錯誤，則需要再次呼叫 writeback_iter（），並將 *error 設定為錯誤，以便清理迭代狀態。此外，當前的對開本需要解鎖和重新髒污。（CVE-2026-72364）

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

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

  - 已解決 Linux 核心中的下列弱點：sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.
    (CVE-2026-72220)

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

ID	名稱	嚴重性
337471	Linux Distros 未修補弱點：CVE-2026-72345	high
337470	Linux Distros 未修補弱點：CVE-2026-74282	high
337469	Linux Distros 未修補弱點：CVE-2026-72387	medium
337468	Linux Distros 未修補弱點：CVE-2026-63347	critical
337467	Linux Distros 未修補弱點：CVE-2026-74425	high
337466	Linux Distros 未修補弱點：CVE-2026-72400	high
337465	Linux Distros 未修補弱點：CVE-2026-72165	high
337464	Linux Distros 未修補弱點：CVE-2026-72003	high
337463	Linux Distros 未修補弱點：CVE-2026-74419	high
337462	Linux Distros 未修補弱點：CVE-2026-74292	high
337461	Linux Distros 未修補弱點：CVE-2026-72235	high
337460	Linux Distros 未修補弱點：CVE-2026-15059	medium
337459	Linux Distros 未修補弱點：CVE-2026-72263	medium
337458	Linux Distros 未修補弱點：CVE-2026-72429	critical
337457	Linux Distros 未修補弱點：CVE-2026-72339	critical
337456	Linux Distros 未修補弱點：CVE-2026-72330	high
337455	Linux Distros 未修補弱點：CVE-2026-72425	high
337454	Linux Distros 未修補弱點：CVE-2026-72344	high
337453	Linux Distros 未修補弱點：CVE-2026-72351	critical
337452	Linux Distros 未修補弱點：CVE-2026-72027	high
337451	Linux Distros 未修補弱點：CVE-2026-74321	high
337450	Linux Distros 未修補弱點：CVE-2026-72197	high
337449	Linux Distros 未修補弱點：CVE-2026-72294	high
337448	Linux Distros 未修補弱點：CVE-2026-72138	medium
337447	Linux Distros 未修補弱點：CVE-2026-72280	high
337446	Linux Distros 未修補弱點：CVE-2026-72352	high
337445	Linux Distros 未修補弱點：CVE-2026-72248	critical
337444	Linux Distros 未修補弱點：CVE-2026-72328	high
337443	Linux Distros 未修補弱點：CVE-2026-72393	critical
337442	Linux Distros 未修補弱點：CVE-2026-74275	high
337441	Linux Distros 未修補弱點：CVE-2026-72185	critical
337440	Linux Distros 未修補弱點：CVE-2026-74316	high
337439	Linux Distros 未修補弱點：CVE-2026-74363	high
337438	Linux Distros 未修補弱點：CVE-2026-74325	high
337437	Linux Distros 未修補弱點：CVE-2026-72100	high
337436	Linux Distros 未修補弱點：CVE-2026-74412	high
337435	Linux Distros 未修補弱點：CVE-2026-72481	high
337434	Linux Distros 未修補弱點：CVE-2026-72018	high
337433	Linux Distros 未修補弱點：CVE-2026-72052	high
337432	Linux Distros 未修補弱點：CVE-2026-72279	critical
337431	Linux Distros 未修補弱點：CVE-2026-72483	high
337430	Linux Distros 未修補弱點：CVE-2026-68461	high
337429	Linux Distros 未修補弱點：CVE-2026-72356	high
337428	Linux Distros 未修補弱點：CVE-2026-72340	high
337427	Linux Distros 未修補弱點：CVE-2026-72139	critical
337426	Linux Distros 未修補弱點：CVE-2026-74313	high
337425	Linux Distros 未修補弱點：CVE-2026-72221	critical
337424	Linux Distros 未修補弱點：CVE-2026-72465	high
337423	Linux Distros 未修補弱點：CVE-2026-72364	high
337422	Linux Distros 未修補弱點：CVE-2026-72220	critical

偵測

Nessus 的 Misc. 系列

high

high

medium

critical

high

high

high

high

high

high

high

medium

medium

critical

critical

high

high

high

critical

high

high

high

high

medium

high

high

critical

high

critical

high

critical

high

high

high

high

high

high

high

high

critical

high

high

high

high

critical

high

critical

high

high

critical