CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

syzkaller triggered the warning [0] in udp_v4_early_demux().

In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
of the looked-up sk and use sock_pfree() as skb->destructor, so we check
SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
period.

Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
into the hash table.  Moreover, the SOCK_RCU_FREE check is done too early
in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
window:

  CPU1                                 CPU2
  ----                                 ----
  udp_v4_early_demux()                 udp_lib_get_port()
  |                                    |- hlist_add_head_rcu()
  |- sk = __udp4_lib_demux_lookup()    |
  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
                                       `- sock_set_flag(sk, SOCK_RCU_FREE)

We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
set SOCK_RCU_FREE before inserting socket into hashtable").

Let's apply the same fix for UDP.

[0]:
WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
Modules linked in:
CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
FS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
PKRU: 55555554
Call Trace:
 <TASK>
 ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349
 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624
 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738
 netif_receive_skb_internal net/core/dev.c:5824 [inline]
 netif_receive_skb+0x271/0x300 net/core/dev.c:5884
 tun_rx_batched drivers/net/tun.c:1549 [inline]
 tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002
 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048
 new_sync_write fs/read_write.c:497 [inline]
 vfs_write+0x76f/0x8d0 fs/read_write.c:590
 ksys_write+0xbf/0x190 fs/read_write.c:643
 __do_sys_write fs/read_write.c:655 [inline]
 __se_sys_write fs/read_write.c:652 [inline]
 __x64_sys_write+0x41/0x50 fs/read_write.c:652
 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7fc44a68bc1f
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48
RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f
RDX: 0000000000000032 RSI: 00000000200000c0 RDI: 00000000000000c8
RBP: 00000000004bc050 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000032 R11: 0000000000000293 R12: 0000000000000000
R13: 000000000000000b R14: 00007fc44a5ec530 R15: 0000000000000000
 </TASK>

The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c
	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.15.163 with commit ddf516e50bf8
	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 6.1.100 with commit a6db0d3ea653
	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 6.6.41 with commit c5fd77ca13d6
	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 6.9.10 with commit 20ceae10623c
	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 6.10 with commit 5c0b485a8c61

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-41041
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/ipv4/udp.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/7a67c4e47626e6daccda62888f8b096abb5d3940
	https://git.kernel.org/stable/c/9f965684c57c3117cfd2f754dd3270383c529fba
	https://git.kernel.org/stable/c/ddf516e50bf8a7bc9b3bd8a9831f9c7a8131a32a
	https://git.kernel.org/stable/c/a6db0d3ea6536e7120871e5448b3032570152ec6
	https://git.kernel.org/stable/c/c5fd77ca13d657c6e99bf04f0917445e6a80231e
	https://git.kernel.org/stable/c/20ceae10623c3b29fdf7609690849475bcdebdb0
	https://git.kernel.org/stable/c/5c0b485a8c6116516f33925b9ce5b6104a6eadfd

Re: CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[Siddh Raman Pant]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Mon, 29 Jul 2024 16:32:36 +0200, Greg Kroah-Hartman wrote:
> In the Linux kernel, the following vulnerability has been resolved:
> 
> udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
> 
> [...]
> 
> We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
> set SOCK_RCU_FREE before inserting socket into hashtable").
> 
> Let's apply the same fix for UDP.
> 
> [...]
> 
> The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
> 	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c

These versions don't have the TCP fix backported. Please do so.

Thanks,
Siddh

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[gregkh]

On Tue, Sep 03, 2024 at 11:56:17AM +0000, Siddh Raman Pant wrote:
> On Mon, 29 Jul 2024 16:32:36 +0200, Greg Kroah-Hartman wrote:
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
> > 
> > [...]
> > 
> > We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
> > set SOCK_RCU_FREE before inserting socket into hashtable").
> > 
> > Let's apply the same fix for UDP.
> > 
> > [...]
> > 
> > The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.
> > 
> > 
> > Affected and fixed versions
> > ===========================
> > 
> > 	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
> > 	Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c
> 
> These versions don't have the TCP fix backported. Please do so.

What fix backported exactly to where?  Please be more specific.  Better
yet, please provide working, and tested, backports.

confused,

greg k-h

Re: CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[Eric Dumazet]

On Tue, Sep 3, 2024 at 2:07 PM gregkh@linuxfoundation.org
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Sep 03, 2024 at 11:56:17AM +0000, Siddh Raman Pant wrote:
> > On Mon, 29 Jul 2024 16:32:36 +0200, Greg Kroah-Hartman wrote:
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
> > >
> > > [...]
> > >
> > > We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
> > > set SOCK_RCU_FREE before inserting socket into hashtable").
> > >
> > > Let's apply the same fix for UDP.
> > >
> > > [...]
> > >
> > > The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.
> > >
> > >
> > > Affected and fixed versions
> > > ===========================
> > >
> > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
> > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c
> >
> > These versions don't have the TCP fix backported. Please do so.
>
> What fix backported exactly to where?  Please be more specific.  Better
> yet, please provide working, and tested, backports.


commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99
Author: Stanislav Fomichev <sdf@fomichev.me>
Date:   Wed Nov 8 13:13:25 2023 -0800

    net: set SOCK_RCU_FREE before inserting socket into hashtable
...
    Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")

It seems 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 has not been pushed
to 5.10 or 5.4 lts

Stanislav mentioned a WARN_ONCE() being hit, I presume we could push
the patch to 5.10 and 5.4.

I guess this was skipped because of a merge conflict.

Re: CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[gregkh]

On Tue, Sep 03, 2024 at 02:53:57PM +0200, Eric Dumazet wrote:
> On Tue, Sep 3, 2024 at 2:07 PM gregkh@linuxfoundation.org
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Sep 03, 2024 at 11:56:17AM +0000, Siddh Raman Pant wrote:
> > > On Mon, 29 Jul 2024 16:32:36 +0200, Greg Kroah-Hartman wrote:
> > > > In the Linux kernel, the following vulnerability has been resolved:
> > > >
> > > > udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
> > > >
> > > > [...]
> > > >
> > > > We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
> > > > set SOCK_RCU_FREE before inserting socket into hashtable").
> > > >
> > > > Let's apply the same fix for UDP.
> > > >
> > > > [...]
> > > >
> > > > The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.
> > > >
> > > >
> > > > Affected and fixed versions
> > > > ===========================
> > > >
> > > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
> > > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c
> > >
> > > These versions don't have the TCP fix backported. Please do so.
> >
> > What fix backported exactly to where?  Please be more specific.  Better
> > yet, please provide working, and tested, backports.
> 
> 
> commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99
> Author: Stanislav Fomichev <sdf@fomichev.me>
> Date:   Wed Nov 8 13:13:25 2023 -0800
> 
>     net: set SOCK_RCU_FREE before inserting socket into hashtable
> ...
>     Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
> 
> It seems 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 has not been pushed
> to 5.10 or 5.4 lts
> 
> Stanislav mentioned a WARN_ONCE() being hit, I presume we could push
> the patch to 5.10 and 5.4.
> 
> I guess this was skipped because of a merge conflict.

Yes, the commit does not apply, we need someone to send a working
backport for us to be able to take it.

Siddh, can you please do this?

thanks,

greg k-h

Re: CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[Siddh Raman Pant]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

On Tue, Sep 03 2024 at 18:28:14 +0530, gregkh@linuxfoundation.org
wrote:
> On Tue, Sep 03, 2024 at 02:53:57PM +0200, Eric Dumazet wrote:
> > On Tue, Sep 3, 2024 at 2:07 PM gregkh@linuxfoundation.org
> > <gregkh@linuxfoundation.org> wrote:
> > > 
> > > On Tue, Sep 03, 2024 at 11:56:17AM +0000, Siddh Raman Pant wrote:
> > > > On Mon, 29 Jul 2024 16:32:36 +0200, Greg Kroah-Hartman wrote:
> > > > > In the Linux kernel, the following vulnerability has been resolved:
> > > > > 
> > > > > udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
> > > > > 
> > > > > [...]
> > > > > 
> > > > > We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
> > > > > set SOCK_RCU_FREE before inserting socket into hashtable").
> > > > > 
> > > > > Let's apply the same fix for UDP.
> > > > > 
> > > > > [...]
> > > > > 
> > > > > The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.
> > > > > 
> > > > > 
> > > > > Affected and fixed versions
> > > > > ===========================
> > > > > 
> > > > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
> > > > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c
> > > > 
> > > > These versions don't have the TCP fix backported. Please do so.
> > > 
> > > What fix backported exactly to where?  Please be more specific.  Better
> > > yet, please provide working, and tested, backports.
> > 
> > 
> > commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99
> > Author: Stanislav Fomichev <sdf@fomichev.me>
> > Date:   Wed Nov 8 13:13:25 2023 -0800
> > 
> >     net: set SOCK_RCU_FREE before inserting socket into hashtable
> > ...
> >     Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
> > 
> > It seems 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 has not been pushed
> > to 5.10 or 5.4 lts
> > 
> > Stanislav mentioned a WARN_ONCE() being hit, I presume we could push
> > the patch to 5.10 and 5.4.
> > 
> > I guess this was skipped because of a merge conflict.
> 
> Yes, the commit does not apply, we need someone to send a working
> backport for us to be able to take it.
> 
> Siddh, can you please do this?

Sure.

I see there are Stable-dep commits too, but the seem unrelated and
require some commits from another feature patchset. Do I need to
backport them too?

Thanks,
Siddh

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: CVE-2024-41041: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().

[gregkh]

On Wed, Sep 04, 2024 at 11:26:36AM +0000, Siddh Raman Pant wrote:
> On Tue, Sep 03 2024 at 18:28:14 +0530, gregkh@linuxfoundation.org
> wrote:
> > On Tue, Sep 03, 2024 at 02:53:57PM +0200, Eric Dumazet wrote:
> > > On Tue, Sep 3, 2024 at 2:07 PM gregkh@linuxfoundation.org
> > > <gregkh@linuxfoundation.org> wrote:
> > > > 
> > > > On Tue, Sep 03, 2024 at 11:56:17AM +0000, Siddh Raman Pant wrote:
> > > > > On Mon, 29 Jul 2024 16:32:36 +0200, Greg Kroah-Hartman wrote:
> > > > > > In the Linux kernel, the following vulnerability has been resolved:
> > > > > > 
> > > > > > udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
> > > > > > set SOCK_RCU_FREE before inserting socket into hashtable").
> > > > > > 
> > > > > > Let's apply the same fix for UDP.
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > The Linux kernel CVE team has assigned CVE-2024-41041 to this issue.
> > > > > > 
> > > > > > 
> > > > > > Affected and fixed versions
> > > > > > ===========================
> > > > > > 
> > > > > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.4.280 with commit 7a67c4e47626
> > > > > >     Issue introduced in 4.20 with commit 6acc9b432e67 and fixed in 5.10.222 with commit 9f965684c57c
> > > > > 
> > > > > These versions don't have the TCP fix backported. Please do so.
> > > > 
> > > > What fix backported exactly to where?  Please be more specific.  Better
> > > > yet, please provide working, and tested, backports.
> > > 
> > > 
> > > commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99
> > > Author: Stanislav Fomichev <sdf@fomichev.me>
> > > Date:   Wed Nov 8 13:13:25 2023 -0800
> > > 
> > >     net: set SOCK_RCU_FREE before inserting socket into hashtable
> > > ...
> > >     Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
> > > 
> > > It seems 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 has not been pushed
> > > to 5.10 or 5.4 lts
> > > 
> > > Stanislav mentioned a WARN_ONCE() being hit, I presume we could push
> > > the patch to 5.10 and 5.4.
> > > 
> > > I guess this was skipped because of a merge conflict.
> > 
> > Yes, the commit does not apply, we need someone to send a working
> > backport for us to be able to take it.
> > 
> > Siddh, can you please do this?
> 
> Sure.
> 
> I see there are Stable-dep commits too, but the seem unrelated and
> require some commits from another feature patchset. Do I need to
> backport them too?

Do what you think you need to do :)

[PATCH 5.10, 5.4] net: set SOCK_RCU_FREE before inserting socket into hashtable

[Siddh Raman Pant]

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

[ Upstream commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 ]

We've started to see the following kernel traces:

 WARNING: CPU: 83 PID: 0 at net/core/filter.c:6641 sk_lookup+0x1bd/0x1d0

 Call Trace:
  <IRQ>
  __bpf_skc_lookup+0x10d/0x120
  bpf_sk_lookup+0x48/0xd0
  bpf_sk_lookup_tcp+0x19/0x20
  bpf_prog_<redacted>+0x37c/0x16a3
  cls_bpf_classify+0x205/0x2e0
  tcf_classify+0x92/0x160
  __netif_receive_skb_core+0xe52/0xf10
  __netif_receive_skb_list_core+0x96/0x2b0
  napi_complete_done+0x7b5/0xb70
  <redacted>_poll+0x94/0xb0
  net_rx_action+0x163/0x1d70
  __do_softirq+0xdc/0x32e
  asm_call_irq_on_stack+0x12/0x20
  </IRQ>
  do_softirq_own_stack+0x36/0x50
  do_softirq+0x44/0x70

__inet_hash can race with lockless (rcu) readers on the other cpus:

  __inet_hash
    __sk_nulls_add_node_rcu
    <- (bpf triggers here)
    sock_set_flag(SOCK_RCU_FREE)

Let's move the SOCK_RCU_FREE part up a bit, before we are inserting
the socket into hashtables. Note, that the race is really harmless;
the bpf callers are handling this situation (where listener socket
doesn't have SOCK_RCU_FREE set) correctly, so the only
annoyance is a WARN_ONCE.

More details from Eric regarding SOCK_RCU_FREE timeline:

Commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under
synflood") added SOCK_RCU_FREE. At that time, the precise location of
sock_set_flag(sk, SOCK_RCU_FREE) did not matter, because the thread calling
__inet_hash() owns a reference on sk. SOCK_RCU_FREE was only tested
at dismantle time.

Commit 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
started checking SOCK_RCU_FREE _after_ the lookup to infer whether
the refcount has been taken care of.

Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Resolved conflict for 5.10 and below.]
Signed-off-by: Siddh Raman Pant <siddh.raman.pant@oracle.com>
---
 net/ipv4/inet_hashtables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 56deddeac1b0..0fb5d758264f 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -653,6 +653,7 @@ int __inet_hash(struct sock *sk, struct sock *osk)
 		if (err)
 			goto unlock;
 	}
+	sock_set_flag(sk, SOCK_RCU_FREE);
 	if (IS_ENABLED(CONFIG_IPV6) && sk->sk_reuseport &&
 		sk->sk_family == AF_INET6)
 		__sk_nulls_add_node_tail_rcu(sk, &ilb->nulls_head);
@@ -660,7 +661,6 @@ int __inet_hash(struct sock *sk, struct sock *osk)
 		__sk_nulls_add_node_rcu(sk, &ilb->nulls_head);
 	inet_hash2(hashinfo, sk);
 	ilb->count++;
-	sock_set_flag(sk, SOCK_RCU_FREE);
 	sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
 unlock:
 	spin_unlock(&ilb->lock);
-- 
2.45.2


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 5.10, 5.4] net: set SOCK_RCU_FREE before inserting socket into hashtable

[gregkh]

On Wed, Sep 04, 2024 at 01:06:45PM +0000, Siddh Raman Pant wrote:
> [ Upstream commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 ]
> 
> We've started to see the following kernel traces:
> 
>  WARNING: CPU: 83 PID: 0 at net/core/filter.c:6641 sk_lookup+0x1bd/0x1d0
> 
>  Call Trace:
>   <IRQ>
>   __bpf_skc_lookup+0x10d/0x120
>   bpf_sk_lookup+0x48/0xd0
>   bpf_sk_lookup_tcp+0x19/0x20
>   bpf_prog_<redacted>+0x37c/0x16a3
>   cls_bpf_classify+0x205/0x2e0
>   tcf_classify+0x92/0x160
>   __netif_receive_skb_core+0xe52/0xf10
>   __netif_receive_skb_list_core+0x96/0x2b0
>   napi_complete_done+0x7b5/0xb70
>   <redacted>_poll+0x94/0xb0
>   net_rx_action+0x163/0x1d70
>   __do_softirq+0xdc/0x32e
>   asm_call_irq_on_stack+0x12/0x20
>   </IRQ>
>   do_softirq_own_stack+0x36/0x50
>   do_softirq+0x44/0x70
> 
> __inet_hash can race with lockless (rcu) readers on the other cpus:
> 
>   __inet_hash
>     __sk_nulls_add_node_rcu
>     <- (bpf triggers here)
>     sock_set_flag(SOCK_RCU_FREE)
> 
> Let's move the SOCK_RCU_FREE part up a bit, before we are inserting
> the socket into hashtables. Note, that the race is really harmless;
> the bpf callers are handling this situation (where listener socket
> doesn't have SOCK_RCU_FREE set) correctly, so the only
> annoyance is a WARN_ONCE.
> 
> More details from Eric regarding SOCK_RCU_FREE timeline:
> 
> Commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under
> synflood") added SOCK_RCU_FREE. At that time, the precise location of
> sock_set_flag(sk, SOCK_RCU_FREE) did not matter, because the thread calling
> __inet_hash() owns a reference on sk. SOCK_RCU_FREE was only tested
> at dismantle time.
> 
> Commit 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
> started checking SOCK_RCU_FREE _after_ the lookup to infer whether
> the refcount has been taken care of.
> 
> Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
> Reviewed-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> [Resolved conflict for 5.10 and below.]
> Signed-off-by: Siddh Raman Pant <siddh.raman.pant@oracle.com>
> ---
>  net/ipv4/inet_hashtables.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Now  queued up, thanks.

greg k-h