From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E023333AD88 for ; Fri, 17 Jul 2026 19:34:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.175 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784316848; cv=pass; b=NsBiXU+gLeK/omGuz+FjtwH3o0PKQIJ6wgKR8aN+/L7gC6rM3s/6MeeFNfosOJrdnV/+jwu9m/zdvrWtjrzPXXQmv5TorjhbgvPxrIjty6Ev5ikIHMXtr347o7I//eU1S12esqSyOLTnul3fpacKLeFR2+FfmpramVAt1knuCqs= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784316848; c=relaxed/simple; bh=Z2+x0bVuX2JZuXF66F8NzOj726FZhm0l0KRuCmFB0LE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=I7xwbDDhnY8wQMv8RbJ6Ywv1lqM9LV+kAD5MRPEIJtsmcB5iRKcB2fh93cjKA3KfaOVE7OBhJS4Ndjq4bbdIPq5eiBwqaGEXD/J6pm5821Ojyyjy3Nc0Sp5IW/KYtxt7y5mEr46kQKNB/+8IGwiNApsKDQzLcQhMBvxbZ0zt9ew= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GhpA09/D; arc=pass smtp.client-ip=209.85.160.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GhpA09/D" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-51c01089e8aso35416041cf.2 for ; Fri, 17 Jul 2026 12:34:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784316846; cv=none; d=google.com; s=arc-20260327; b=EoS/x3s8DDg1uNI4SvNljPwfdzFOqBiZks38D4567lZKSc9nddijybZAA4wL3UNOAq tiJNQtkIc3e+46ESawmx5f6pfgclzaZoP2wcRJ5Zs/E65PSkgiB0AYgVgCHVrMIY6n2z luFcwRsF7xTki85j2YWv7uwod4FjjNy4slXhxmarPsOECrqzWB0N9fMhfZGAedwwewDF i6Kl/1vPDYgJaDWyJh4oI/oADGKsHx1EIB2gRqaLX86c+uqPss4tRxCnDGf4//O2rztj 3WRsjS+EUqyR/BAF+lQ2tqCk39+hB16Dd2EUkohZ2PE86f3hclm1+hLmRAvqJuJHtUOu wdZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0VXJKOtnkf44j+tQQsqQzA0l3vLSi+Q72kwccQQQrtI=; fh=C1oYpdwUQaua6sCHKWBa74ME8yse8TQWG+ofpXj0za8=; b=ncN7r2Jtphni0Ju5Ze+QupDY+IgH6P1xYTQmfQTnbbZrA8TlULnzTrJjnF59c5QHvn vnqa5FRNFjt/fdaeeVnDuWUTRwNdYJXgVbjfs8wO9h7v3fUyYu9T5UKg9PiEwiMz3Pis GuY+7sH7iKeoKX3LhYsTh2ChOEikZV9g6KMHEs6rC3Tq8dHZPRXFzKfstQdJ+x4jn2sB Shg4F7Ngct4z8ptk8KRHG/JrKN7ZfqRLHrqsK210mXLQbOVaUOp01NCj36FVvUWPlUqj o3hY6TX+a0aSrNufRjgjFnx5GxX4hhUIcJ0uXhRevmWq7wCnRL6Ux3izke4PzuM+E3fL YTDA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784316846; x=1784921646; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=0VXJKOtnkf44j+tQQsqQzA0l3vLSi+Q72kwccQQQrtI=; b=GhpA09/DoCfXdyGGw7zJ9bP9uoHcFXAbDYNrOfZd4UlF6r56MqXBISyGIx0DH/aA+8 flc7lUkG2oUgoH+SEAnwAWbY600DXVGjWpnBy9jxSUoMCWJQb+eCSukiujd8/C3fOhn5 VFWqs9q9rCDcJgKCFmwZFGrX5QAtWniCUAuW5ajgJl5qX0QYd4I7gUd3anDnsoxYlR2N GsytER35otGTNYcygF2S+3nvQLb7JN7ql6TcKD22THvKQcHMcqqyqCEZIqPRO1wV9HfD Y2opmcQUoxDtfe244ASkRTcS7TugCUGj10aQhJA+w01AQAFu7xg1esbIO02vwCeDhA4h Cz3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784316846; x=1784921646; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0VXJKOtnkf44j+tQQsqQzA0l3vLSi+Q72kwccQQQrtI=; b=lcGOduS/MgVkx/wggCBUHKjTgkgDgQoYExRZTiroxTqrh/PBiRk2l4HwoRAj3XnmMa /LGGTSoVX1S5ohOMV5NTpKLlRbOt1HrW0N+ag5wLT9RBckdCOAZYEu6N60IFnGvQi4iA ihjrldMq4hd7o0WSYG5lonHGnf5wulrWuJ+bIhFa0Ftt+8u/qVtA2yXkje+XAL8bzY7a DGgnwX18QIJ220bBYoRMB2De0M0N2UPKcFYZ4YPqO+dZ/f4HapeBwtvP78OajyFhO1jR KCWqmszzg3gTTMAgZtLeDk4sYZCPqsEIG1u+a63DRsLEJHSmvPgVn2dIL+ix8D9OtXvA VWYw== X-Forwarded-Encrypted: i=1; AHgh+RraAHbRl/TuLwepZZAooJjaOyN1Edqe1FH6vDlosURJ2Nz3jfG5nHrPV5PpaLAY7hQrC94T9MvepD9/MlE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzgn2Ahim3yxoZ2rvLIVkXuG/Vw0ioeyoCH80BEwUVJJGk7fTZJ TgQIjY1/Z1DUDYYGiFW7h03dcrsZ+6ZhkWpk+7YztdDTpulvariFV/P0OJ/6O8oSQFumXXLvMrC vCfCyf/PP92EVEdjUzLal04+2dYsni06RQs52LtWV X-Gm-Gg: AfdE7cm4ClOjlEnetg/9QM90RVPS8qxFLCW2jXU7fyQLBMHzURJfkqXNUmewZh1vRoC 6bsXOv5UjjVNlAZSdThrnsAVSf7qkYHzIX2YQR92B5YtHTJ5tvYIRE1QXes4W/CuBIFAUV71LQP 4Zfnu1FyAjm8lH74Zjm06BHHRkZ7IcsdODydWP8DyALLzE1Pdy6IvT3qvghBJ7ImH6G5a5ohsdY XAHAhVK6OjXnieuRhIZnSRYW/Fl8dsxTaITKokbJ7hDEAwK2Q5b+jPF/RPw9TVJqn6TSJQ7vj9Z 2BuIH8qqRP3zhSOsCwdXZwRAbU8P0Icc4MWJ5bXSJhqT8zAZISQlClX2nA4qo59sBxBWKfPQE5x LCsCPfmSX X-Received: by 2002:a05:622a:a05:b0:51c:1c00:e46 with SMTP id d75a77b69052e-5213c7e8436mr37586171cf.25.1784316845085; Fri, 17 Jul 2026 12:34:05 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260717074109.686170-1-yangyx22@mails.tsinghua.edu.cn> In-Reply-To: <20260717074109.686170-1-yangyx22@mails.tsinghua.edu.cn> From: Eric Dumazet Date: Fri, 17 Jul 2026 21:33:52 +0200 X-Gm-Features: AUfX_mzjSXpXhmgPyFW5IUal0VGKT4ixqqI6k9wW0PNFr2YNbw4acNqb_17YTjk Message-ID: Subject: Re: [PATCH net] ipv4: reject impossible oversized fragments at queue time To: Yuxiang Yang Cc: netdev@vger.kernel.org, dsahern@kernel.org, idosch@nvidia.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Yizhou Zhao , Ao Wang , Xuewei Feng , Qi Li , Ke Xu , yyxroy22@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2026 at 9:41=E2=80=AFAM Yuxiang Yang wrote: > > ip_frag_queue() computes each incoming fragment's end offset and may > store it in qp->q.len without checking that the fragment can fit within > the 65535 byte IPv4 datagram limit, even with the minimum IPv4 header. > The only 65535 byte check lives later in ip_frag_reasm(), after the > fragment has already been accepted into the reassembly queue and has > updated its state. > > A fragment whose end offset exceeds 65535 minus the minimum 20-byte IPv4 > header cannot be part of any valid IPv4 datagram. Letting it update > qp->q.len leaves the shared reassembly queue with an impossible expected > length. A later legitimate two-fragment datagram sharing that key can no > longer complete reassembly and is not delivered. > > This was verified at runtime on Linux 6.12.93-0-virt. A same-key > oversized-fragment injection (offset 65528, payload 8, end 65536) drove > legitimate two-fragment UDP delivery from 8/8 to 0/8, while a cross-ID > control stayed at 8/8. > > With this change applied to net main, the same-key test delivered 8/8. > A valid 65535-byte datagram with a 20-byte header was also delivered with > both in-order and reverse-order fragments; its 65507-byte UDP payload > was intact in both cases. > > Add a per-fragment bound check in ip_frag_queue() right after computing > end and before any qp->q.len update or skb insertion. IPv4 always needs > at least a struct iphdr, so an end offset greater than IP_MAX_MTU minus > sizeof(struct iphdr) cannot fit in any valid IPv4 datagram. Use that > minimum-header bound rather than the current fragment's IHL because > fragments may arrive out of order and the first fragment may carry > non-copied options that later fragments lack. The existing check in > ip_frag_reasm() continues to validate the final length against the > actual header length of the first fragment. > > Drop only the invalid skb so an existing queue for the same key remains > intact. I have a hard time understanding the issue. This is an invalid packet, why should we add more bloat to the kernel just to 'optimize' this case? You understand that IP frags are unreliable no matter how hard we try to 'fix' them, right ? > > The issue was found by Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, > Qi Li, and Ke Xu, with assistance from GLM-5.2 by Z.ai. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org > Signed-off-by: Yuxiang Yang > --- > net/ipv4/ip_fragment.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c > index c790d2f49..32e5240a5 100644 > --- a/net/ipv4/ip_fragment.c > +++ b/net/ipv4/ip_fragment.c > @@ -291,6 +291,8 @@ static int ip_frag_queue(struct ipq *qp, struct sk_bu= ff *skb, int *refs) > /* Determine the position of this fragment. */ > end =3D offset + skb->len - skb_network_offset(skb) - ihl; > err =3D -EINVAL; > + if (end > IP_MAX_MTU - sizeof(struct iphdr)) > + goto err; > > /* Is this the final fragment? */ > if ((flags & IP_MF) =3D=3D 0) { > -- > 2.34.1 >