Re: [PATCH net 2/2] net/ipv4: fail append when the moved fraggap exceeds the fragment data

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Eric Dumazet wrote:
> Le lun. 26 oct. 2026 à 12:23, tencentos_secure(TencentOS安全公共邮箱)
> <tencentos_secure@tencent.com> a écrit :
> >
> > When the first fragment of a cork is already at maxfraglen, the next
> > __ip_append_data() iteration relays the previous fragment's tail,
> > fraggap = skb_prev->len - maxfraglen, into the new skb. The moved
> > fraggap is charged against datalen by computing
> >
> >         copy = datalen - transhdrlen - fraggap - pagedlen;
> >
> > but once datalen is capped at maxfraglen - fragheaderlen it can become
> > smaller than transhdrlen + fraggap. Then copy goes negative: no payload
> > is copied and the iteration makes no progress. Worse, in the paged
> > branch (MSG_SPLICE_PAGES / MSG_ZEROCOPY / GSO) pagedlen = datalen -
> > transhdrlen - fraggap additionally wraps unsigned, breaking the
> > alloclen + pagedlen == fraglen invariant that commit eca856950f7c
> > ("ipv4: account for fraggap on the paged allocation path") relies
> > on; the loop then either queues skbs with garbage tail accounting
> > (silent packet corruption) or, when maxfraglen == fragheaderlen,
> > never makes progress and grinds on until -ENOBUFS.
> >
> > Reject such an append before any allocation: if the moved tail
> > (transhdrlen + fraggap) cannot fit in the fragment's datalen, the
> > iteration cannot make progress, so fail with -EINVAL. This covers all
> > three alloclen branches, including the paged one. With the preceding
> > fix fraggap is bounded by the alignment slop, but the condition stays
> > reachable with extreme geometries (e.g. an effective mtu too small for
> > fragheaderlen + transhdrlen), so pin the geometry explicitly, as
> > __ip6_append_data() has done since commit 232cd35d0804 ("ipv6: fix
> > out of bound writes in __ip6_append_data()").
> >
> 
> I do not think this is reachable once patch 1 is applied.
> 
> ip_setup_cork() rejects cork->fragsize < 68 (inetdev_valid_mtu()), and
> fragheaderlen is at most 60, so a capped datalen is at least 8, and
> maxfraglen == fragheaderlen cannot happen.
> 
> transhdrlen is non zero only on the first iteration with an empty
> queue, where fraggap is 0, and current callers pass at most 8 bytes
> (UDP, ICMP, ping). On later iterations transhdrlen is 0 and, with
> patch 1, fraggap <= mtu - maxfraglen <= 7.
> 
> So transhdrlen + fraggap > datalen can not be true.

Supposedly there is a path where

    transhdrlen + fraggap > IPV4_MIN_MTU

icmp_timestamp sets transhdrlen to 20