All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: Ren Wei <weir@nebusec.ai>
Cc: netdev@vger.kernel.org, dsahern@kernel.org, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, vega@nebusec.ai, edragain@163.com
Subject: Re: [PATCH net 1/1] ipv4: reject RTAX_MTU values below IPV4_MIN_MTU
Date: Wed, 12 Aug 2026 15:08:27 +0300	[thread overview]
Message-ID: <20260812120827.GA3410841@shredder> (raw)
In-Reply-To: <ccd14fb1411b8b9c466065582e43f6a6c0743842.1786094799.git.edragain@163.com>

On Sat, Aug 08, 2026 at 04:01:15PM +0800, Ren Wei wrote:
> From: Yong Wang <edragain@163.com>
> 
> ip_metrics_convert() caps RTAX_MTU at the IPv4 maximum, but it still
> accepts undersized non-zero values from userspace.
> 
> A route installed with "mtu lock 20" can later reach the IPv4
> forwarding fragmentation path. With a normal 20-byte IPv4 header,
> ip_do_fragment() reduces the payload MTU to zero. ip_frag_next() then
> keeps producing zero-length payload fragments, so the fragmentation
> state never makes forward progress and the kernel loops until the
> softlockup detector fires.
> 
> Reject non-zero RTAX_MTU values smaller than IPV4_MIN_MTU while keeping
> the existing "0 means use default MTU" behavior intact.
> 
> This fixes the bug at the route metric input point and avoids adding
> redundant checks in the fragmentation path.

Sashiko is correct that this is also reproducible without setting an MTU
lock. See [1].

Better to fix it in ip_do_fragment(), in a similar fashion to IPv6.
Something like [2].

Sashiko review:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/ccd14fb1411b8b9c466065582e43f6a6c0743842.1786094799.git.edragain%40163.com

And please note:

"Patch authors are expected to proactively look into the AI-generated
reviews and handle such feedback as any other kind of review: either
debate it or address it. In both cases a reply on the mailing list is
expected."

https://docs.kernel.org/next/process/maintainer-netdev.html#review-timelines

[1]
#!/bin/bash

sysctl -w net.ipv4.ip_forward=1

ip link add name dummy1 up mtu 20 type dummy
ip address add 192.0.2.1/24 dev dummy1

ip link add veth0 type veth peer name veth1
ip addr add 198.51.100.1/24 dev veth0
ip link set veth0 up

ip netns add ns1
ip link set veth1 netns ns1
ip -n ns1 address add 198.51.100.2/24 dev veth1
ip -n ns1 link set veth1 up
ip -n ns1 route add default via 198.51.100.1
ip netns exec ns1 ping -M dont -s 1000 -c 1 192.0.2.2

[2]
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e6dd1e5b8c32..e6bbae103e4f 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -790,6 +790,12 @@ int ip_do_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
 	 */
 
 	hlen = iph->ihl * 4;
+
+	if (mtu < hlen + 8) {
+		err = -EMSGSIZE;
+		goto fail;
+	}
+
 	mtu = mtu - hlen;	/* Size of data space */
 	IPCB(skb)->flags |= IPSKB_FRAG_COMPLETE;
 	ll_rs = LL_RESERVED_SPACE(rt->dst.dev);

      reply	other threads:[~2026-08-12 12:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08  8:01 [PATCH net 0/1] ipv4: fix a non-progressing fragmentation loop from undersized RTAX_MTU Ren Wei
2026-08-08  8:01 ` [PATCH net 1/1] ipv4: reject RTAX_MTU values below IPV4_MIN_MTU Ren Wei
2026-08-12 12:08   ` Ido Schimmel [this message]

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=20260812120827.GA3410841@shredder \
    --to=idosch@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edragain@163.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vega@nebusec.ai \
    --cc=weir@nebusec.ai \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.