* [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
@ 2023-05-23 16:33 Kuniyuki Iwashima
2023-05-25 8:59 ` Paolo Abeni
2023-05-25 9:20 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 8+ messages in thread
From: Kuniyuki Iwashima @ 2023-05-23 16:33 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Kuniyuki Iwashima, Kuniyuki Iwashima, netdev,
syzbot+444ca0907e96f7c5e48b
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(+)
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,
};
--
2.30.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-23 16:33 [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated() Kuniyuki Iwashima
@ 2023-05-25 8:59 ` Paolo Abeni
2023-05-25 15:10 ` Kuniyuki Iwashima
2023-05-25 9:20 ` patchwork-bot+netdevbpf
1 sibling, 1 reply; 8+ messages in thread
From: Paolo Abeni @ 2023-05-25 8:59 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S. Miller, Eric Dumazet, Jakub Kicinski
Cc: Kuniyuki Iwashima, netdev, syzbot+444ca0907e96f7c5e48b
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-23 16:33 [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated() Kuniyuki Iwashima
2023-05-25 8:59 ` Paolo Abeni
@ 2023-05-25 9:20 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 8+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-05-25 9:20 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, kuni1840, netdev,
syzbot+444ca0907e96f7c5e48b
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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-25 8:59 ` Paolo Abeni
@ 2023-05-25 15:10 ` Kuniyuki Iwashima
2023-05-25 15:18 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: Kuniyuki Iwashima @ 2023-05-25 15:10 UTC (permalink / raw)
To: pabeni
Cc: davem, edumazet, kuba, kuni1840, kuniyu, netdev,
syzbot+444ca0907e96f7c5e48b
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<---
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-25 15:10 ` Kuniyuki Iwashima
@ 2023-05-25 15:18 ` Florian Westphal
2023-05-25 16:21 ` Kuniyuki Iwashima
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2023-05-25 15:18 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: pabeni, davem, edumazet, kuba, kuni1840, netdev,
syzbot+444ca0907e96f7c5e48b
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-25 15:18 ` Florian Westphal
@ 2023-05-25 16:21 ` Kuniyuki Iwashima
2023-05-25 16:33 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: Kuniyuki Iwashima @ 2023-05-25 16:21 UTC (permalink / raw)
To: fw
Cc: davem, edumazet, kuba, kuni1840, kuniyu, netdev, pabeni,
syzbot+444ca0907e96f7c5e48b
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-25 16:21 ` Kuniyuki Iwashima
@ 2023-05-25 16:33 ` Florian Westphal
2023-05-25 17:06 ` Kuniyuki Iwashima
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2023-05-25 16:33 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: fw, davem, edumazet, kuba, kuni1840, netdev, pabeni,
syzbot+444ca0907e96f7c5e48b
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...).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
2023-05-25 16:33 ` Florian Westphal
@ 2023-05-25 17:06 ` Kuniyuki Iwashima
0 siblings, 0 replies; 8+ messages in thread
From: Kuniyuki Iwashima @ 2023-05-25 17:06 UTC (permalink / raw)
To: fw
Cc: davem, edumazet, kuba, kuni1840, kuniyu, netdev, pabeni,
syzbot+444ca0907e96f7c5e48b
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-05-25 17:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-23 16:33 [PATCH v1 net] udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated() Kuniyuki Iwashima
2023-05-25 8:59 ` Paolo Abeni
2023-05-25 15:10 ` Kuniyuki Iwashima
2023-05-25 15:18 ` Florian Westphal
2023-05-25 16:21 ` Kuniyuki Iwashima
2023-05-25 16:33 ` Florian Westphal
2023-05-25 17:06 ` Kuniyuki Iwashima
2023-05-25 9:20 ` patchwork-bot+netdevbpf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.