From: Sabrina Dubroca <sd@queasysnail.net>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
David Ahern <dsahern@kernel.org>,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH net-next v2 3/5] udp_tunnel: fix UaF in GRO accounting
Date: Tue, 25 Mar 2025 17:10:04 +0100 [thread overview]
Message-ID: <Z-LVXCFm9Dyf8seK@krikkit> (raw)
In-Reply-To: <70a8c5bdf58ed1937e2f3edbefb37c55cfe6ebc1.1742557254.git.pabeni@redhat.com>
2025-03-21, 12:52:54 +0100, Paolo Abeni wrote:
> Siyzkaller reported a race in UDP tunnel GRO accounting, leading to
> UaF:
>
> BUG: KASAN: slab-use-after-free in udp_tunnel_update_gro_lookup+0x23c/0x2c0 net/ipv4/udp_offload.c:65
> Read of size 8 at addr ffff88801235ebe8 by task syz.2.655/7921
>
> CPU: 1 UID: 0 PID: 7921 Comm: syz.2.655 Not tainted 6.14.0-rc6-syzkaller-01313-g23c9ff659140 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
> print_address_description mm/kasan/report.c:408 [inline]
> print_report+0x16e/0x5b0 mm/kasan/report.c:521
> kasan_report+0x143/0x180 mm/kasan/report.c:634
> udp_tunnel_update_gro_lookup+0x23c/0x2c0 net/ipv4/udp_offload.c:65
> sk_common_release+0x71/0x2e0 net/core/sock.c:3896
> inet_release+0x17d/0x200 net/ipv4/af_inet.c:435
> __sock_release net/socket.c:647 [inline]
> sock_release+0x82/0x150 net/socket.c:675
> sock_free drivers/net/wireguard/socket.c:339 [inline]
> wg_socket_reinit+0x215/0x380 drivers/net/wireguard/socket.c:435
> wg_stop+0x59f/0x600 drivers/net/wireguard/device.c:133
> __dev_close_many+0x3a6/0x700 net/core/dev.c:1717
> dev_close_many+0x24e/0x4c0 net/core/dev.c:1742
> unregister_netdevice_many_notify+0x629/0x24f0 net/core/dev.c:11923
> rtnl_delete_link net/core/rtnetlink.c:3512 [inline]
> rtnl_dellink+0x526/0x8c0 net/core/rtnetlink.c:3554
> rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6945
> netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2534
> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339
> netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883
> sock_sendmsg_nosec net/socket.c:709 [inline]
> __sock_sendmsg+0x221/0x270 net/socket.c:724
> ____sys_sendmsg+0x53a/0x860 net/socket.c:2564
> ___sys_sendmsg net/socket.c:2618 [inline]
> __sys_sendmsg+0x269/0x350 net/socket.c:2650
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f35ab38d169
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f35ac28f038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00007f35ab5a6160 RCX: 00007f35ab38d169
> RDX: 0000000000000000 RSI: 0000400000000000 RDI: 0000000000000004
> RBP: 00007f35ab40e2a0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 0000000000000001 R14: 00007f35ab5a6160 R15: 00007ffdddd781b8
> </TASK>
>
> Allocated by task 7770:
> kasan_save_stack mm/kasan/common.c:47 [inline]
> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
> unpoison_slab_object mm/kasan/common.c:319 [inline]
> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
> kasan_slab_alloc include/linux/kasan.h:250 [inline]
> slab_post_alloc_hook mm/slub.c:4115 [inline]
> slab_alloc_node mm/slub.c:4164 [inline]
> kmem_cache_alloc_noprof+0x1d9/0x380 mm/slub.c:4171
> sk_prot_alloc+0x58/0x210 net/core/sock.c:2190
> sk_alloc+0x3e/0x370 net/core/sock.c:2249
> inet_create+0x648/0xea0 net/ipv4/af_inet.c:326
> __sock_create+0x4c0/0xa30 net/socket.c:1539
> sock_create net/socket.c:1597 [inline]
> __sys_socket_create net/socket.c:1634 [inline]
> __sys_socket+0x150/0x3c0 net/socket.c:1681
> __do_sys_socket net/socket.c:1695 [inline]
> __se_sys_socket net/socket.c:1693 [inline]
> __x64_sys_socket+0x7a/0x90 net/socket.c:1693
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 7768:
> kasan_save_stack mm/kasan/common.c:47 [inline]
> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576
> poison_slab_object mm/kasan/common.c:247 [inline]
> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
> kasan_slab_free include/linux/kasan.h:233 [inline]
> slab_free_hook mm/slub.c:2353 [inline]
> slab_free mm/slub.c:4609 [inline]
> kmem_cache_free+0x195/0x410 mm/slub.c:4711
> sk_prot_free net/core/sock.c:2230 [inline]
> __sk_destruct+0x4fd/0x690 net/core/sock.c:2327
> inet_release+0x17d/0x200 net/ipv4/af_inet.c:435
> __sock_release net/socket.c:647 [inline]
> sock_close+0xbc/0x240 net/socket.c:1389
> __fput+0x3e9/0x9f0 fs/file_table.c:464
> task_work_run+0x24f/0x310 kernel/task_work.c:227
> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
> exit_to_user_mode_loop kernel/entry/common.c:114 [inline]
> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
> syscall_exit_to_user_mode+0x13f/0x340 kernel/entry/common.c:218
> do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff88801235e4c0
> which belongs to the cache UDP of size 1856
> The buggy address is located 1832 bytes inside of
> freed 1856-byte region [ffff88801235e4c0, ffff88801235ec00)
>
> At disposal time, to avoid unconditionally acquiring a spin lock, UDP
> tunnel sockets are conditionally removed from the known tunnels list
> only if the socket is actually present in such a list.
>
> Such check happens outside the socket lock scope: the current CPU
> could observe an uninitialized list entry even if the tunnel has been
> actually registered by a different core.
>
> Address the issue moving the blamed check under the relevant list
> spin lock.
>
> Reported-by: syzbot+1fb3291cc1beeb3c315a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1fb3291cc1beeb3c315a
> Fixes: 8d4880db37835 ("udp_tunnel: create a fastpath GRO lookup.")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
next prev parent reply other threads:[~2025-03-25 16:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 11:52 [PATCH net-next v2 0/5] udp_tunnel: GRO optimization follow-up Paolo Abeni
2025-03-21 11:52 ` [PATCH net-next v2 1/5] udp_tunnel: properly deal with xfrm gro encap Paolo Abeni
2025-03-21 16:33 ` Willem de Bruijn
2025-03-25 9:52 ` Paolo Abeni
2025-03-25 12:12 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 2/5] udp_tunnel: fix compile warning Paolo Abeni
2025-03-21 16:35 ` Willem de Bruijn
2025-03-21 17:11 ` Sabrina Dubroca
2025-03-25 16:09 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 3/5] udp_tunnel: fix UaF in GRO accounting Paolo Abeni
2025-03-21 16:39 ` Willem de Bruijn
2025-03-25 16:10 ` Sabrina Dubroca [this message]
2025-03-21 11:52 ` [PATCH net-next v2 4/5] udp_tunnel: avoid inconsistent local variables usage Paolo Abeni
2025-03-21 16:39 ` Willem de Bruijn
2025-03-25 16:17 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 5/5] udp_tunnel: prevent GRO lookup optimization for user-space sockets Paolo Abeni
2025-03-21 16:43 ` Willem de Bruijn
2025-03-25 16:22 ` Sabrina Dubroca
2025-03-25 16:24 ` [PATCH net-next v2 0/5] udp_tunnel: GRO optimization follow-up Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z-LVXCFm9Dyf8seK@krikkit \
--to=sd@queasysnail.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).