Loading story…
Researchers disclosed CVE-2024-36904, a seven-year-old race condition in the Linux kernel TCP subsystem that can lead to a real use-after-free involving TIME-WAIT sockets. The flaw was introduced by commit ec94c2696f0b, which changed inet_twsk_hashdance() so a socket could be inserted into the established hash table before its reference counter was initialized, allowing concurrent code in paths such as tcp_twsk_unique() and __inet_check_established() to observe a zero refcount and corrupt socket lifetime handling. The issue was first encountered while investigating a syzkaller report that appeared tied to KCM, but researchers determined it was unrelated and reproducible even with CONFIG_AF_KCM disabled.
Allele Security reproduced the bug on a RHEL-derived 5.14.0-362.24.2.el9_3.x86_64 kernel and on Fedora 39 6.8.6-200.fc39.x86_64, where it initially manifested as refcount warnings. The researchers said Linux refcount protections usually degrade such races into leaks, but in this case a later refcount_set() could overwrite the saturated value and create an unbalanced reference count, enabling premature free; with a modified KASAN-enabled research kernel, they obtained an actual use-after-free report in inet_twsk_put(). Upstream addressed the flaw in commit f2db7230f73a by changing tcp_twsk_unique() to use refcount_inc_not_zero() before taking a reference to the TIME-WAIT socket.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
Allele published a GitHub repository containing research artifacts for CVE-2024-36904, including the original and minimized syzkaller reproducers, a custom trigger, and a modified research kernel setup used to obtain a KASAN splat confirming a real use-after-free. The materials documented testing on AlmaLinux 9 and showed the modified kernel could trigger the KASAN splat in under 30 minutes.
An upstream Linux kernel commit titled "tcp: Use refcount_inc_not_zero() in tcp_twsk_unique()" added a conditional refcount_inc_not_zero() check and removed a later sock_hold() call. The change addressed the TIME-WAIT socket lifetime race associated with CVE-2024-36904.
A Linux kernel commit titled "tcp/dccp: avoid one atomic operation for timewait hashdance" moved time-wait socket refcount initialization until after releasing the bucket lock and changed the count from 4 to 3. This change introduced the race condition later tracked as CVE-2024-36904.
Allele Security published its analysis of CVE-2024-36904, describing a seven-year-old race condition in the Linux kernel TCP subsystem affecting time-wait sockets. The researchers said they had reported the issue upstream and explained how the bug could lead to a real use-after-free rather than only refcount warnings.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
6 references tracked. Mallory keeps watching after this page renders.
allelesecurity.com
Open sourcegithub.com
Open sourceallelesecurity.com
Open sourcegithub.com
Open sourcelore.kernel.org
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers detailed **CVE-2024-27394**, a Linux kernel use-after-free flaw in the TCP Authentication Option (**TCP-AO**) implementation, linking the bug to incorrect use of the kernel’s **Read-Copy Update (RCU)** synchronization model. The issue affects `tcp_ao_connect_init()` in `net/ipv4/tcp_ao.c`, where the kernel iterates over TCP-AO keys with an RCU list macro and schedules key reclamation with `call_rcu()` without remaining inside an RCU read-side critical section, creating a window in which a freed key can still be accessed. The analysis showed the bug can be prepared through `setsockopt(TCP_AO_ADD_KEY)` and triggered during `connect()` on IPv4 TCP sockets, with a proof of concept reportedly reproducing the fault on Linux kernel `6.8.4` under KASAN and `CONFIG_PREEMPT`. Researchers said the race can be made more reliable by forcing preemption with reschedule IPIs, widening the interval between reclamation and continued iteration. The fix replaces `hlist_for_each_entry_rcu` with `hlist_for_each_entry_safe` to prevent dereferencing a freed next node, and the patch was reported as merged in April and backported to stable kernels.
Jul 24, 2026
**CVE-2022-3566** is a race condition in the Linux kernel TCP subsystem involving concurrent access to `icsk->icsk_af_ops`. A low-privileged attacker with adjacent-network access could exploit the flaw to disclose internal kernel or Internet Protocol information and potentially affect system confidentiality, integrity, and availability. Red Hat rates the issue Moderate at CVSS 4.6, while the NVD score is 7.1. Red Hat released fixed kernel and real-time kernel packages for affected Red Hat Enterprise Linux 8 and 9 deployments, including RHEL 8.6 Extended Update Support and Red Hat Virtualization 4 on RHEL 8. RHEL 6 and 7 are outside support scope, and Red Hat identified no qualifying workaround; organizations should upgrade affected systems to supported fixed kernel packages. The issue reflects CWE-366, where unsynchronized concurrent access to shared resources can leave data or execution state invalid or unexpected.
Aug 26, 2026
A Linux kernel vulnerability in the TLS ULP subsystem can trigger a use-after-free in `tls_sk_proto_close()` when one thread closes a TLS socket while another concurrently calls `setsockopt(SOL_TLS, TLS_TX)`. The flaw stems from a race in TLS socket teardown and state manipulation, and the original reporter said a reproducer exists, though it was mistakenly included in a public `oss-security` posting despite an intention to withhold it until a fix was available. The issue was reportedly shared with `linux-distros` before a fix had been accepted upstream, with public disclosure occurring later on `oss-security`. Follow-up discussion on the mailing list pointed to taking `lock_sock(sk)` earlier in `tls_sk_proto_close()` as the most natural mitigation because the function already acquires that lock unconditionally. Reviewers said the bug may reflect a broader locking-order problem worth auditing in similar kernel paths, and the reporter said the proposed locking change would be raised with Linux kernel networking maintainers while a fix is discussed.
Jun 29, 2026