[PATCH net 1/1] ipv4: reject RTAX_MTU values below IPV4_MIN_MTU

From: Yong Wang <[email protected]>

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.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: [email protected]
Reported-by: Vega <[email protected]>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Yong Wang <[email protected]>
Signed-off-by: Ren Wei <[email protected]>
---
 net/ipv4/metrics.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/ipv4/metrics.c b/net/ipv4/metrics.c
index ad40762a8b38..10575c6af908 100644
--- a/net/ipv4/metrics.c
+++ b/net/ipv4/metrics.c
@@ -44,6 +44,12 @@ static int ip_metrics_convert(struct nlattr *fc_mx,
 			}
 			val = nla_get_u32(nla);
 		}
+		if (type == RTAX_MTU && val && val < IPV4_MIN_MTU) {
+			NL_SET_ERR_MSG_ATTR_FMT(extack, nla,
+						"Invalid mtu, must be 0 or >= %u",
+						IPV4_MIN_MTU);
+			return -EINVAL;
+		}
 		if (type == RTAX_ADVMSS && val > 65535 - 40)
 			val = 65535 - 40;
 		if (type == RTAX_MTU && val > 65535 - 15)
-- 
2.53.0