CVE-2024-43887: net/tcp: Disable TCP-AO static key after RCU grace period
In the Linux kernel, the following vulnerability has been resolved:
net/tcp: Disable TCP-AO static key after RCU grace period
The lifetime of TCP-AO statickey is the same as the last tcpaoinfo. On the socket destruction tcpaoinfo ceases to be with RCU grace period, while tcp-ao static branch is currently deferred destructed. The static key definition is : DEFINESTATICKEYDEFERREDFALSE(tcpaoneeded, HZ);
which means that if RCU grace period is delayed by more than a second and tcpaoneeded is in the process of disablement, other CPUs may yet see tcpaoinfo which atent dead, but soon-to-be. And that breaks the assumption of statickeyfastincnotdisabled().
See the comment near the definition: The caller must make sure that the static key can't get disabled while in this function. It doesn't patch jump labels, only adds a user to an already enabled static key.
Originally it was introduced in commit eb8c507296f6 ("jumplabel: Prevent key->enabled int overflow"), which is needed for the atomic contexts, one of which would be the creation of a full socket from a request socket. In that atomic context, it's known by the presence of the key (md5/ao) that the static branch is already enabled. So, the ref counter for that static branch is just incremented instead of holding the proper mutex. statickeyfastincnotdisabled() is just a helper for such usage case. But it must not be used if the static branch could get disabled in parallel as it's not protected by jumplabelmutex and as a result, races with jumplabelupdate() implementation details.
Happened on netdev test-bot[1], so not a theoretical issue:
[] jumplabel: Fatal kernel bug, unexpected op at tcpinboundhash+0x1a7/0x870 [ffffffffa8c4e9b7] (eb 50 0f 1f 44 != 66 90 0f 1f 00)) size:2 type:1 [] ------------[ cut here ]------------ [] kernel BUG at arch/x86/kernel/jumplabel.c:73! [] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [] CPU: 3 PID: 243 Comm: kworker/3:3 Not tainted 6.10.0-virtme #1 [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [] Workqueue: events jumplabelupdatetimeout [] RIP: 0010:jumplabelpatch+0x2f6/0x350 ... [] Call Trace: [] <TASK> [] archjumplabeltransformqueue+0x6c/0x110 [] jumplabelupdate+0xef/0x350 [] statickeyslowdeccpuslocked.part.0+0x3c/0x60 [] jumplabelupdatetimeout+0x2c/0x40 [] processonework+0xe3b/0x1670 [] workerthread+0x587/0xce0 [] kthread+0x28a/0x350 [] retfromfork+0x31/0x70 [] retfromforkasm+0x1a/0x30 [] </TASK> [] Modules linked in: veth [] ---[ end trace 0000000000000000 ]--- [] RIP: 0010:jumplabelpatch+0x2f6/0x350
[1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/696681/5-connect-deny-ipv6/stderr
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-43887?
CVE-2024-43887 is classified as a vulnerability in the Linux kernel, affecting network protocols.
How do I fix CVE-2024-43887?
To fix CVE-2024-43887, update the Linux kernel to one of the patched versions listed in the advisory.
Which versions of the Linux kernel are affected by CVE-2024-43887?
CVE-2024-43887 affects multiple versions of the Linux kernel, specifically those before version 6.11-rc2.
Is CVE-2024-43887 exploitable in any Linux distribution?
Yes, CVE-2024-43887 can be exploited in various Linux distributions that utilize affected kernel versions.
Are there any workarounds for CVE-2024-43887?
While patching is the recommended approach, temporarily limiting TCP connections may mitigate the risk until the kernel can be updated.