PT-2026-43882 · Linux · Linux

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-46015

CVSS v3.1

7.8

High

VectorAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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.

Fix

Related Identifiers

CVE-2026-46015

Affected Products

Linux