From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.222.42 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793027526; b=loAMGxgnPnsZn8yEylnzH2KYBW5Nz84NOEFwRREM241BFSAyTMF62v6Q9fIIKRcq5rCq T5t5z2iZxe9pxAGM0QOMTGE7J3jjrye1IEAYNpp1NSJOh1VTdhsvs/pDT2NzImn9Uy194 Qii3FmzTtMohiV4g1YzgTUWtqwzHz+4RVPsJ4xniwDsdWjV7cWJooEmq9C7d3T4h5q1RF smeZNkKjz39kWCmg6nqkzrd2YtopMXXGea1gIJyuj/A9DxeXepsKTgYbH1Yw/PPLCMGrn PP2SnHdO7o//UgzksI3sSUAmGbjLPJn41gYIw6Whg9YBXlCRy3YyFcowypHVgDp/i/Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793027526; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=18eqJR6kyQWwvlbFvPJ3uLv5+RhM/XmkF7e0poo81Lk=; b=1Zd7rfA1RXazFBySWdOoRPjRrAUkIN9sYQp3nXwXn9XYskkpX6zzyM9QMNLQ+5Z5CIGF 7iflA4z3dvPAaJTKl1ek2oc1qQnecY5I9CVhjqQBz/W0UHhPgY7YYr6iHM7wddwfexjRp 1A6+AlknDkzpef/fZIxwZ5tnqy1Yxxpxh3zGQj1RbbUcWF8/HcOSvDdg5JtSm6zRa5gg4 UFTwtZKOWJoJCQs4dG3HpWCGhSKAGLH/UIx7QmNhKrU5ojX981A4mCfoz9MhyELLsfTcs DjUmwCjGl3sOc/ommkz//6+xnY11AdefaFLAStf1O44SHEvG1nneGZgWBohdLRPFn9A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=I1o7tJok; arc=none smtp.remote-ip=209.85.222.42 Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FDC2606A33F for ; Mon, 26 Oct 2026 15:12:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 7FDC2606A33F Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=I1o7tJok Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-990a39ba4fbso707662241.0 for ; Mon, 26 Oct 2026 08:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1793027525; x=1793632325; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=18eqJR6kyQWwvlbFvPJ3uLv5+RhM/XmkF7e0poo81Lk=; b=I1o7tJokyf/ftDqohyfkLGfTgURnZwL6WadVmjXnhuhOtae10kjs1eJUkmu/BwK9w+ LUGDgAhNNTNphLY7v8040t8Ti2aJMaGDG6WDgIHBGQGoyqDDcfgH0TXrZYJmTeiq8ZYI hyTXHsHUEamtR+tm8GNbIL+M0gSb0jiZwUxtHIM9vwWV7s3DNTNW/+4qp5pzEIoG1e60 rknS21a0TP06KzKQHydtcAOPPbr55hMwH9r7tPrKM9vqHf4Ierb01XKKCpkLg9eAE3ti np80TPyLaqvBzutk+sSq/0iHvRGtIurdlae+DWZ5fmt/mqK/be+Wi9xaD24kduhk67kG in0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793027525; x=1793632325; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=18eqJR6kyQWwvlbFvPJ3uLv5+RhM/XmkF7e0poo81Lk=; b=d7kLW0NvTdGLbMIACxCUf/cOB01uXR4jBiWHUioeh/9VY7v4sYTnHrPuqyZXL40xHE Y8qrixc0PUeQGNNNOCgy1c3mYVBEfYp4lwcO4RgxBmt4f85h4TN57HBOsfEwB1gOW6J2 6NzJubbTEzHWmVCmRJ/8L3PsTmj5+CGGvp3iQikmzH1n1TnXQSv0t1pawRjB1cLqN6bJ rxKOfopKY7f3uz7c+/vpAAYbj7Vq/2vAKYCzGh6X8dySBUDoYNaiOc25xqlLHVp1ZzZr q38nyeLu9b2s9Or+szJdBWBZghL1akw+McP4+L5kql5OqPUBxqk8l3TwtB7iSBp1PYgh Dy4Q== X-Forwarded-Encrypted: i=1; AKwUvBzVVSosduuzxoaXM2AEj46oTNbuDVcLzFG1DYaOOycKCRHR18CyX6y3SpZZ2vF4dWw296N6mvk=@vger.kernel.org X-Gm-Message-State: AFq9FYKpw67rDvUw/lAgkz+fZ9SaPgjQWOZoekAlhLyv5NIz9+MxcMpn vIAmGdhEEEXMhjKi8HrdeMXH61WVztl482PAKY6mKva6bJpW9zKnu2gU X-Gm-Gg: AYBFou3w3ChfX56RGRKFXk39pIh+p3BVoAXPfa82q8f0Nl5fKKi++H4Kw+ukIzrb6S+ E90t9tIQTQkxoGGOCBiBlpuoozBio5Q5nxEcEwe7w/T7TCNZPI7LcqmH0kbLuGeFcsIExFuUFZA 3J52mgOYAaQtQDQEeSh88M/Q1aPZagNteegT/CvfNFrzfgernZXK9oT+v3OydlcfqloTeveec8d h7Dgr5G85yunO7IECr4sLtYHyVLcEfWv+By4wTzdXRQZkLqm5G1eUAoCTJj6tggnuP8FoYls84Y WGoWJtbJ2iIj13nkAKyYfBoMmGCbP7WAEXQzn+EXIILaN2wPbEQ6F7L0g9UnrTpdi44u1XIovpN voiUVHHrf0lju8JyLmpqi6pGDgpfFCSiQqH+np+MadXGmEMF48KyL5PWjyUwtq5M+0GN8qduG9t KqaOUzYWVd+5T1Q9hsSC5C0I/AqS6XULcfhnrXl8DT/E05/eIMvBbzG5PXGv2gc7IXfaXhiWRgi 5007stwYSc5+T5kQe72+a7LEJgXr+XRR/ja0eS2cl1hJJohs8DBsVpEgNpl8cXa4+N9wc9AvwPI PaSTArGYb7Kjea9uOXDpRoTu3xPO6QJc+ImjzE9zPcMbF6KMVdR1EFi9r8wC7d46wweagkV4CdD p6UuONJ3HoasQN2N9AK8= X-Received: by 2002:a05:6122:512:b0:5ea:c727:11fa with SMTP id 71dfb90a1353d-5ec22ed48bfmr2374687e0c.0.1793027525326; Mon, 26 Oct 2026 08:12:05 -0700 (PDT) Received: from gmail.com (111.46.245.35.bc.googleusercontent.com. [35.245.46.111]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5ec233f5148sm8676016e0c.6.2026.10.26.08.12.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2026 08:12:03 -0700 (PDT) Date: Mon, 26 Oct 2026 11:12:03 -0400 From: Willem de Bruijn To: =?UTF-8?B?5bmz5LmL?= , Greg KH , netdev Cc: "David S. Miller" , YOSHIFUJI , Ahern , stable Message-ID: In-Reply-To: References: <2026102604-circus-juvenile-c521@gregkh> <2026102658-jockey-volley-94ff@gregkh> Subject: Re: [PATCH net] ipv6: fix dead half of the MTU guard in __ip6_append_data() X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E5=B9=B3=E4=B9=8B wrote: > The second half of the MTU guard in __ip6_append_data() has been dead > code since the initial git import: > = > if (mtu <=3D fragheaderlen || > ((mtu - fragheaderlen) & ~7) + fragheaderlen <=3D sizeof(struct fr= ag_hdr)) > goto emsgsize; > = > (x & ~7) is unsigned and >=3D 0, and fragheaderlen is at least > sizeof(struct ipv6hdr) =3D 40 > sizeof(struct frag_hdr) =3D 8, so the > second condition can never be true. Commit 5e34af4142ff ("net: ipv6: > fix skb_over_panic in __ip6_append_data") tightened the first half > (mtu =3D=3D fragheaderlen) but left the dead second half in place. > = > For mtu - fragheaderlen in [1,7], (x & ~7) =3D=3D 0, so > = > maxfraglen =3D ((mtu - fragheaderlen) & ~7) + fragheaderlen - 8 > = > underflows below fragheaderlen. Every later bound computed as > maxfraglen - fragheaderlen then wraps to 0xfffffff8, in particular the > datalen clamp inside the fragment loop, which never fires and lets > fraglen =3D datalen + fragheaderlen escape the MTU constraint. > = > With MSG_MORE on an egress device without NETIF_F_SG, alloclen =3D mtu > while skb_put() is called with the unclamped fraglen, so a single > sendmsg() on a raw IPv6 socket with a 1240-byte HOPOPTS cmsg and > IPV6_MTU =3D fragheaderlen + 1 triggers: > = > skbuff: skb_over_panic: len:61280 put:61280 ... > [ 37.607856] kernel BUG at net/core/skbuff.c:214! > [ 37.607865] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP > ... > [ 37.616606] Call trace: > [ 37.616606] skb_panic+0x5c/0x60 (P) > [ 37.616778] skb_put+0x9c/0xa8 > [ 37.616952] __ip6_append_data+0xf80/0x1948 > [ 37.617172] ip6_append_data+0x94/0x2a8 > [ 37.617363] rawv6_sendmsg+0x588/0x988 > [ 37.617716] inet_sendmsg+0x4c/0xa8 > [ 37.617891] ____sys_sendmsg+0x268/0x308 > [ 37.618105] ___sys_sendmsg+0xb4/0x140 > [ 37.618299] __sys_sendmsg+0xa8/0x140 > = > Replace the dead expression with a direct check of the payload space > available in a fragment, which rejects mtu - fragheaderlen in [1,8]. > = > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org > Signed-off-by: bo cao Reviewed-by: Willem de Bruijn > --- > net/ipv6/ip6_output.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > = > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > index 25fe0ba98b1a..7d4d4d45e207 100644 > --- a/net/ipv6/ip6_output.c > +++ b/net/ipv6/ip6_output.c > @@ -1500,7 +1500,7 @@ static int __ip6_append_data(struct sock *sk, > rt->rt6i_nfheader_len; > = > if (mtu <=3D fragheaderlen || > - ((mtu - fragheaderlen) & ~7) + fragheaderlen <=3D sizeof(struct f= rag_hdr)) > + mtu - fragheaderlen <=3D sizeof(struct frag_hdr)) > goto emsgsize; Thanks for the patch. Not critical, but could even consider a single chec= k: if (mtu <=3D fragheaderlen + sizeof(struct frag_hdr)) Checkers may complain that the right hand side could overflow, but in practice fragheaderlen is bounded. > = > maxfraglen =3D ((mtu - fragheaderlen) & ~7) + fragheaderlen - > -- =