From: Yong Wang 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: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:GPT-5.4 Signed-off-by: Yong Wang Signed-off-by: Ren Wei --- 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