From: bo cao <treebacker@foxmail.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
dsahern@kernel.org, edumazet@kernel.org, idosch@nvidia.com,
horms@kernel.org, willemdebruijn.kernel@gmail.com,
stable@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net v4] ipv6: fix dead half of the MTU guard in __ip6_append_data()
Date: Mon, 2 Nov 2026 09:57:36 +0800 [thread overview]
Message-ID: <tencent_0A4B784EEB3D358B09B43AA2B2F13AE44505@qq.com> (raw)
The second half of the MTU guard in __ip6_append_data() has been dead
code since the initial git import:
if (mtu <= fragheaderlen ||
((mtu - fragheaderlen) & ~7) + fragheaderlen <= sizeof(struct frag_hdr))
goto emsgsize;
(x & ~7) is unsigned and >= 0, and fragheaderlen is at least
sizeof(struct ipv6hdr) = 40 > sizeof(struct frag_hdr) = 8, so the
second condition can never be true.
For mtu - fragheaderlen in [1,7], (x & ~7) == 0, so
maxfraglen = ((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 = datalen + fragheaderlen escape the MTU constraint.
With MSG_MORE on an egress device without NETIF_F_SG, alloclen = 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 = fragheaderlen + 1 triggers:
skbuff: skb_over_panic: len:61280 put:61280 ...
kernel BUG at net/core/skbuff.c
skb_put __ip6_append_data ip6_append_data rawv6_sendmsg
The same re-lowering exists with a transport-mode xfrm bundle: ESP/AH
bytes counted in rt->dst.header_len are not part of fragheaderlen
(ESP lacks XFRM_TYPE_NON_FRAGMENT), and ip6_append_data_mtu()
subtracts dst.header_len from mtu for the first fragment, so after
the entry guard passes, the recomputed maxfraglen can be pushed below
fragheaderlen the same way.
Remove the dead expression and, when the datagram actually has to be
fragmented, require room for at least one 8-octet payload block after
the fragment header, matching the minimum ip6_fragment() already
enforces once skb->len > mtu. The check is placed after the dontfrag
and maxnonfragsize handling so that unfragmented datagrams that fit
within mtu, and the dontfrag PMTU notification path, keep their
current behaviour.
reserved_headerlen accounts for the first fragment's xfrm header
space regardless of whether this append is the first one on the cork:
a subsequent append that pushes an initially unfragmented datagram
past mtu still fragments, and ip6_append_data_mtu() subtracts
dst.header_len from mtu for the first fragment. The check runs
before any zerocopy uarg is allocated, so the emsgsize path needs no
cleanup.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Link: https://lore.kernel.org/netdev/willemdebruijn.kernel.22a3131380a8c@gmail.com/
Signed-off-by: bo cao <treebacker@foxmail.com>
---
Changes in v2: move the check into ip6_append_data_mtu() (review of v1).
Changes in v3: collapse the fix into a single entry check, leaving
ip6_append_data_mtu() unchanged (review of v2).
Changes in v4: gate the check on fragmentation actually being needed
and place it after the dontfrag / maxnonfragsize handling, so valid
unfragmented datagrams and the dontfrag PMTU notification path are not
affected; include dst.header_len in reserved_headerlen regardless of
!skb, so a subsequent corked append that fragments still accounts for
the first fragment's xfrm header space (review of v3).
---
net/ipv6/ip6_output.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 25fe0ba98b1a..4353b154f216 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1477,7 +1477,7 @@ static int __ip6_append_data(struct sock *sk,
bool paged, hold_tskey = false, extra_uref = false;
struct ipv6_txoptions *opt = v6_cork->opt;
int csummode = CHECKSUM_NONE;
- unsigned int maxnonfragsize, headersize;
+ unsigned int maxnonfragsize, headersize, reserved_headerlen;
unsigned int wmem_alloc_delta = 0;
skb = skb_peek_tail(queue);
@@ -1499,8 +1499,7 @@ static int __ip6_append_data(struct sock *sk,
(opt ? opt->opt_flen + opt->opt_nflen : 0) +
rt->rt6i_nfheader_len;
- if (mtu <= fragheaderlen ||
- ((mtu - fragheaderlen) & ~7) + fragheaderlen <= sizeof(struct frag_hdr))
+ if (mtu <= fragheaderlen)
goto emsgsize;
maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen -
@@ -1533,6 +1532,29 @@ static int __ip6_append_data(struct sock *sk,
return -EMSGSIZE;
}
+ /*
+ * If the datagram has to be fragmented, each non-final fragment
+ * must leave room for at least 8 bytes of payload after the
+ * fragment header, matching the minimum ip6_fragment() enforces
+ * once skb->len > mtu. This rejects the MTUs that make maxfraglen
+ * underflow below fragheaderlen and defeat the datalen clamp,
+ * which leads to skb_over_panic() from skb_put().
+ *
+ * reserved_headerlen accounts for the first fragment's xfrm header
+ * space (with a transport-mode xfrm bundle, ESP/AH bytes counted
+ * in dst.header_len are not part of fragheaderlen), regardless of
+ * whether this append is the first one on the cork: a subsequent
+ * append that pushes an initially unfragmented datagram past mtu
+ * still fragments, and ip6_append_data_mtu() subtracts
+ * dst.header_len from mtu for the first fragment.
+ */
+ reserved_headerlen = fragheaderlen;
+ if (!(rt->dst.flags & DST_XFRM_TUNNEL))
+ reserved_headerlen += rt->dst.header_len;
+ if (reserved_headerlen + cork->length + length > mtu &&
+ mtu < reserved_headerlen + sizeof(struct frag_hdr) + 8)
+ goto emsgsize;
+
/* CHECKSUM_PARTIAL only with no extension headers and when
* we are not going to fragment
*/
--
2.39.5 (Apple Git-154)
next reply other threads:[~2026-11-02 1:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 1:57 bo cao [this message]
2026-11-02 2:03 ` netdev-bot+sinfo
2026-11-02 2:18 ` bo cao
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=tencent_0A4B784EEB3D358B09B43AA2B2F13AE44505@qq.com \
--to=treebacker@foxmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.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
all inboxes | Powered by JetHome®