Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - net：skbuff：通过 frag-transfer 帮助程序传播 shared-frag 标记 将 frag 从源移动到目标时，两个 frag-transfer 帮助程序（__pskb_copy_fclone（） 和 skb_shift（））无法在 skb_shinfo（）->flags 中传播 SKBFL_SHARED_FRAG 位。__pskb_copy_fclone（） 在复制 frag 描述符后将其余 shinfo 元数据推迟到 skb_copy_header（），但该帮助程序仅继承 gso_{size，segs， type}，从不接触 skb_shinfo（）->flags;skb_shift（） 直接移动 frag 描述符，不影响标记。因此，目标 skb 在将 skb_has_shared_frag（） 报告为 false 时，会保留对相同外部拥有的或页面缓存支持的页面的引用。不匹配对于任何使用 skb_has_shared_frag（） 来决定是否必须通过 skb_cow_data（） 绕过共享页面的就地编写器都是有害的。ESP 输入就是这样一个写入器（esp4.c、esp6.c），单一 nft“重复到 <local>”规则（或任何其他 nf_dup_ipv4（） / xt_TEE调用程序，就足以在剥离标记的情况下，在 esp_input（） 中登陆一个 pskb_copy（） 的 skb，让非特权用户通过 authencesn-ESN 杂散写入写入根拥有的只读文件的页面缓存。每当实际从源移动碎片描述符时，就在目标上设置SKBFL_SHARED_FRAG。skb_copy（） 和 skb_copy_expand（） 也共享 skb_copy_header（），但将所有分页数据线性化到新分配的 head 存储中并出现 nr_frags == 0，因此 skb_has_shared_frag（） 自行返回 false;他们不需要改变。skb_gro_receive（） 和 skb_gro_receive_list（） 中存在相同的遗漏。前者通过两条路径（直接 frag-move 循环和 head_frag + memcpy 路径）将传入 skb 的 frag 描述符移动到累加器的最后一个子 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-frags 耗尽时将frag_skb重新绑定为 list_skb 的内部开关不会将新frag_skb的标记折叠到 nskb 中。在两个地点折叠frag_skb的旗帜，以便从frag_list构件中绘制碎片的段带有标记。（CVE-2026-43503）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-43503

high Nessus 插件 ID 316600

版本 1.20