CVE-2026-46015

What it actually does

This is a Linux kernel networking flaw in the TCP listener migration path for SO_REUSEPORT sockets. When an established child socket is migrated from a closing listener to another listener in the same reuseport group, the kernel can fail to wake blocking accept(), poll(), or epoll_wait() waiters, causing listener threads to sleep despite queued connections. The fix also addresses a race where the migrated request can be accepted or torn down on another CPU while the migration path still dereferences the target listener, creating a potential use-after-free condition. Because the issue is in kernel-space socket handling, successful exploitation could affect confidentiality, integrity, and availability of the host, but the CVSS vector indicates an attacker needs local, low-privileged access.

Why it matters to the business

An attacker with local access to a Linux system may be able to trigger kernel instability or potentially gain elevated control by exploiting a race in TCP socket handling. Operationally, affected systems could experience service hangs, missed incoming connections, kernel crashes, or broader compromise if the memory-safety aspect is weaponized. This is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad exploitation is not indicated, but internet-facing or multi-tenant Linux systems that allow untrusted local code should still prioritize kernel updates.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user on a vulnerable Linux host. They create TCP listeners using SO_REUSEPORT and arrange for established child sockets to be migrated while one listener is being closed. By racing listener shutdown, accept handling, and reuseport migration across CPUs, the attacker attempts to hit the window where the kernel queues a migrated request to a target listener but later dereferences that listener after its reference may already have been dropped. At minimum, this can produce service-level denial of service behavior where blocking accept or epoll-based workers fail to wake for queued connections. If the use-after-free race is reliably controlled, an attacker may attempt kernel memory corruption techniques to crash the system or escalate privileges.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for the TCP listener migration path, specifically the change that calls sk_data_ready() after successful listener migration and protects post-migration target listener dereferences with RCU locking. No exact fixed package versions were provided in the input, so use the security advisory from the relevant Linux distribution or kernel vendor to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by restricting local shell/container access, limiting the ability of untrusted workloads to create arbitrary network listeners, isolating multi-tenant workloads, and using hardened kernel configurations. Reboot into the patched kernel after installation; installing a kernel package alone is insufficient if the running kernel is not replaced.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, is a vendor-fixed build using commands such as uname -r and the distribution package manager’s kernel advisory metadata. Review the vendor changelog or backport notes for references to TCP SO_REUSEPORT listener migration, inet_csk_listen_stop(), sk_data_ready(), or the relevant CVE. Validate operationally by ensuring services using SO_REUSEPORT accept new connections normally after listener restarts and do not leave epoll or blocking accept workers asleep with queued connections. For high-assurance validation, use a staging system with the patched kernel and regression tests that exercise listener shutdown and connection migration under load.

Typical attack path

1. Gain low-privileged local code execution on a vulnerable Linux host.
2. Create TCP sockets using SO_REUSEPORT so multiple listeners share the same port.
3. Establish or cause TCP connections that create child sockets eligible for listener migration.
4. Trigger shutdown of one listener while another listener in the reuseport group remains active.
5. Race accept(), listener shutdown, and migration activity across threads or CPUs.
6. Attempt to cause missed wakeups, service hangs, kernel warnings, crashes, or use-after-free behavior.
7. If exploitation is reliable, use kernel memory corruption primitives to attempt privilege escalation or system compromise.

How to detect it

Look for evidence of local kernel exploitation attempts or instability rather than remote network-only indicators. Useful log sources include kernel logs, system journal, crash dumps, hypervisor reset events, EDR telemetry for local proof-of-concept execution, and service logs for applications using SO_REUSEPORT. Search for kernel warnings, KASAN reports, RCU warnings, general protection faults, NULL pointer dereferences, or panics referencing TCP listener migration functions such as inet_csk_listen_stop(), reuseport_migrate_sock(), inet_csk_reqsk_queue_add(), reqsk_put(), or sk_data_ready(). Also investigate unexplained service hangs where blocking accept(), poll(), or epoll_wait() workers stop accepting new connections while the process remains running. Because no public exploit indicators were provided and this is a kernel race condition, absence of these artifacts does not prove absence of exploitation.

• BUG: KASAN: use-after-free
• use-after-free in inet_csk_listen_stop
• inet_csk_listen_stop
• reuseport_migrate_sock
• inet_csk_reqsk_queue_add
• reqsk_put
• sk_data_ready
• general protection fault
• kernel panic
• RCU detected stall
• WARNING: suspicious RCU usage
• epoll_wait
• accept()

What your security team should do

• Inventory Linux systems, especially multi-tenant servers, container hosts, CI runners, developer workstations, and systems where untrusted users can run local code.
• Prioritize patching systems that allow local user access, run untrusted containers, or host network services using SO_REUSEPORT.
• Upgrade to a vendor-fixed kernel and reboot to ensure the patched kernel is active.
• Monitor for kernel crash, KASAN, refcount, RCU, and general protection fault messages involving TCP listener migration functions.
• Treat unexpected kernel panics or networking hangs on affected kernels as potentially security-relevant until investigated.
• If patching is delayed, reduce local attack surface by limiting untrusted shell access, tightening container isolation, and restricting workload privileges such as CAP_NET_ADMIN where practical.
• Track distribution advisories because fixed versions may be delivered as backports without changing to an obvious upstream kernel version.