CVE-2026-53260

What it actually does

This is a Linux kernel race condition in the TCP request-socket path on kernels using PREEMPT_RT or full real-time preemption. In reqsk_queue_hash_req(), a request socket timer can be armed with mod_timer() before the request socket reference count is initialized with refcount_set(). If the task is preempted in that window and the timer fires while the listener is being closed, the timer path can drop references that were never correctly established, producing a request-socket reference-count underflow and a potential use-after-free in the TCP connection setup path. The most likely technical outcomes are kernel warnings, instability, denial of service, or memory-corruption side effects in affected kernel builds.

Why it matters to the business

Systems running affected Linux kernels, especially real-time or PREEMPT_RT-enabled builds, may become unstable or crash when exposed to specific TCP connection timing conditions. For organizations using Linux for latency-sensitive workloads, industrial systems, telecom, embedded platforms, or high-availability services, this can translate into service interruption, node reboots, degraded reliability, and operational downtime. The available risk signals are currently lower urgency: EPSS is low at 0.00369, the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no exploit maturity is reported; however, kernel flaws should still be remediated through normal patch cycles because impact can be severe if reachable conditions exist.

How an attack unfolds

An attacker would need to trigger a narrow timing window in the TCP connection request lifecycle on an affected kernel. The vulnerable sequence occurs when the kernel creates and hashes a TCP request socket, arms its timer, and is preempted before initializing the expected reference count. If the request timer runs during that gap and the associated listening socket is closing, the kernel may process the request socket as though references exist and then decrement them, causing an underflow and use-after-free warning. In practical terms, exploitation would likely require repeated TCP connection attempts against a listening service while the listener is being stopped, restarted, or closed, plus a kernel configuration that allows the relevant preemption behavior. There is no evidence from the supplied data of weaponized exploitation, named threat actor activity, or ransomware use.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the fix adding preempt_disable_nested() and preempt_enable_nested() around the timer arming and reference-count initialization sequence in reqsk_queue_hash_req(). Because no exact fixed versions were provided, use the relevant distribution, appliance, cloud image, embedded BSP, or kernel vendor advisory to identify the corrected package. Prioritize real-time kernel variants, PREEMPT_RT deployments, internet-facing TCP services, and systems where service restarts occur frequently. If immediate patching is not possible, reduce exposure by limiting network access to TCP services, minimizing unnecessary listener restarts, applying host firewalls or network ACLs, and using redundancy to reduce outage impact. Mitigations do not remove the underlying kernel flaw; patching is the durable fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that contains the upstream TCP request-socket preemption fix. Validate both the installed package version and the active booted kernel version, because kernel updates often require a reboot. On Linux systems, compare uname -a and package-manager output against vendor advisories. Review kernel configuration for PREEMPT_RT or full preemption to determine exposure relevance. After patching and rebooting, monitor dmesg, journald, syslog, and kernel crash logs for recurrence of request-socket reference-count underflow messages under TCP connection and service-restart testing. Where feasible, run controlled regression testing that repeatedly starts/stops a listening TCP service while generating connection attempts, and confirm no refcount underflow, use-after-free warning, soft lockup, or kernel oops is observed.

Typical attack path

1. Identify a Linux system running an affected PREEMPT_RT or full-preemption kernel with an exposed TCP listening service.
2. Generate repeated TCP connection attempts or half-open connection activity toward the listening service.
3. Attempt to align traffic with listener shutdown, restart, or close events so request-socket timers can fire during connection setup.
4. Trigger the race window after mod_timer() but before refcount_set() in the TCP request-socket path.
5. Cause request-socket reference-count underflow, potentially resulting in kernel warnings, instability, crash, or other memory-corruption effects.

How to detect it

To determine whether the condition has already occurred, review kernel logs rather than application logs. Search dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, pstore, netconsole output, and centralized SIEM telemetry for refcount underflow, use-after-free, request-socket, and TCP timer-handler warnings. Relevant artifacts include stack traces mentioning refcount_warn_saturate, reqsk_put, __inet_csk_reqsk_queue_drop, reqsk_timer_handler, inet_connection_sock.c, ktimers, or PREEMPT_RT. Correlate any matching kernel warnings with bursts of TCP connection attempts, SYN floods or connection churn, and service stop/start/restart events for listening daemons. Detection cannot reliably prove malicious exploitation from logs alone because the same race may be triggered accidentally under stress or service churn; treat matches as evidence of exposure and possible triggering, then preserve kernel logs and crash dumps for analysis.

• refcount_t: underflow; use-after-free.
• refcount_warn_saturate
• __inet_csk_reqsk_queue_drop
• reqsk_timer_handler
• reqsk_put
• reqsk->rsk_refcnt underflow
• net/ipv4/inet_connection_sock.c
• ktimers/
• PREEMPT_RT
• PREEMPT_{RT,(full)}
• WARNING: lib/refcount.c
• request_sock.h
• inet_connection_sock.c:1007
• inet_connection_sock.c:1137

What your security team should do

• Inventory Linux systems running real-time, PREEMPT_RT, or full-preemption kernels and map exposed TCP listening services on those systems.
• Track vendor advisories and kernel package updates for this vulnerability, and schedule patching according to normal kernel remediation procedures, with higher priority for internet-facing or mission-critical systems.
• Verify that patched kernels are actually booted after maintenance; do not rely only on package installation status.
• Increase monitoring for kernel warnings, oopses, panics, and refcount underflow messages on systems that cannot be patched immediately.
• Restrict untrusted network access to affected TCP services using firewalls, security groups, ACLs, or service-level access controls until patched.
• Review service restart automation and high-frequency listener churn on affected systems, because listener close events are part of the vulnerable timing scenario.
• Because this is not KEV-listed, not ransomware-associated, and has low EPSS, avoid emergency disruption unless the affected systems are critical or exposed; nevertheless, include it in the next kernel patch cycle.