CVE-2026-80793: ipv4: reject undersized MTUs in ip_do_fragment()
In the Linux kernel, the following vulnerability has been resolved:
ipv4: reject undersized MTUs in ipdofragment()
ipdofragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ipfragnext().
If the effective MTU is smaller than hlen + 8, ipfragnext() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ipdofragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires.
This is reproducible with a route installed using "mtu lock 20", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20.
Fix it in ipdofragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
IPv4 fragmentation must occur with an effective MTU smaller than the IPv4 header length plus 8 bytes. The issue is reproducible with a route configured with "mtu lock 20" or when forwarding traffic to a device with an MTU of 20.
What is the operational impact of a successful trigger?
The kernel repeatedly allocates and transmits header-only fragments without making progress in fragmentation state. This continues until the softlockup detector fires.
Are route MTU locks required for exploitation?
No. Although a route installed with "mtu lock 20" can reproduce the issue, it can also occur without a route MTU lock when forwarding a packet to a device whose MTU is 20.
How does the resolved behavior prevent the problem?
The fix rejects an MTU below the IPv4 header length plus 8 bytes and returns -EMSGSIZE. This prevents ip_frag_next() from receiving a payload MTU that rounds down to zero.