CVE-2026-46015

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: call sk_data_ready() after listener migration<br /> <br /> When inet_csk_listen_stop() migrates an established child socket from<br /> a closing listener to another socket in the same SO_REUSEPORT group,<br /> the target listener gets a new accept-queue entry via<br /> inet_csk_reqsk_queue_add(), but that path never notifies the target<br /> listener&amp;#39;s waiters. A nonblocking accept() still works because it<br /> checks the queue directly, but poll()/epoll_wait() waiters and<br /> blocking accept() callers can also remain asleep indefinitely.<br /> <br /> Call READ_ONCE(nsk-&gt;sk_data_ready)(nsk) after a successful migration<br /> in inet_csk_listen_stop().<br /> <br /> However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired<br /> in reuseport_migrate_sock() is effectively transferred to<br /> nreq-&gt;rsk_listener. Another CPU can then dequeue nreq via accept()<br /> or listener shutdown, hit reqsk_put(), and drop that listener ref.<br /> Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()<br /> dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also<br /> covers the existing sock_net(nsk) access in that path.<br /> <br /> The reqsk_timer_handler() path does not need the same changes for two<br /> reasons: half-open requests become readable only after the final ACK,<br /> where tcp_child_process() already wakes the listener; and once nreq is<br /> visible via inet_ehash_insert(), the success path no longer touches<br /> nsk directly.