CVE-2026-46015: tcp: call sk_data_ready() after listener migration

In the Linux kernel, the following vulnerability has been resolved:

tcp: call skdataready() after listener migration

When inetcsklistenstop() migrates an established child socket from a closing listener to another socket in the same SOREUSEPORT group, the target listener gets a new accept-queue entry via inetcskreqskqueueadd(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epollwait() waiters and blocking accept() callers can also remain asleep indefinitely.

Call READONCE(nsk->skdataready)(nsk) after a successful migration in inetcsklistenstop().

However, after inetcskreqskqueueadd() succeeds, the ref acquired in reuseportmigratesock() is effectively transferred to nreq->rsklistener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqskput(), and drop that listener ref. Since listeners are SOCKRCUFREE, wrap the post-queueadd() dereferences of nsk in rcureadlock()/rcureadunlock(), which also covers the existing socknet(nsk) access in that path.

The reqsktimerhandler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcpchildprocess() already wakes the listener; and once nreq is visible via inetehashinsert(), the success path no longer touches nsk directly.