CVE-2024-43887 in Linuxinfo

Summary

by MITRE • 08/26/2024

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 static_key is the same as the last tcp_ao_info. On the socket destruction tcp_ao_info ceases to be with RCU grace period, while tcp-ao static branch is currently deferred destructed. The static key definition is : DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ);

which means that if RCU grace period is delayed by more than a second and tcp_ao_needed is in the process of disablement, other CPUs may yet see tcp_ao_info which atent dead, but soon-to-be. And that breaks the assumption of static_key_fast_inc_not_disabled().

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 ("jump_label: 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. static_key_fast_inc_not_disabled() 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 jump_label_mutex and as a result, races with jump_label_update() implementation details.

Happened on netdev test-bot[1], so not a theoretical issue:

[] jump_label: Fatal kernel bug, unexpected op at tcp_inbound_hash+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/jump_label.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 jump_label_update_timeout
[] RIP: 0010:__jump_label_patch+0x2f6/0x350
... [] Call Trace:
[]
[] arch_jump_label_transform_queue+0x6c/0x110
[] __jump_label_update+0xef/0x350
[] __static_key_slow_dec_cpuslocked.part.0+0x3c/0x60
[] jump_label_update_timeout+0x2c/0x40
[] process_one_work+0xe3b/0x1670
[] worker_thread+0x587/0xce0
[] kthread+0x28a/0x350
[] ret_from_fork+0x31/0x70
[] ret_from_fork_asm+0x1a/0x30
[]
[] Modules linked in: veth
[] ---[ end trace 0000000000000000 ]---
[] RIP: 0010:__jump_label_patch+0x2f6/0x350

[1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/696681/5-connect-deny-ipv6/stderr

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 09/29/2025

The vulnerability described in CVE-2024-43887 resides within the Linux kernel's implementation of the TCP-AO (Authenticated Offload) protocol, specifically concerning the management of static keys during the lifecycle of TCP connections. This issue manifests as a race condition that can lead to kernel crashes and undefined behavior due to improper handling of the tcp_ao_needed static key. The problem occurs when a socket is destroyed and the associated tcp_ao_info structure is scheduled for removal through an RCU grace period, while the static key itself remains in a transitional state. The static key definition uses DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ) which means that if the grace period extends beyond one second, the key may still appear enabled to other CPU cores even though the underlying tcp_ao_info data is effectively dead and soon-to-be destroyed. This creates a scenario where static_key_fast_inc_not_disabled() is invoked on a key that could potentially be disabled in parallel, violating fundamental assumptions about static key usage patterns. The vulnerability is particularly concerning because it operates at the kernel level and can cause immediate system instability through kernel BUG traps and invalid opcode exceptions.

The technical flaw stems from a mismatch between the RCU grace period semantics and the static key management mechanism in the TCP-AO implementation. When a socket is destroyed, the tcp_ao_info structure is freed after an RCU grace period, but the static key tcp_ao_needed is not immediately disabled. This creates a temporal window where the static key still reports as enabled while the underlying data structures are being torn down. The static_key_fast_inc_not_disabled() function was designed for atomic contexts where the key's existence is guaranteed to be stable, such as during socket creation from request sockets. However, in this scenario, the function is used in a context where the key could be disabled concurrently, leading to memory corruption and invalid instruction execution. The kernel's jump_label subsystem, which handles dynamic patching of code paths, fails when encountering this inconsistent state, as evidenced by the fatal kernel bug with unexpected operation at tcp_inbound_hash function. This represents a classic race condition between the RCU destruction path and the static key usage path, where the lack of proper synchronization leads to invalid memory access patterns.

The operational impact of this vulnerability is severe and can result in immediate system crashes, kernel panics, and complete system instability. The issue manifests as kernel BUG traps, invalid opcode exceptions, and memory corruption errors that occur during normal network operations involving TCP-AO connections. The vulnerability is not theoretical but has been observed in real-world testing environments such as the netdev test-bot, where the kernel crashes with specific error patterns indicating jump_label subsystem failures. The crash occurs in the __jump_label_patch function when it encounters unexpected instruction patterns, indicating that the jump label system has been corrupted by the race condition. This vulnerability affects systems running Linux kernel versions that include the TCP-AO implementation and can be exploited by attackers who can trigger socket destruction scenarios, potentially leading to denial of service conditions or system crashes. The impact extends beyond simple service interruption as it represents a fundamental flaw in the kernel's static key management that could compromise system integrity.

Mitigation strategies for CVE-2024-43887 require immediate kernel updates to address the race condition in TCP-AO static key management. The most effective approach is to apply the official kernel patch that resolves the synchronization issue between RCU grace periods and static key operations, ensuring that static keys are properly disabled before underlying data structures are freed. Organizations should prioritize updating their Linux kernel versions to include the fix, particularly those running systems with TCP-AO enabled or those that may be subjected to network traffic involving authenticated connections. System administrators should monitor for kernel crash reports and ensure that all network services are updated to prevent exploitation of this vulnerability. Additional mitigations include implementing proper network monitoring to detect unusual socket destruction patterns and ensuring that systems are not subjected to high-frequency socket creation and destruction scenarios that could trigger the race condition. The vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and maps to ATT&CK technique T1499.004 (Endpoint Denial of Service) as it can be leveraged to cause system instability and denial of service through carefully crafted network traffic patterns that trigger the vulnerable code path.

Responsible

Linux

Reservation

08/17/2024

Disclosure

08/26/2024

Moderation

accepted

CPE

ready

EPSS

0.00189

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!