CVE-2026-43503

总结

在 Linux 内核中，已解决以下漏洞：net: skbuff: 通过 frag 转移辅助函数传播共享 frag 标记。两个 frag 转移辅助函数（__pskb_copy_fclone() 和 skb_shift()）在将 frag 从源移动到目标时，未能传播 skb_shinfo()->flags 中的 SKBFL_SHARED_FRAG 位。__pskb_copy_fclone() 在复制 frag 描述符后，将 shinfo 元数据的其余部分留给 skb_copy_header() 处理，但该辅助函数只继承 gso_{size,segs,type}，从不触碰 skb_shinfo()->flags；skb_shift() 直接移动 frag 描述符，也让 flags 保持不变。结果是，目标 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 调用者——就足以让一个经 pskb_copy() 复制出的 skb 在标记被剥离的情况下进入 esp_input()，从而使无特权用户能够通过 authencesn-ESN 杂散写入，写入根拥有的只读文件的页缓存。只要 frag 描述符确实从源被移动，就在目标上设置 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() 中：前者通过两条路径（直接的 frag 移动循环以及 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() 中，该函数通过将 frag 描述符从 sk_write_queue 上的 skb 移动到新分配的 nskb，来构建 MTU 探测 skb。该辅助函数属于同一家族，理应得到同样的修复以保持一致；目前尚无已知的 TCP TX 侧就地写入者会通过这一缺口到达用户页面，但未来依赖该标记的消费者会悄然发生回归。同样的遗漏还存在于 skb_segment() 中：每次迭代的标记合并只取 head_skb 的标记，而且当 head_skb 的 frag 耗尽时，内部将 frag_skb 重新绑定到 list_skb 的 switch 语句也不会把新 frag_skb 的标记并入 nskb。在这两个位置都并入 frag_skb 的标记，以便从 frag_list 成员获取 frag 的分段携带该标记。

• CVE-2026-43503信息

  CVE-2026-43503

• dirtyclone-CVE-2026-43503