[PATCH net] net: ipv4: fix tnl_update_pmtu negative MTU advertisement

[PATCH net] net: ipv4: fix tnl_update_pmtu negative MTU advertisement

[zhangmh25]

From: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>

tnl_update_pmtu() derives the tunnel MTU for DF packets by subtracting
the outer IP header and the tunnel header length from the MTU of the
underlay route.  When that route has a very low MTU (for example one
installed with "ip route ... mtu 15" on an ipip tunnel, where the
outer header alone is 20 bytes), the result can drop below
IPV4_MIN_MTU or even become negative.

The IPv6 branch of the same function emits ICMPV6_PKT_TOOBIG only
when mtu >= IPV6_MIN_MTU, but the IPv4 branch passes the unclamped
value to icmp_ndo_send().  An effective MTU of -5 produces a bogus
Next-Hop MTU value of 65531 in the generated ICMP_FRAG_NEEDED instead
of providing usable PMTU feedback.  Values below IPV4_MIN_MTU are not
valid to advertise (RFC 1191), and ip_tunnel_bind_dev() already
clamps the device MTU to IPV4_MIN_MTU.

Mirror the IPv6 guard and only send the error when mtu >=
IPV4_MIN_MTU.  The packet is still rejected with -E2BIG.

IPIP previously rejected packets when the effective tunnel MTU was
below 68.  Commit fd58156e456d ("IPIP: Use ip-tunneling code.")
switched IPIP to the shared transmit path, which lacked this check.

Tested in a network namespace with an ipip tunnel: with a tunnel route
of "mtu 15" the kernel generates an ICMP_FRAG_NEEDED advertising a
next-hop MTU of 65531, and with a route of "mtu 88" it advertises the
correct MTU of 68.  After this change no ICMP error is generated for
the "mtu 15" case while the packet is still rejected with -E2BIG, and
the "mtu 88" advertisement is unchanged.

Found during a systematic audit of PMTU handling in tunnel
encapsulation paths.

Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Reported-by: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
Reported-by: Jianjun Chen <jianjun@tsinghua.edu.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
---
 net/ipv4/ip_tunnel.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index e6bcf0141..3200c33d3 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -536,7 +536,9 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
 		if (!skb_is_gso(skb) &&
 		    (inner_iph->frag_off & htons(IP_DF)) &&
 		    mtu < pkt_size) {
-			icmp_ndo_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
+			if (mtu >= IPV4_MIN_MTU)
+				icmp_ndo_send(skb, ICMP_DEST_UNREACH,
+					      ICMP_FRAG_NEEDED, htonl(mtu));
 			return -E2BIG;
 		}
 	}
-- 
2.34.1

Re: [PATCH net] net: ipv4: fix tnl_update_pmtu negative MTU advertisement

[Ido Schimmel]

On Mon, Nov 02, 2026 at 11:54:44PM +0800, zhangmh25@mails.tsinghua.edu.cn wrote:
> From: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
> 
> tnl_update_pmtu() derives the tunnel MTU for DF packets by subtracting
> the outer IP header and the tunnel header length from the MTU of the
> underlay route.  When that route has a very low MTU (for example one
> installed with "ip route ... mtu 15" on an ipip tunnel, where the
> outer header alone is 20 bytes), the result can drop below
> IPV4_MIN_MTU or even become negative.
> 
> The IPv6 branch of the same function emits ICMPV6_PKT_TOOBIG only
> when mtu >= IPV6_MIN_MTU, but the IPv4 branch passes the unclamped
> value to icmp_ndo_send().  An effective MTU of -5 produces a bogus
> Next-Hop MTU value of 65531 in the generated ICMP_FRAG_NEEDED instead
> of providing usable PMTU feedback.  Values below IPV4_MIN_MTU are not
> valid to advertise (RFC 1191), and ip_tunnel_bind_dev() already
> clamps the device MTU to IPV4_MIN_MTU.
> 
> Mirror the IPv6 guard and only send the error when mtu >=
> IPV4_MIN_MTU.  The packet is still rejected with -E2BIG.
> 
> IPIP previously rejected packets when the effective tunnel MTU was
> below 68.  Commit fd58156e456d ("IPIP: Use ip-tunneling code.")
> switched IPIP to the shared transmit path, which lacked this check.
> 
> Tested in a network namespace with an ipip tunnel: with a tunnel route
> of "mtu 15" the kernel generates an ICMP_FRAG_NEEDED advertising a
> next-hop MTU of 65531, and with a route of "mtu 88" it advertises the
> correct MTU of 68.  After this change no ICMP error is generated for
> the "mtu 15" case while the packet is still rejected with -E2BIG, and
> the "mtu 88" advertisement is unchanged.
> 
> Found during a systematic audit of PMTU handling in tunnel
> encapsulation paths.
> 
> Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
> Reported-by: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
> Reported-by: Jianjun Chen <jianjun@tsinghua.edu.cn>
> Cc: stable@vger.kernel.org
> Signed-off-by: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
> ---
>  net/ipv4/ip_tunnel.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Why is this interesting?

An admin setting such a low MTU turns the box into a blackhole. Why does
it matter if a bogus MTU is advertised in the ICMP error? The overlay
source will see that it's bigger than the current MTU and won't update
its PMTU. At best this seems like net-next material, but even then it
seems like unnecessary churn.