Netdev List
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: "tencentos_secure(TencentOS安全公共邮箱)"
	<tencentos_secure@tencent.com>,
	netdev@vger.kernel.org
Cc: David Ahern <dsahern@kernel.org>,
	 Ido Schimmel <idosch@nvidia.com>,
	 Paolo Abeni <pabeni@redhat.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Willem de Bruijn <willemb@google.com>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 Steffen Klassert <klassert@kernel.org>,
	 steffen.klassert@secunet.com,
	 Eric Dumazet <edumazet@kernel.org>
Subject: Re: [PATCH net v2 2/2] net/ipv4: reject appends with negative fragment copy
Date: Thu, 05 Nov 2026 21:51:37 -0500	[thread overview]
Message-ID: <willemdebruijn.kernel.20f8423db92c4@gmail.com> (raw)
In-Reply-To: <306E09760B4212AC+ipv4.6d58afc075934322860394a26ceaa2e8.2@tencent.com>

tencentos_secure(TencentOS安全公共邮箱) wrote:
> __ip_append_data() caps datalen at maxfraglen - fragheaderlen when more
> fragments are needed, and later computes
> 
> 	copy = datalen - transhdrlen - fraggap - pagedlen;
> 
> If transhdrlen + fraggap exceeds datalen, copy goes negative in the
> non-paged allocation branches, where pagedlen is zero, invalidating
> the offset/length accounting. In the paged allocation branch,
> pagedlen = datalen - transhdrlen - fraggap wraps unsigned instead.
> The subsequent copy calculation cancels to zero, so checking copy
> alone does not catch this invalid fragment geometry.
> 
> This is reachable independently of the xfrm fraggap bug fixed by the
> preceding patch. icmp_timestamp() passes a 20-byte transport header.
> With a small MTU and IPv4 options, the capped datalen can be smaller
> than that header even when fraggap is zero. The negative copy then
> propagates a negative offset into icmp_glue_bits(), and a timestamp
> reply with corrupted timestamp fields can be emitted.
> 
> For example, with MTU 68 and 40 bytes of IPv4 options, fragheaderlen
> is 60, maxfraglen is 68, datalen is capped at 8, and fraggap is zero,
> so the 20-byte transport header cannot fit.
> 
> Reject this geometry before allocation with -EINVAL, covering all three
> alloclen branches and matching the existing __ip6_append_data() guard.
> A negative copy cannot produce a valid append, so this does not reject a
> send that could otherwise construct a correct packet. All callers flush
> the cork on append error, and returning -EINVAL in mid-cork state already
> happens in this function (MSG_ZEROCOPY ubuf mismatch).
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anakin Zhang <tencentos_secure@tencent.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>

> ---
> v2:
> - Document the independently reachable ICMP Timestamp corruption path.
> - Distinguish negative copy in non-paged allocation branches from
>   unsigned pagedlen wrap in the paged allocation branch.
> - Update the subject and Fixes tag accordingly.
> - Drop the unrelated xfrm Reported-by tag; no code changes.
> 
>  net/ipv4/ip_output.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index b84d56c..5db8b06 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1105,6 +1105,11 @@ alloc_new_skb:
>  			fraglen = datalen + fragheaderlen;
>  			pagedlen = 0;
>  
> +			if (unlikely(transhdrlen + fraggap > datalen)) {
> +				err = -EINVAL;

nit: EMSGSIZE might be better

> +				goto error;
> +			}
> +



  reply	other threads:[~2026-11-06  2:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ipv4.6d58afc075934322860394a26ceaa2e8.0@tencent.com>
2026-11-05  7:34 ` [PATCH net v2 2/2] net/ipv4: reject appends with negative fragment copy =?gb18030?B?dGVuY2VudG9zX3NlY3VyZShUZW5jZW50T1Owssiruau5stPKz+Qp?=
2026-11-06  2:51   ` Willem de Bruijn [this message]
2026-11-05  7:34 ` [PATCH net v2 1/2] net/ipv4: reserve exthdrlen as headroom instead of counting it in skb->len =?gb18030?B?dGVuY2VudG9zX3NlY3VyZShUZW5jZW50T1Owssiruau5stPKz+Qp?=

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=willemdebruijn.kernel.20f8423db92c4@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=klassert@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.com \
    --cc=tencentos_secure@tencent.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox