CVE-2026-46015High· 7.8▾ TwilightIn the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the sa…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 42.9 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 8.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.1%
In the Linux kernel, the following vulnerability has been resolved:
tcp: call sk_data_ready() after listener migration
When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely.
Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop().
However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path.
The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.
linux_kernel >= 5.14, < 5.15.209linux_kernel >= 5.16, < 6.1.175linux_kernel >= 6.2, < 6.6.140linux_kernel >= 6.7, < 6.12.86linux_kernel >= 6.13, < 6.18.27linux_kernel >= 6.19, < 7.0.4Upgrade past the affected range:
linux_kernel 7.0.4Connected by shared product, vendor, weakness, or advisory.
CVE-2023-4611High· 7.0A use-after-free flaw was found in mm/mempolicy.c in the memory management subsystem in the Linux Kernel
CVE-2026-64373Medium· 4.7In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path
CVE-2026-53352Medium· 4.7In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_…
CVE-2026-23466High· 7.8In the Linux kernel, the following vulnerability has been resolved: drm/xe: Open-code GGTT MMIO access protection GGTT MMIO access is currently protected by hotplug (drm_dev_enter), which works correctly when the driver loads successfu…
CVE-2026-53219Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to us…
CVE-2026-93159Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchro…