[PATCH net v5 0/4] Fix UDP length overflow in edge cases

[PATCH net v5 0/4] Fix UDP length overflow in edge cases

[Alice Mikityanska]

From: Alice Mikityanska <alice@isovalent.com>

These are fixes for rare edge cases of 16-bit UDP length field overflow
that might happen on netdevs with MTU >= 64k.

Exposed by the new WARN added to udp_set_len_short, reported by syzbot.

v5 changes: Added docstrings to the selftest, used defer.

v4: https://lore.kernel.org/netdev/20260825200215.90326-1-alice.kernel@fastmail.im/

v4 changes: Fixed IPv6 commit message; deduplicated code in the selftest
and fixed pylint and ruff warnings.

v3: https://lore.kernel.org/netdev/20260822115717.1161782-1-alice.kernel@fastmail.im/

v3 changes: Split IPv4, IPv6 and selftest; limited the clamp to UDP
sockets to support UDP jumbograms over raw sockets; added a selftest for
raw sockets; added the kernel config check to the selftest.

v2: https://lore.kernel.org/netdev/20260813120351.2807829-1-alice.kernel@fastmail.im/

v2 changes: Restored the MTU clamp in ip6_dst_mtu_maybe_forward.

v1: https://lore.kernel.org/netdev/20260805205957.1652619-1-alice.kernel@fastmail.im/

Alice Mikityanska (4):
  net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
  net: ipv6: Fix UDP length overflow with PMTU discover and big MTU
  selftests: net: Test UDP length overflow with PMTU discover and big
    MTU
  net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward

 include/net/ip6_route.h                      |   2 +
 net/ipv4/ip_output.c                         |   1 +
 net/ipv6/ip6_output.c                        |   2 +
 tools/testing/selftests/net/Makefile         |   1 +
 tools/testing/selftests/net/cork_fragsize.py | 187 +++++++++++++++++++
 5 files changed, 193 insertions(+)
 create mode 100755 tools/testing/selftests/net/cork_fragsize.py

-- 
2.55.0

[PATCH net v5 1/4] net: ipv4: Fix UDP length overflow with PMTU discover and big MTU

[Alice Mikityanska]

From: Alice Mikityanska <alice@isovalent.com>

This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a
possible overflow of UDP length that triggers a WARN in
udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to
IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an
unusually large MTU.

Steps to reproduce:

1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will
   be set to that MTU in ip_setup_cork.
2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be
   set to device MTU (cork->fragsize) in __ip_append_data, rather than
   to IP_MAX_MTU.
3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of
   IPv4 header). Device MTU allows it (it's only one byte bigger than
   IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that).
4. The UDP length in the built packet is 65536, which overflows the
   16-bit length field and triggers the WARN in udp_set_len_short.

Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward
always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.

The Fixes tag points at the first commit where I could reproduce the
overflow with IPv4 and IP_PMTUDISC_PROBE.

Fixes: daba287b299e ("ipv4: fix DO and PROBE pmtu mode regarding local fragmentation with UFO/CORK")
Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Assisted-by: Claude:claude-sonnet-4.6
Reviewed-by: Willem de Bruijn <willemb@google.com>
---
 net/ipv4/ip_output.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 74e095b6b7ca..a24cc8ee11d3 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1303,6 +1303,7 @@ static int ip_setup_cork(struct sock *sk, struct inet_cork *cork,
 
 	cork->fragsize = ip_sk_use_pmtu(sk) ?
 			 dst4_mtu(&rt->dst) : READ_ONCE(rt->dst.dev->mtu);
+	cork->fragsize = min(cork->fragsize, IP_MAX_MTU);
 
 	if (!inetdev_valid_mtu(cork->fragsize))
 		return -ENETUNREACH;
-- 
2.55.0

[PATCH net v5 2/4] net: ipv6: Fix UDP length overflow with PMTU discover and big MTU

[Alice Mikityanska]

From: Alice Mikityanska <alice@isovalent.com>

This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to
avoid a possible overflow of UDP length that triggers a WARN in
udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to
IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over
a netdev with an unusually large MTU.

Steps to reproduce (included in the new selftest):

1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be
   set to that MTU in ip6_setup_cork.
2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It
   lets maxnonfragsize be set to device MTU (cork->fragsize) in
   __ip6_append_data, rather than to IP6_MAX_MTU.
3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of
   IPv6 header). Device MTU allows it (it's only one byte bigger than
   IP6_MAX_MTU, and the device MTU is bigger than that).
4. The UDP length in the built packet is 65536, which overflows the
   16-bit length field and triggers the WARN in udp_set_len_short.

To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit
the change to UDP sockets only.

The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to
predate git history (verified reproduction on 2.6.21), was fixed later,
and then reappeared in commit 427faee167bc ("net: ipv6: introduce
ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The
overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in
commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE").

Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward")
Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Assisted-by: Codex:gpt-5.6-sol
Reviewed-by: Willem de Bruijn <willemb@google.com>
---
 net/ipv6/ip6_output.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 8fc4766c8da9..550965058991 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1432,6 +1432,8 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork,
 	if (frag_size && frag_size < mtu)
 		mtu = frag_size;
 
+	if (sk_is_udp(sk))
+		mtu = min(mtu, IP6_MAX_MTU);
 	cork->base.fragsize = mtu;
 	cork->base.gso_size = ipc6->gso_size;
 	cork->base.tx_flags = 0;
-- 
2.55.0

[PATCH net v5 3/4] selftests: net: Test UDP length overflow with PMTU discover and big MTU

[Alice Mikityanska]

From: Alice Mikityanska <alice@isovalent.com>

Two previous commits fixed overflow of UDP length when setsockopt
IP(V6)_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IP(V6)_PMTUDISC_PROBE,
and a large packet is sent over a netdev with an unusually large MTU.

This commit adds the selftests that replicate the described steps to
reproduce for IPv6 and IPv4, and also one more test that ensures that
sending UDP jumbograms over a raw socket is still possible after the
fix.

Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
---
 tools/testing/selftests/net/Makefile         |   1 +
 tools/testing/selftests/net/cork_fragsize.py | 187 +++++++++++++++++++
 2 files changed, 188 insertions(+)
 create mode 100755 tools/testing/selftests/net/cork_fragsize.py

diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 517c09d60bef..3ee3378f8b26 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -25,6 +25,7 @@ TEST_PROGS := \
 	cmsg_so_mark.sh \
 	cmsg_so_priority.sh \
 	cmsg_time.sh \
+	cork_fragsize.py \
 	double_udp_encap.sh \
 	drop_monitor_tests.sh \
 	ecmp_rehash.sh \
diff --git a/tools/testing/selftests/net/cork_fragsize.py b/tools/testing/selftests/net/cork_fragsize.py
new file mode 100755
index 000000000000..7afd643d07ec
--- /dev/null
+++ b/tools/testing/selftests/net/cork_fragsize.py
@@ -0,0 +1,187 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+
+'''Test possible UDP length overflow in udp_send_skb/udp_v6_send_skb.'''
+
+import errno
+import gzip
+import os
+import socket
+import struct
+import subprocess
+from contextlib import contextmanager
+
+from lib.py import (
+    KsftNamedVariant,
+    KsftSkipEx,
+    NetNS,
+    NetNSEnter,
+    defer,
+    ip,
+    ksft_eq,
+    ksft_exit,
+    ksft_pr,
+    ksft_raises,
+    ksft_run,
+    ksft_true,
+    ksft_variants,
+)
+
+IP_MTU_DISCOVER = 10
+IP_PMTUDISC_PROBE = 3
+IPV6_MTU_DISCOVER = 23
+IPV6_PMTUDISC_DO = 2
+IPV6_PMTUDISC_PROBE = 3
+IPV6_TLV_JUMBO = 194
+
+
+def check_kernel_config(option: str) -> bool | None:
+    '''
+    Check whether the option is enabled in the config of the running kernel.
+    Returns None if the config is not found; otherwise returns True/False
+    depending on the option value in the config.
+    '''
+
+    for filename, method in [
+        ('/proc/config.gz', gzip.open),
+        (f'/boot/config-{os.uname().release}', open),
+    ]:
+        try:
+            with method(filename, 'rt') as config:
+                for line in config:
+                    if line.rstrip() == f'{option}=y':
+                        return True
+                return False
+        except OSError:
+            continue
+        return None
+
+
+def assert_debug_kernel() -> None:
+    '''
+    Skip the test if CONFIG_DEBUG_NET is not set in the kernel config.
+    '''
+
+    res = check_kernel_config('CONFIG_DEBUG_NET')
+    if res is None:
+        ksft_pr("WARN: Can't read kernel config; assuming debug kernel, and running the test")
+    elif not res:
+        raise KsftSkipEx('CONFIG_DEBUG_NET is not set')
+
+
+def check_dmesg_clean(func: str) -> bool:
+    '''
+    Check if the given function produced a WARN in dmesg.
+    '''
+
+    with subprocess.Popen(['dmesg'], stdout=subprocess.PIPE) as dmesg:
+        res = subprocess.run(['grep', '-q', f'WARNING:.*{func}'], stdin=dmesg.stdout, check=False)
+    return res.returncode != 0 and dmesg.returncode == 0
+
+
+@contextmanager
+def dummy_netdev(ns: NetNS, mtu: int, ipv6: bool) -> None:
+    '''
+    Create a dummy netdev inside the given namespace, and tune it for the test.
+    '''
+
+    ip('link add dummy type dummy', ns=ns)
+    with defer(ip, 'link del dummy', ns=ns):
+        ip(f'link set dummy mtu {mtu}', ns=ns)
+        ip('link set dummy up', ns=ns)
+        flag = '-6' if ipv6 else ''
+        nodad = 'nodad' if ipv6 else ''
+        local = 'fd00::1/64' if ipv6 else '10.0.0.1/24'
+        remote = 'fd00::2' if ipv6 else '10.0.0.2'
+        ip(f'{flag} addr add {local} dev dummy {nodad}', ns=ns)
+        ip(f'{flag} neigh add {remote} lladdr 02:00:00:00:00:02 dev dummy nud permanent', ns=ns)
+        yield
+
+
+@ksft_variants([
+    KsftNamedVariant(
+        'ipv6',
+        True,
+        socket.AF_INET6,
+        (socket.IPPROTO_IPV6, IPV6_MTU_DISCOVER, IPV6_PMTUDISC_DO),
+        'fd00::2',
+        'udp_v6_send_skb',
+    ),
+    KsftNamedVariant(
+        'ipv4',
+        False,
+        socket.AF_INET,
+        (socket.IPPROTO_IP, IP_MTU_DISCOVER, IP_PMTUDISC_PROBE),
+        '10.0.0.2',
+        'udp_send_skb',
+    ),
+])
+def test_udp(
+    ipv6: bool,
+    af: socket.AddressFamily,
+    sockopts: tuple[int, int, int],
+    destip: str,
+    func: str
+) -> None:
+    '''
+    Test that sending an oversized UDP packet over a UDP socket doesn't overflow
+    the 16-bit length field in the UDP header, which could happen on older
+    kernels in udp_send_skb/udp_v6_send_skb.
+
+    IPv4: The packet will be dropped with EMSGSIZE, but the overflow could
+    happen before it happens. The only way to test this is to check dmesg on
+    CONFIG_DEBUG_NET=y kernels that have udp_set_len_short with the warning.
+
+    IPv6: The packet will be dropped with EMSGSIZE on fixed kernels, and will be
+    sent corrupted on older kernels. Test both: sendto must return EMSGSIZE, and
+    dmesg must be clean of warnings on CONFIG_DEBUG_NET=y kernels.
+    '''
+
+    if not ipv6:
+        assert_debug_kernel()
+
+    with (
+        NetNS() as ns,
+        dummy_netdev(ns, 65556 + 20 * ipv6, ipv6),
+        NetNSEnter(ns),
+        socket.socket(af, socket.SOCK_DGRAM) as fd,
+    ):
+        fd.setsockopt(*sockopts)
+        with ksft_raises(OSError) as e:
+            fd.sendto(b' ' * 65528, (destip, 1234))
+        # IPv6: EMSGSIZE happens on kernels with the fix.
+        # IPv4: EMSGSIZE happens on both fixed and unfixed kernels, after the
+        #       WARN is printed - ignore it and rely on the dmesg check.
+        if e.exception is not None:
+            ksft_eq(e.exception.errno, errno.EMSGSIZE)
+
+    ksft_true(check_dmesg_clean(func), 'WARNING detected in dmesg')
+
+
+def test_ipv6_jumbo() -> None:
+    '''
+    Test that sending UDP jumbograms over a raw IPv6 socket works, despite
+    having the fix for oversized UDP packets. sendto must not raise an OSError
+    exception (when raised, the test fails automatically).
+    '''
+
+    with (
+        NetNS() as ns,
+        dummy_netdev(ns, 65584, True),
+        NetNSEnter(ns),
+        socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_UDP) as fd,
+    ):
+        hopopts = struct.pack('!BBBBI', 0, 0, IPV6_TLV_JUMBO, 4, 65544)
+        fd.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_HOPOPTS, hopopts)
+        fd.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_CHECKSUM, 6)
+        fd.setsockopt(socket.IPPROTO_IPV6, IPV6_MTU_DISCOVER, IPV6_PMTUDISC_PROBE)
+        udp = struct.pack('!HHHH', 1234, 1234, 0, 0) + b' ' * 65528
+        fd.sendto(udp, ('fd00::2', 0))
+
+
+if __name__ == "__main__":
+    ksft_run([
+        test_udp,
+        test_ipv6_jumbo,
+    ])
+    ksft_exit()
-- 
2.55.0

[PATCH net v5 4/4] net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward

[Alice Mikityanska]

From: Alice Mikityanska <alice@isovalent.com>

Commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward")
dropped the IP6_MAX_MTU clamp that used to be present in ip6_mtu(). A
similar IPv4 commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and
ip_dst_mtu_maybe_forward") preserves the IP_MAX_MTU clamp.

Restore the upper bound in the IPv6 flow to avoid potential 16-bit
overflows in forwarding paths.

Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward")
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
---
 include/net/ip6_route.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index c69f1c871922..b9e8d2b759e9 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -384,6 +384,8 @@ static inline unsigned int ip6_dst_mtu_maybe_forward(const struct dst_entry *dst
 	rcu_read_unlock();
 
 out:
+	mtu = min_t(unsigned int, mtu, IP6_MAX_MTU);
+
 	return mtu - lwtunnel_headroom(dst->lwtstate, mtu);
 }
 
-- 
2.55.0

Re: [PATCH net v5 2/4] net: ipv6: Fix UDP length overflow with PMTU discover and big MTU

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 0 · Low: 1

- [Low] Claim that the commit message's "Steps to reproduce (included in
  the new selftest)" references a selftest that does not exist in this…

--

net: ipv6: Fix UDP length overflow with PMTU discover and big MTU

The change clamps cork->base.fragsize to IP6_MAX_MTU in ip6_setup_cork() for
UDP sockets, so a device MTU larger than IP6_MAX_MTU combined with
IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE can no longer produce a 16-bit UDP
length overflow. Raw IPv6 sockets are left alone so jumbograms keep working.

Link: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/

> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 8fc4766c8da90..5509650589915 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1432,6 +1432,8 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork,
>  	if (frag_size && frag_size < mtu)
>  		mtu = frag_size;
>  
> +	if (sk_is_udp(sk))
> +		mtu = min(mtu, IP6_MAX_MTU);
>  	cork->base.fragsize = mtu;
>  	cork->base.gso_size = ipc6->gso_size;
>  	cork->base.tx_flags = 0;

One note on the changelog rather than the code:

> Steps to reproduce (included in the new selftest):

[Severity: Low]
This turned out to be accurate, so no change is needed here; noting it only
because the reference is forward-looking within the series.

This commit only touches net/ipv6/ip6_output.c, so "the new selftest" is not
present in this commit itself.  The test is added by the later patch in the
same series, "selftests: net: Test UDP length overflow with PMTU discover and
big MTU", which creates tools/testing/selftests/net/cork_fragsize.py and adds
it to TEST_PROGS in tools/testing/selftests/net/Makefile:

  +	cork_fragsize.py \

The ipv6 variant of test_udp() there does set up a dummy netdev with an MTU
above IP6_MAX_MTU, sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_DO, sends 65528
bytes and expects EMSGSIZE, and test_ipv6_jumbo() covers the raw socket
jumbogram case mentioned in the last paragraph of the changelog.

Would it be worth saying "included in a selftest added later in this series"
so that anyone reading or backporting this commit alone knows where to look?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901195714.673548-1-alice.kernel%40fastmail.im

Re: [PATCH net v5 3/4] selftests: net: Test UDP length overflow with PMTU discover and big MTU

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 5 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 2 · Low: 3

- [Medium] tools/testing/selftests/net/cork_fragsize.py:38 uses a PEP 604
  union annotation (`def check_kernel_config(option: str) -> bool |…
- [Medium] check_dmesg_clean() (cork_fragsize.py:72-79) greps the whole
  retained kernel ring buffer for `WARNING:.*<func>` after the send,…
- [Low] The `return None` at cork_fragsize.py:57 (last statement of the
  `for` body in check_kernel_config()) is unreachable: the `try` block…
- [Low] assert_debug_kernel() (cork_fragsize.py:60-69) treats an
  unreadable kernel configuration as "assume debug kernel and run the…
- [Low] check_dmesg_clean()'s docstring (cork_fragsize.py:73-75) says
  "Check if the given function produced a WARN in dmesg", which is the…

--

selftests: net: Test UDP length overflow with PMTU discover and big MTU

This adds a new python selftest, cork_fragsize.py, that sends an oversized
UDP datagram over a dummy netdev with a very large MTU while
IP(V6)_MTU_DISCOVER is set, and checks both the sendto() errno and dmesg.
A third test verifies UDP jumbograms over a raw IPv6 socket still work.

A few questions about the new test below.

> diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> index 517c09d60bef7..3ee3378f8b26e 100644
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -25,6 +25,7 @@ TEST_PROGS := \
>  	cmsg_so_mark.sh \
>  	cmsg_so_priority.sh \
>  	cmsg_time.sh \
> +	cork_fragsize.py \
>  	double_udp_encap.sh \
>  	drop_monitor_tests.sh \
>  	ecmp_rehash.sh \
> diff --git a/tools/testing/selftests/net/cork_fragsize.py b/tools/testing/selftests/net/cork_fragsize.py
> new file mode 100755
> index 0000000000000..7afd643d07ec2
> --- /dev/null
> +++ b/tools/testing/selftests/net/cork_fragsize.py
> @@ -0,0 +1,187 @@
> +#!/usr/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0
> +
> +'''Test possible UDP length overflow in udp_send_skb/udp_v6_send_skb.'''
> +
> +import errno
> +import gzip
> +import os
> +import socket
> +import struct
> +import subprocess
> +from contextlib import contextmanager

[ ... ]

> +def check_kernel_config(option: str) -> bool | None:

[Severity: Medium]
Does this signature work on the minimum supported interpreter?
Documentation/process/changes.rst lists:

  Python                 3.9.x            python3 --version

The PEP 604 union syntax "bool | None" in a function annotation is
evaluated eagerly when the def statement executes, i.e. at module import,
and type.__or__ only exists from CPython 3.10. Without
"from __future__ import annotations" in the file, would importing this on a
3.9 host raise:

  TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

before ksft_run() is reached, so that the entry just added to TEST_PROGS
reports a hard error instead of running or skipping the two UDP tests?

Would typing.Optional[bool], or the future import, avoid this?  The other
new annotations in the file (tuple[int, int, int], -> None) are fine on 3.9.

> +    '''
> +    Check whether the option is enabled in the config of the running kernel.
> +    Returns None if the config is not found; otherwise returns True/False
> +    depending on the option value in the config.
> +    '''
> +
> +    for filename, method in [
> +        ('/proc/config.gz', gzip.open),
> +        (f'/boot/config-{os.uname().release}', open),
> +    ]:
> +        try:
> +            with method(filename, 'rt') as config:
> +                for line in config:
> +                    if line.rstrip() == f'{option}=y':
> +                        return True
> +                return False
> +        except OSError:
> +            continue
> +        return None

[Severity: Low]
Is this return None reachable?  It sits at the end of the for body, but the
try block always returns (True on match, False once the file is exhausted)
and the only other path is "except OSError: continue", which restarts the
loop.  The documented "Returns None if the config is not found" behaviour
comes from falling off the end of the loop after both candidates raise
OSError.

If the try/except were ever reworked so that the statement did execute, it
would also stop the /boot/config-$(uname -r) candidate from being tried.
Was this meant to be dedented out of the loop, or dropped?

> +
> +
> +def assert_debug_kernel() -> None:
> +    '''
> +    Skip the test if CONFIG_DEBUG_NET is not set in the kernel config.
> +    '''
> +
> +    res = check_kernel_config('CONFIG_DEBUG_NET')
> +    if res is None:
> +        ksft_pr("WARN: Can't read kernel config; assuming debug kernel, and running the test")
> +    elif not res:
> +        raise KsftSkipEx('CONFIG_DEBUG_NET is not set')

[Severity: Low]
Should an unreadable config be treated as satisfying the CONFIG_DEBUG_NET
precondition rather than as a skip?

On a kernel built without CONFIG_IKCONFIG_PROC and with no /boot/config-*
file, check_kernel_config() returns None and the test proceeds.  If
CONFIG_DEBUG_NET happens to be off, the warning the ipv4 variant depends on
does not exist at all:

  include/net/net_debug.h:
  #define DEBUG_NET_WARN_ON_ONCE(cond) BUILD_BUG_ON_INVALID(cond)

An unfixed kernel then emits nothing, sendto() still returns EMSGSIZE from
ip_fragment(), check_dmesg_clean() reports clean, and the ipv4 variant
passes with the overflow still present.  Would KsftSkipEx be a safer
default here?

> +
> +
> +def check_dmesg_clean(func: str) -> bool:
> +    '''
> +    Check if the given function produced a WARN in dmesg.
> +    '''

[Severity: Low]
Is this docstring inverted with respect to the return value?  grep exits 0
on a match, so "res.returncode != 0" means no warning was found, and True
means "clean", which matches the function name but not the comment.

A future caller following the docstring would invert the verdict of the
test.

> +
> +    with subprocess.Popen(['dmesg'], stdout=subprocess.PIPE) as dmesg:
> +        res = subprocess.run(['grep', '-q', f'WARNING:.*{func}'], stdin=dmesg.stdout, check=False)
> +    return res.returncode != 0 and dmesg.returncode == 0

[Severity: Medium]
Can this grep of the whole retained ring buffer misreport in both
directions?  There is no pre-test snapshot, message count, timestamp filter
or dmesg -C to bound the window.

False failure: any earlier "WARNING:" line in this boot whose text contains
udp_send_skb or udp_v6_send_skb, including a previous run of this same test
in the same boot, makes a correctly fixed kernel report:

  not ok ... WARNING detected in dmesg

False pass: the diagnostic being consumed fires once per boot per site,

  include/linux/udp.h:udp_set_len_short() {
      DEBUG_NET_WARN_ON_ONCE(len >= GRO_LEGACY_MAX_SIZE);
  }

so if that record has already scrolled out of a wrapped buffer, or was
already consumed, the oversized send leaves no visible record.  For the
ipv4 variant the errno cannot discriminate either, since __ip_append_data()
returns -EMSGSIZE on a fixed kernel and ip_fragment() returns -EMSGSIZE on
an unfixed one after the warning, which the test docstring notes.  So a
still-broken kernel can pass.

Other net selftests bound the window with before/after counts, for example
fib_nexthops.sh and openvswitch/openvswitch.sh.  Would recording a dmesg
boundary before the send, and grepping only what was added, be more
reliable here?

Separately, does the "and dmesg.returncode == 0" term conflate two
different failures?  If dmesg itself exits non-zero, for instance under
kernel.dmesg_restrict or in an unprivileged container, the helper returns
False and the caller prints "WARNING detected in dmesg" for a warning that
was never observed.  Would a distinct error or skip be clearer for that
case?

[ ... ]

> +    if not ipv6:
> +        assert_debug_kernel()
> +
> +    with (
> +        NetNS() as ns,
> +        dummy_netdev(ns, 65556 + 20 * ipv6, ipv6),
> +        NetNSEnter(ns),
> +        socket.socket(af, socket.SOCK_DGRAM) as fd,
> +    ):
> +        fd.setsockopt(*sockopts)
> +        with ksft_raises(OSError) as e:
> +            fd.sendto(b' ' * 65528, (destip, 1234))
> +        # IPv6: EMSGSIZE happens on kernels with the fix.
> +        # IPv4: EMSGSIZE happens on both fixed and unfixed kernels, after the
> +        #       WARN is printed - ignore it and rely on the dmesg check.
> +        if e.exception is not None:
> +            ksft_eq(e.exception.errno, errno.EMSGSIZE)
> +
> +    ksft_true(check_dmesg_clean(func), 'WARNING detected in dmesg')

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901195714.673548-1-alice.kernel%40fastmail.im

Re: [PATCH net v5 4/4] net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 0

- [Medium] Incomplete fix: the clamp value chosen (IP6_MAX_MTU = 0xFFFF +
  sizeof(struct ipv6hdr) = 65575, include/net/ip6_route.h:44) is 40…

--

net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward

This restores an IP6_MAX_MTU upper bound on the value returned by
ip6_dst_mtu_maybe_forward(), which was dropped when the helper was
introduced in commit 427faee167bc. The stated goal is to avoid 16-bit
overflows in forwarding paths, mirroring the IPv4 clamp added by commit
ac6627a28dbf.

> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index c69f1c8719223..b9e8d2b759e9b 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
> @@ -384,6 +384,8 @@ static inline unsigned int ip6_dst_mtu_maybe_forward(const struct dst_entry *dst
>  	rcu_read_unlock();
>  
>  out:
> +	mtu = min_t(unsigned int, mtu, IP6_MAX_MTU);
> +

[Severity: Medium]
Does this clamp actually bound the 16-bit store the changelog refers to?

IP6_MAX_MTU in this same header is:

include/net/ip6_route.h:
	#define IP6_MAX_MTU (0xFFFF + sizeof(struct ipv6hdr))

so the bound is 65575, which is 40 above U16_MAX.

The IPv4 precedent quoted in the commit message does not look analogous
here.  include/linux/ip.h has:

	/* IPv4 datagram length is stored into 16bit field (tot_len) */
	#define IP_MAX_MTU	0xFFFFU

That is exactly U16_MAX, so the IPv4 clamp does bound a u16 consumer, while
the IPv6 value chosen here does not.

The forwarding-path consumer that narrows to 16 bits is
flow_offload_fill_route() in net/netfilter/nf_flow_table_core.c:

	case NFPROTO_IPV6:
		flow_tuple->mtu = ip6_dst_mtu_maybe_forward(dst, true);

and the destination field in include/net/netfilter/nf_flow_table.h is:

	struct flow_offload_tuple {
		...
		u16				mtu;

Any returned value in [65536, 65575] truncates to 0..39 there.

Is the new deterministic output worse than the unclamped case for that
consumer?  After this change every egress device with an MTU at or above
65575 yields exactly 65575, which truncates to exactly 39.  Then in
nf_flow_offload_ipv6_forward() in net/netfilter/nf_flow_table_ip.c:

	mtu = flow->tuplehash[dir].tuple.mtu + ctx->offset;
	if (flow->tuplehash[!dir].tuple.tun_num)
		mtu -= sizeof(*ip6h);

	if (unlikely(nf_flow_exceeds_mtu(skb, mtu)))
		return 0;

With a truncated tuple.mtu of 39 and the peer direction carrying tun_num,
the unsigned int subtraction of sizeof(struct ipv6hdr) wraps to roughly
4294967295, and nf_flow_exceeds_mtu():

	static bool nf_flow_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)
	{
		if (skb->len <= mtu)
			return false;

then returns false for every packet size, so the fast-path MTU check no
longer fires.

Is a raw MTU above U16_MAX reachable in-tree?  The idev->cnf.mtu6 branch
takes dev->mtu, and vrf_setup() in drivers/net/vrf.c does:

	dev->min_mtu = IPV6_MIN_MTU;
	dev->max_mtu = IP6_MAX_MTU;
	dev->mtu = dev->max_mtu;

Devices that leave max_mtu unset (loopback, for instance) also accept
arbitrarily large values, since dev_validate_mtu() in net/core/dev.c only
enforces an upper bound when max_mtu is non-zero:

	if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {

Would clamping to U16_MAX, or fixing the narrowing at the flowtable
consumer, be closer to what the changelog describes?

One related note on the reasoning: the locked route metric path does not
appear to be a way to get above 65535, since ip_metrics_convert() in
net/ipv4/metrics.c clamps RTAX_MTU to 65520 and is the only writer for
user-supplied IPv6 route metrics.

>  	return mtu - lwtunnel_headroom(dst->lwtstate, mtu);
>  }
>

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901195714.673548-1-alice.kernel%40fastmail.im