Re: [syzbot] [net?] WARNING in udp_v6_send_skb

["Alice Mikityanska" <alice.kernel@fastmail.im>]

On Thu, Jul 30, 2026, at 17:10, Willem de Bruijn wrote:
> Willem de Bruijn wrote:
>> syzbot wrote:
>> > Hello,
>> > 
>> > syzbot found the following issue on:
>> > 
>> > HEAD commit:    04026c998c24 net/rds: use krealloc_array() for iovector gr..
>> > git tree:       net-next
>> > console output: https://syzkaller.appspot.com/x/log.txt?x=163a6499580000
>> > kernel config:  https://syzkaller.appspot.com/x/.config?x=f9f592a4e0cc86da
>> > dashboard link: https://syzkaller.appspot.com/bug?extid=ce13c07d96d04716eaa2
>> > compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
>> > 
>> > Unfortunately, I don't have any reproducer for this issue yet.
>> > 
>> > Downloadable assets:
>> > disk image: https://storage.googleapis.com/syzbot-assets/4f82b6352d02/disk-04026c99.raw.xz
>> > vmlinux: https://storage.googleapis.com/syzbot-assets/9b29e52c71b2/vmlinux-04026c99.xz
>> > kernel image: https://storage.googleapis.com/syzbot-assets/0b1e84e828d6/bzImage-04026c99.xz
>> > 
>> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> > Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com
>> > 
>> > ------------[ cut here ]------------
>> > len >= 65536u
>> > WARNING: ./include/linux/udp.h:49 at udp_set_len_short include/linux/udp.h:49 [inline], CPU#0: syz.4.4430/24120
>> > WARNING: ./include/linux/udp.h:49 at udp_v6_send_skb+0xd3b/0x13a0 net/ipv6/udp.c:1375, CPU#0: syz.4.4430/24120
>> > Modules linked in:
>> > CPU: 0 UID: 0 PID: 24120 Comm: syz.4.4430 Not tainted syzkaller #0 PREEMPT(full) 
>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/16/2026
>> > RIP: 0010:udp_set_len_short include/linux/udp.h:49 [inline]
>> > RIP: 0010:udp_v6_send_skb+0xd3b/0x13a0 net/ipv6/udp.c:1375
>> > Code: 42 0f b6 04 38 84 c0 0f 85 37 06 00 00 41 0f b7 1e e9 60 f3 ff ff e8 04 c3 43 f7 90 0f 0b 90 e9 02 f4 ff ff e8 f6 c2 43 f7 90 <0f> 0b 90 e9 e9 f4 ff ff e8 e8 c2 43 f7 90 0f 0b 90 e9 94 f5 ff ff
>> > RSP: 0018:ffffc9000e0a74c8 EFLAGS: 00010287
>> > RAX: ffffffff8a833e8a RBX: ffff8880355e4a00 RCX: 0000000000080000
>> > RDX: ffffc900100ca000 RSI: 00000000000049e3 RDI: 00000000000049e4
>> > RBP: 000000000000244c R08: ffff888049ed5d00 R09: 0000000000000003
>> > R10: 000000000000000b R11: 0000000000000002 R12: dffffc0000000000
>> > R13: ffff888027cb0c80 R14: 0000000000010000 R15: ffff8880355e4a02
>> > FS:  00007f2d4a07b6c0(0000) GS:ffff888124f54000(0000) knlGS:0000000000000000
>> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > CR2: 0000200000010000 CR3: 0000000029d28000 CR4: 00000000003526f0
>> > Call Trace:
>> >  <TASK>
>> >  udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1451
>> >  udpv6_sendmsg+0xfa0/0x2610 net/ipv6/udp.c:1740
>> >  sock_sendmsg_nosec+0x90/0x180 net/socket.c:775
>> >  __sock_sendmsg net/socket.c:790 [inline]
>> >  ____sys_sendmsg+0x54e/0x850 net/socket.c:2684
>> >  ___sys_sendmsg+0x2a5/0x360 net/socket.c:2738
>> >  __sys_sendmmsg+0x273/0x4d0 net/socket.c:2827
>> >  __do_sys_sendmmsg net/socket.c:2854 [inline]
>> >  __se_sys_sendmmsg net/socket.c:2851 [inline]
>> >  __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2851
>> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>> >  do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
>> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> > RIP: 0033:0x7f2d4919de99
>> 
>> Interesting trigger of the recently added DEBUG_NET_WARN_ON_ONCE in
>> udp_set_len_short called in udp_v6_send_skb.
>> 
>> No reproducer yet, so probably not very actionable at this point.

I got an [AI-generated] reproducer, please expect a fix early next week.

>> A mostly straightforward looking ipv6 udp sendmsg path.
>
> Actually, this may just be a valid UDP_SEGMENT skb with max payload:
>
>     IP6_MAX_MTU (0xFFFF + sizeof(struct ipv6hdr))
>
> This is what __ip6_append_data checks on egress
>
>     mtu = cork->gso_size ? IP6_MAX_MTU : cork->fragsize;
>
> Not sure whether UDP_SEGMENT can legitimately build even larger
> BIG-TCP variants of UDP_SEGMENT skbs at this point too today.

My reproducer sends a regular UDP datagram, no UDP_SEGMENT:

1. Set device MTU > IP6_MAX_MTU. cork->base.fragsize will be set to MTU
   in ip6_setup_cork.
2. setsockopt IPV6_MTU_DISCOVER to IPV6_PMTUDISC_DO. It lets
   maxnonfragsize be set to device MTU (cork->fragsize) in
   __ip6_append_data, rather than to IP6_MAX_MTU=65575.
3. Send 65528 bytes of payload + 8 bytes of UDP header + 40 bytes of
   IPv6 header. Device MTU allows it (one byte bigger than IP6_MAX_MTU),
   and UDP length is 65536, triggering the WARN.

It shouldn't be possible with UDP_SEGMENT, because mtu (and then
maxnonfragsize) is set to IP6_MAX_MTU in __ip6_append_data if
cork->gso_size is set.