CVE-2026-63978

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

net/handshake: Drain pending requests at net namespace exit

The arguments to listspliceinit() in handshakenetexit() are

reversed. The call moves the local empty "requests" list onto

hn->hn_requests, leaving the local list empty, so the subsequent

drain loop runs zero iterations. Pending handshake requests that

had not yet been accepted are not torn down when the net namespace

is destroyed; each one keeps a reference on a socket file and on

the handshake_req allocation.

Pass the source and destination in the documented order

(listspliceinit(list, head) moves list onto head) so the pending

list is transferred to the local scratch list and drained through

handshake_complete().

Fixing the splice direction exposes a list-corruption race. After

the splice each req->hr_list still has non-empty link pointers,

threading the stack-local scratch list rather than hn_requests.

A concurrent handshakereqcancel() -- for example, from sunrpc's

TLS timeout on a kernel socket whose netns reference was not

taken -- finds the request through the rhashtable, calls

removepending(), and sees !listempty(&req->hr_list).

_removependinglocked() then listdel_init()s an entry off the

scratch list while the drain iterates, corrupting it. The same

call arriving after the drain loop has run list_del() on an

entry hits LIST_POISON instead.

Have removepending() check HANDSHAKEFNETDRAINING under

hn_lock and report not-found when drain is in progress. The

drain has already taken ownership; handshake_complete()'s existing

testandset on HANDSHAKEFREQ_COMPLETED still arbitrates

between drain and cancel for who calls the consumer's hp_done. Use

listdelinit() rather than listdel() in the drain so req->hrlist

does not carry LIST_POISON after drain releases the entry.

The DRAINING guard in remove_pending() makes cancel return false,

but cancel still falls through to testandset_bit on

HANDSHAKEFREQCOMPLETED and drops the request's hrfile reference.

Without another pin, if that is the last reference, sk_destruct frees

the request while it is still linked on the drain loop's local list.

Pin each request's hrfile under hnlock before releasing the list,

and drop that drain pin after the loop finishes with the request.