Message ID | 20230523163305.66466-1-kuniyu@amazon.com (mailing list archive) |
---|---|
State | Accepted |
Commit | ad42a35bdfc6d3c0fc4cb4027d7b2757ce665665 |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [v1,net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated(). | expand |
On Tue, 2023-05-23 at 09:33 -0700, Kuniyuki Iwashima wrote: > syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using > IPPROTO_UDPLITE (0x88): > > 14:25:52 executing program 1: > r0 = socket$inet6(0xa, 0x80002, 0x88) > > We had a similar report [1] for probably sk_memory_allocated_add() > in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix > NULL pointer dereference") fixed it by setting .memory_allocated for > udplite_prot and udplitev6_prot. > > To fix the variant, we need to set either .sysctl_wmem_offset or > .sysctl_rmem. > > Now UDP and UDPLITE share the same value for .memory_allocated, so we > use the same .sysctl_wmem_offset for UDP and UDPLITE. > > [0]: > general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] > CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 > RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline] > RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006 > Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b > RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 > RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 > RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 > RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 > R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 > FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 > Call Trace: > <TASK> > __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 > udp_rmem_schedule net/ipv4/udp.c:1539 [inline] > __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 > __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] > udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 > udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 > __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] > __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 > ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 > ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 > NF_HOOK include/linux/netfilter.h:303 [inline] > NF_HOOK include/linux/netfilter.h:297 [inline] > ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 > ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 > dst_input include/net/dst.h:468 [inline] > ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] > NF_HOOK include/linux/netfilter.h:303 [inline] > NF_HOOK include/linux/netfilter.h:297 [inline] > ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 > __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 > __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 > netif_receive_skb_internal net/core/dev.c:5691 [inline] > netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 > tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 > tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 > tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 > call_write_iter include/linux/fs.h:1868 [inline] > new_sync_write fs/read_write.c:491 [inline] > vfs_write+0x945/0xd50 fs/read_write.c:584 > ksys_write+0x12b/0x250 fs/read_write.c:637 > do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] > __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 > do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 > entry_SYSENTER_compat_after_hwframe+0x70/0x82 > RIP: 0023:0xf7f21579 > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 > RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004 > RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040 > RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000 > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > </TASK> > Modules linked in: > > Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1] > Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema") Thanks for addressing this issue! The patch LGTM. Side note: the blamed commit is almost 7y old and the oops should not that hard to reproduce by a real app using UDP-lite, but only syzkaller stumbled upon it. The above looks like a serious hint UDP-lite is not used by anyone anymore ?!? Perhaps we could consider deprecating and dropping it? It could simplify the UDP code a bit removing a bunch of conditionals in fast-path, and that nowadays would be possibly more relevant?!? Cheers, Paolo
Hello: This patch was applied to netdev/net.git (main) by Paolo Abeni <pabeni@redhat.com>: On Tue, 23 May 2023 09:33:05 -0700 you wrote: > syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using > IPPROTO_UDPLITE (0x88): > > 14:25:52 executing program 1: > r0 = socket$inet6(0xa, 0x80002, 0x88) > > We had a similar report [1] for probably sk_memory_allocated_add() > in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix > NULL pointer dereference") fixed it by setting .memory_allocated for > udplite_prot and udplitev6_prot. > > [...] Here is the summary with links: - [v1,net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated(). https://git.kernel.org/netdev/net/c/ad42a35bdfc6 You are awesome, thank you!
From: Paolo Abeni <pabeni@redhat.com> Date: Thu, 25 May 2023 10:59:09 +0200 > On Tue, 2023-05-23 at 09:33 -0700, Kuniyuki Iwashima wrote: > > syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using > > IPPROTO_UDPLITE (0x88): > > > > 14:25:52 executing program 1: > > r0 = socket$inet6(0xa, 0x80002, 0x88) > > > > We had a similar report [1] for probably sk_memory_allocated_add() > > in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix > > NULL pointer dereference") fixed it by setting .memory_allocated for > > udplite_prot and udplitev6_prot. > > > > To fix the variant, we need to set either .sysctl_wmem_offset or > > .sysctl_rmem. > > > > Now UDP and UDPLITE share the same value for .memory_allocated, so we > > use the same .sysctl_wmem_offset for UDP and UDPLITE. > > > > [0]: > > general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] > > CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 > > RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline] > > RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006 > > Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b > > RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 > > RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 > > RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 > > RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 > > R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 > > FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 > > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > > CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 > > Call Trace: > > <TASK> > > __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 > > udp_rmem_schedule net/ipv4/udp.c:1539 [inline] > > __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 > > __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] > > udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 > > udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 > > __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] > > __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 > > ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 > > ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 > > NF_HOOK include/linux/netfilter.h:303 [inline] > > NF_HOOK include/linux/netfilter.h:297 [inline] > > ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 > > ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 > > dst_input include/net/dst.h:468 [inline] > > ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] > > NF_HOOK include/linux/netfilter.h:303 [inline] > > NF_HOOK include/linux/netfilter.h:297 [inline] > > ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 > > __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 > > __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 > > netif_receive_skb_internal net/core/dev.c:5691 [inline] > > netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 > > tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 > > tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 > > tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 > > call_write_iter include/linux/fs.h:1868 [inline] > > new_sync_write fs/read_write.c:491 [inline] > > vfs_write+0x945/0xd50 fs/read_write.c:584 > > ksys_write+0x12b/0x250 fs/read_write.c:637 > > do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] > > __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 > > do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 > > entry_SYSENTER_compat_after_hwframe+0x70/0x82 > > RIP: 0023:0xf7f21579 > > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 > > RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004 > > RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040 > > RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000 > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > </TASK> > > Modules linked in: > > > > Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1] > > Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema") > > Thanks for addressing this issue! > > The patch LGTM. > > Side note: the blamed commit is almost 7y old and the oops should not > that hard to reproduce by a real app using UDP-lite, but only syzkaller > stumbled upon it. > > The above looks like a serious hint UDP-lite is not used by anyone > anymore ?!? Perhaps we could consider deprecating and dropping it? It > could simplify the UDP code a bit removing a bunch of conditionals in > fast-path, and that nowadays would be possibly more relevant?!? Yes, that crossed my mind too :) Maybe we can do like this (or drop it immediately now) and see if someone complains ? ---8<--- diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c index 56d94d23b9e0..39b82082b68f 100644 --- a/net/ipv4/udplite.c +++ b/net/ipv4/udplite.c @@ -22,6 +22,7 @@ static int udplite_sk_init(struct sock *sk) { udp_init_sock(sk); udp_sk(sk)->pcflag = UDPLITE_BIT; + pr_warn("IPPROTO_UDPLITE will be deprecated at the end of 2024\n"); return 0; } diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c index 3bab0cc13697..54828f08926f 100644 --- a/net/ipv6/udplite.c +++ b/net/ipv6/udplite.c @@ -8,6 +8,9 @@ * Changes: * Fixes: */ + +#define pr_fmt(fmt) "UDPLite6: " fmt + #include <linux/export.h> #include <linux/proc_fs.h> #include "udp_impl.h" @@ -16,6 +19,7 @@ static int udplitev6_sk_init(struct sock *sk) { udpv6_init_sock(sk); udp_sk(sk)->pcflag = UDPLITE_BIT; + pr_warn("IPPROTO_UDPLITE will be deprecated at the end of 2024\n"); return 0; } ---8<---
Kuniyuki Iwashima <kuniyu@amazon.com> wrote: > From: Paolo Abeni <pabeni@redhat.com> > Date: Thu, 25 May 2023 10:59:09 +0200 > > On Tue, 2023-05-23 at 09:33 -0700, Kuniyuki Iwashima wrote: > > > syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using > > > IPPROTO_UDPLITE (0x88): > > > > > > 14:25:52 executing program 1: > > > r0 = socket$inet6(0xa, 0x80002, 0x88) > > > > > > We had a similar report [1] for probably sk_memory_allocated_add() > > > in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix > > > NULL pointer dereference") fixed it by setting .memory_allocated for > > > udplite_prot and udplitev6_prot. > > > > > > To fix the variant, we need to set either .sysctl_wmem_offset or > > > .sysctl_rmem. > > > > > > Now UDP and UDPLITE share the same value for .memory_allocated, so we > > > use the same .sysctl_wmem_offset for UDP and UDPLITE. > > > > > > [0]: > > > general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN > > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] > > > CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 > > > RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline] > > > RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006 > > > Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b > > > RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 > > > RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 > > > RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 > > > RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 > > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 > > > R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 > > > FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 > > > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > > > CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 > > > Call Trace: > > > <TASK> > > > __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 > > > udp_rmem_schedule net/ipv4/udp.c:1539 [inline] > > > __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 > > > __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] > > > udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 > > > udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 > > > __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] > > > __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 > > > ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 > > > ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 > > > NF_HOOK include/linux/netfilter.h:303 [inline] > > > NF_HOOK include/linux/netfilter.h:297 [inline] > > > ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 > > > ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 > > > dst_input include/net/dst.h:468 [inline] > > > ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] > > > NF_HOOK include/linux/netfilter.h:303 [inline] > > > NF_HOOK include/linux/netfilter.h:297 [inline] > > > ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 > > > __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 > > > __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 > > > netif_receive_skb_internal net/core/dev.c:5691 [inline] > > > netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 > > > tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 > > > tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 > > > tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 > > > call_write_iter include/linux/fs.h:1868 [inline] > > > new_sync_write fs/read_write.c:491 [inline] > > > vfs_write+0x945/0xd50 fs/read_write.c:584 > > > ksys_write+0x12b/0x250 fs/read_write.c:637 > > > do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] > > > __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 > > > do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 > > > entry_SYSENTER_compat_after_hwframe+0x70/0x82 > > > RIP: 0023:0xf7f21579 > > > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 > > > RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004 > > > RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040 > > > RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000 > > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > > R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 > > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > </TASK> > > > Modules linked in: > > > > > > Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1] > > > Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema") > > > > Thanks for addressing this issue! > > > > The patch LGTM. > > > > Side note: the blamed commit is almost 7y old and the oops should not > > that hard to reproduce by a real app using UDP-lite, but only syzkaller > > stumbled upon it. > > > > The above looks like a serious hint UDP-lite is not used by anyone > > anymore ?!? Perhaps we could consider deprecating and dropping it? It > > could simplify the UDP code a bit removing a bunch of conditionals in > > fast-path, and that nowadays would be possibly more relevant?!? > > Yes, that crossed my mind too :) > > Maybe we can do like this (or drop it immediately now) and see if someone > complains ? I'd remove it in -next. Same for DCCP.
From: Florian Westphal <fw@strlen.de> Date: Thu, 25 May 2023 17:18:42 +0200 > Kuniyuki Iwashima <kuniyu@amazon.com> wrote: > > From: Paolo Abeni <pabeni@redhat.com> > > Date: Thu, 25 May 2023 10:59:09 +0200 > > > On Tue, 2023-05-23 at 09:33 -0700, Kuniyuki Iwashima wrote: > > > > syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using > > > > IPPROTO_UDPLITE (0x88): > > > > > > > > 14:25:52 executing program 1: > > > > r0 = socket$inet6(0xa, 0x80002, 0x88) > > > > > > > > We had a similar report [1] for probably sk_memory_allocated_add() > > > > in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix > > > > NULL pointer dereference") fixed it by setting .memory_allocated for > > > > udplite_prot and udplitev6_prot. > > > > > > > > To fix the variant, we need to set either .sysctl_wmem_offset or > > > > .sysctl_rmem. > > > > > > > > Now UDP and UDPLITE share the same value for .memory_allocated, so we > > > > use the same .sysctl_wmem_offset for UDP and UDPLITE. > > > > > > > > [0]: > > > > general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN > > > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] > > > > CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 > > > > RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline] > > > > RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006 > > > > Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b > > > > RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 > > > > RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 > > > > RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 > > > > RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 > > > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 > > > > R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 > > > > FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 > > > > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > > > > CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 > > > > Call Trace: > > > > <TASK> > > > > __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 > > > > udp_rmem_schedule net/ipv4/udp.c:1539 [inline] > > > > __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 > > > > __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] > > > > udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 > > > > udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 > > > > __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] > > > > __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 > > > > ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 > > > > ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 > > > > NF_HOOK include/linux/netfilter.h:303 [inline] > > > > NF_HOOK include/linux/netfilter.h:297 [inline] > > > > ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 > > > > ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 > > > > dst_input include/net/dst.h:468 [inline] > > > > ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] > > > > NF_HOOK include/linux/netfilter.h:303 [inline] > > > > NF_HOOK include/linux/netfilter.h:297 [inline] > > > > ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 > > > > __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 > > > > __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 > > > > netif_receive_skb_internal net/core/dev.c:5691 [inline] > > > > netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 > > > > tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 > > > > tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 > > > > tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 > > > > call_write_iter include/linux/fs.h:1868 [inline] > > > > new_sync_write fs/read_write.c:491 [inline] > > > > vfs_write+0x945/0xd50 fs/read_write.c:584 > > > > ksys_write+0x12b/0x250 fs/read_write.c:637 > > > > do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] > > > > __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 > > > > do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 > > > > entry_SYSENTER_compat_after_hwframe+0x70/0x82 > > > > RIP: 0023:0xf7f21579 > > > > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 > > > > RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004 > > > > RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040 > > > > RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000 > > > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > > > R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 > > > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > > </TASK> > > > > Modules linked in: > > > > > > > > Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1] > > > > Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema") > > > > > > Thanks for addressing this issue! > > > > > > The patch LGTM. > > > > > > Side note: the blamed commit is almost 7y old and the oops should not > > > that hard to reproduce by a real app using UDP-lite, but only syzkaller > > > stumbled upon it. > > > > > > The above looks like a serious hint UDP-lite is not used by anyone > > > anymore ?!? Perhaps we could consider deprecating and dropping it? It > > > could simplify the UDP code a bit removing a bunch of conditionals in > > > fast-path, and that nowadays would be possibly more relevant?!? > > > > Yes, that crossed my mind too :) > > > > Maybe we can do like this (or drop it immediately now) and see if someone > > complains ? > > I'd remove it in -next. Same for DCCP. Ok, I'll do for UDP Lite. +1 for DCCP, but we know there are real? still experimenting? users ... ? https://lore.kernel.org/netdev/20230519082143.3d20db49@kernel.org/
Kuniyuki Iwashima <kuniyu@amazon.com> wrote: > > I'd remove it in -next. Same for DCCP. > > Ok, I'll do for UDP Lite. Thanks. > +1 for DCCP, but we know there are real? > still experimenting? users ... ? Yes, and they can continue to work on their out of tree fork and research projects, no problem. I'd say next time some net/core change needs dccp changes, remove dccp first (or mark it as CONFIG_BROKEN) so it doesn't cause extra work. DCCP can be brought back when someone has interest to maintain it. Looking at DCCP patches its either: 1. odd syzbot fixes 2. api changes in net that need folloup changes in dccp 3. automated transformations There is no sign that anyone is maintaining this (or running it in a production environment...).
From: Florian Westphal <fw@strlen.de> Date: Thu, 25 May 2023 18:33:42 +0200 > Kuniyuki Iwashima <kuniyu@amazon.com> wrote: > > > I'd remove it in -next. Same for DCCP. > > > > Ok, I'll do for UDP Lite. > > Thanks. > > > +1 for DCCP, but we know there are real? > > still experimenting? users ... ? > > Yes, and they can continue to work on their out of tree fork > and research projects, no problem. > > I'd say next time some net/core change needs dccp changes, > remove dccp first (or mark it as CONFIG_BROKEN) so it doesn't > cause extra work. FWIW, I was going to post such a patch that removes .twsk_unique and .twsk_destructor handler in timewait_sock_ops, which is only used by TCP but exists just because DCCP shares the struct. > DCCP can be brought back when someone has interest to maintain it. > > Looking at DCCP patches its either: > 1. odd syzbot fixes > 2. api changes in net that need folloup changes in dccp > 3. automated transformations > > There is no sign that anyone is maintaining this (or running it > in a production environment...). Exactly. It's now kind of bleeding ground of CVE. Actualy, we disable CONFIG_IP_DCCP for our latest distribution (AL2023) for the reason, and RHEL 7.8+ also prevents the module from being loaded by default. If there's no objection, I can remove it after UDP Lite. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.8_release_notes/deprecated_functionality#automatic_loading_of_dccp_modules_through_socket_layer_is_now_disabled_by_default
diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c index e0c9cc39b81e..56d94d23b9e0 100644 --- a/net/ipv4/udplite.c +++ b/net/ipv4/udplite.c @@ -64,6 +64,8 @@ struct proto udplite_prot = { .per_cpu_fw_alloc = &udp_memory_per_cpu_fw_alloc, .sysctl_mem = sysctl_udp_mem, + .sysctl_wmem_offset = offsetof(struct net, ipv4.sysctl_udp_wmem_min), + .sysctl_rmem_offset = offsetof(struct net, ipv4.sysctl_udp_rmem_min), .obj_size = sizeof(struct udp_sock), .h.udp_table = &udplite_table, }; diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c index 67eaf3ca14ce..3bab0cc13697 100644 --- a/net/ipv6/udplite.c +++ b/net/ipv6/udplite.c @@ -60,6 +60,8 @@ struct proto udplitev6_prot = { .per_cpu_fw_alloc = &udp_memory_per_cpu_fw_alloc, .sysctl_mem = sysctl_udp_mem, + .sysctl_wmem_offset = offsetof(struct net, ipv4.sysctl_udp_wmem_min), + .sysctl_rmem_offset = offsetof(struct net, ipv4.sysctl_udp_rmem_min), .obj_size = sizeof(struct udp6_sock), .h.udp_table = &udplite_table, };
syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using IPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88) We had a similar report [1] for probably sk_memory_allocated_add() in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix NULL pointer dereference") fixed it by setting .memory_allocated for udplite_prot and udplitev6_prot. To fix the variant, we need to set either .sysctl_wmem_offset or .sysctl_rmem. Now UDP and UDPLITE share the same value for .memory_allocated, so we use the same .sysctl_wmem_offset for UDP and UDPLITE. [0]: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline] RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006 Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 Call Trace: <TASK> __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 RIP: 0023:0xf7f21579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004 RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040 RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1] Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema") Reported-by: syzbot+444ca0907e96f7c5e48b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=444ca0907e96f7c5e48b Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> --- net/ipv4/udplite.c | 2 ++ net/ipv6/udplite.c | 2 ++ 2 files changed, 4 insertions(+)