CVE-2024-53124: net: fix data-races around sk->sk_forward_alloc

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

net: fix data-races around sk->skforwardalloc

Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable skmemreclaim skforwardallocadd()

In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 skmemschedule() | | +4096 = 4096 | skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | skmemreclaim() | | -4096 = 4096 | skmemreclaim() | -8192 = -4096 != 0

The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().

— NVD

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

— Launchpad