CVE-2024-50154 is a high-severity use-after-free (UAF) vulnerability in the Linux kernel's TCP/DCCP networking stack, specifically related to the handling of timers in the reqsk_queue_unlink() function. The root cause stems from improper use of the timer_pending() function within reqsk_queue_unlink(), which was introduced in commit 83fccfc3940c to avoid deadlocks by preventing del_timer_sync() calls from reqsk_timer_handler(). However, this introduced a race condition where the timer_pending() check could miss a timer that was just detached by expire_timers(), leading to the reqsk timer continuing to run and retransmit SYN+ACK packets multiple times until expiration (default 63 seconds). The vulnerability manifests when a socket (req->sk) is closed before the timer expires. The sequence involves inet_csk_complete_hashdance() calling inet_csk_reqsk_queue_drop() but missing del_timer_sync(), allowing the reqsk timer to execute and reschedule. Meanwhile, the socket is accepted and closed, but the timer still holds a reference. When the timer executes again, it accesses the freed socket memory, resulting in a use-after-free condition. This UAF can be triggered by BPF programs attached to trace_tcp_retransmit_synack, which access req->sk via bpf_sk_storage_get_tracing(). The vulnerability is subtle because the reqsk timer is pinned, so it does not occur in most use cases, but the race window exists. Exploitation could lead to arbitrary kernel memory access, potentially allowing privilege escalation, denial of service, or information disclosure. The CVSS 3.1 score is 7.8 (high), reflecting local access with low complexity, requiring privileges but no user interaction, and impacting confidentiality, integrity, and availability. No known exploits are reported in the wild yet. The vulnerability affects Linux kernel versions containing the problematic commit hashes listed, requiring patching to avoid exploitation.

For European organizations, this vulnerability poses a significant risk especially to those running Linux-based infrastructure, including servers, network appliances, and cloud environments. The vulnerability could be exploited by a local attacker or a malicious process with limited privileges to cause kernel memory corruption, leading to privilege escalation or system crashes. This can disrupt critical services, compromise sensitive data, or allow attackers to gain persistent control over affected systems. Given the widespread use of Linux in European data centers, telecommunications, financial institutions, and government agencies, the impact could be broad. Systems running custom or older kernels that have not yet integrated the fix are particularly vulnerable. The use of BPF programs in observability or security tooling could inadvertently increase exposure. Additionally, denial of service attacks exploiting this flaw could affect availability of critical infrastructure. The vulnerability's exploitation complexity is low for privileged users, making insider threats or compromised accounts a concern. Overall, the vulnerability threatens confidentiality, integrity, and availability of Linux-based systems across Europe.

1. Immediate patching: Apply the official Linux kernel patches that remove the use of timer_pending() in reqsk_queue_unlink() and fix the race condition as described. Monitor kernel mailing lists and vendor advisories for updated stable kernel releases containing the fix. 2. Kernel version management: Maintain an inventory of Linux kernel versions in use and prioritize upgrades or backported patches for affected versions. 3. Restrict local access: Limit local user privileges to prevent untrusted users from loading or attaching BPF programs or triggering the vulnerable code paths. 4. Harden BPF usage: Audit and control BPF program deployment, especially those attached to tcp retransmit tracing, to reduce attack surface. 5. Monitor for anomalies: Implement kernel-level monitoring and logging to detect unusual timer behavior or repeated SYN+ACK retransmissions that could indicate exploitation attempts. 6. Use security modules: Employ Linux Security Modules (e.g., SELinux, AppArmor) to confine processes and reduce the impact of potential exploitation. 7. Incident response readiness: Prepare to respond to potential exploitation incidents with forensic capabilities to analyze kernel memory and logs. 8. Vendor coordination: Work with Linux distribution vendors for timely patch availability and guidance.