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

  - net： skbuff：透過片段傳輸協助程式傳播共用片段標記 將片段從來源移動到目的地時，兩個片段傳輸協助程式 （__pskb_copy_fclone（） 和 skb_shift（）） 無法傳播 skb_shinfo（）->flags 中的SKBFL_SHARED_FRAG位元。__pskb_copy_fclone（） 在複製片段描述符後將其餘的 shinfo 元資料推遲到 skb_copy_header（），但該協助程式僅繼承 gso_{size，segs， type}，並且永遠不會觸及 skb_shinfo（）->flags;skb_shift（） 直接移動片段描述元並保持旗標不變。因此，目的地 skb 會保留對相同外部擁有或頁面快取支援頁面的參照，同時將 skb_has_shared_frag（） 報告為 false。對於任何使用 skb_has_shared_frag（） 來決定是否必須透過 skb_cow_data（） 繞道共用頁面的就地寫入器來說，這種不相符都是有害的。ESP 輸入就是這樣一個寫入器（esp4.c、esp6.c），而單個 nft 'dup to <local>' 規則（或任何其他 nf_dup_ipv4（） / xt_TEE調用者——就足以在 esp_input（） 中放置一個 pskb_copy（） 的 skb，並剝離標記，讓無權限的使用者透過 authencesn-ESN 雜散寫入 root 擁有的唯讀檔案的頁面快取中。每當片段描述元實際從來源移動時，在目的地上設定 SKBFL_SHARED_FRAG。skb_copy（） 和 skb_copy_expand（） 也共用 skb_copy_header（），但將所有分頁資料線性化到新分配的頭部儲存中，並以 nr_frags == 0 出現，因此 skb_has_shared_frag（） 自行傳回 false;他們不需要改變。skb_gro_receive（） 和 skb_gro_receive_list（） 中也存在相同的遺漏。前者會透過兩條路徑 （直接片段移動迴圈和 head_frag + memcpy 路徑） 將傳入的 skb 片段描述項移動到累加器的最後一個子 skb 中;後者將傳入的 skb 整個鏈結到 P 的frag_list上。下游 skb_segment（） 僅讀取 skb_shinfo（p）->flags，而 skb_segment_list（） 重複使用每個子 skb 的 shinfo 作為 nskb -- p 和 lp 都必須攜帶標記。tcp_clone_payload（） 中也存在相同的遺漏，它透過將片段描述項從 sk_write_queue 上的 skb 移動到新分配的 nskb 來建立 MTU 探測 skb。幫手屬於同一個家庭，並保證相同的修復以確保一致性;目前已知不會有 TCP TX 端就地寫入器透過此間隙連線到使用者頁面，但根據標記的未來取用者會以無訊息方式迴歸。skb_segment（） 中也存在同樣的遺漏：每次迭代旗標合併僅採用 head_skb 的旗標，並且在 head_skb片段耗盡時將 frag_skb 重新綁定到 list_skb 的內部開關不會將新frag_skb的旗標折疊到 nskb 中。在兩個地點折疊frag_skb的旗幟，以便從frag_list成員身上繪製碎片的部分攜帶標記。（CVE-2026-43503）

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

偵測

Linux Distros 未修補弱點：CVE-2026-43503

high Nessus Plugin ID 316600

版本 1.8