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;
> + }
> +
next prev parent 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