CVE-2026-63978

Source
https://cve.org/CVERecord?id=CVE-2026-63978
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-63978.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-63978
Downstream
Published
2026-07-19T14:56:02.484Z
Modified
2026-07-21T03:47:45.441352053Z
Severity
  • 9.8 (Critical) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
Summary
net/handshake: Drain pending requests at net namespace exit
Details

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->hnrequests, 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 handshakereq 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->hrlist still has non-empty link pointers, threading the stack-local scratch list rather than hnrequests. 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 listdelinit()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run listdel() on an entry hits LISTPOISON instead.

Have removepending() check HANDSHAKEFNETDRAINING under hnlock and report not-found when drain is in progress. The drain has already taken ownership; handshakecomplete()'s existing testandset on HANDSHAKEFREQCOMPLETED still arbitrates between drain and cancel for who calls the consumer's hpdone. 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 removepending() makes cancel return false, but cancel still falls through to testandsetbit on HANDSHAKEFREQCOMPLETED and drops the request's hrfile reference. Without another pin, if that is the last reference, skdestruct frees the request while it is still linked on the drain loop's local list. Pin each request's hrfile under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/63xxx/CVE-2026-63978.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
3b3009ea8abb713b022d94fba95ec270cf6e7eae
Fixed
9ec20c9a5a04f2c3f1cf65d21f886d7aaa6189cd
Fixed
8c35539db0ab0bfa1ea44efab00b053261a69469
Fixed
ea5fe6a73ca57e5150b8a38b341aef2636eb72f0

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-63978.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.4.0
Fixed
6.12.93
Type
ECOSYSTEM
Events
Introduced
6.13.0
Fixed
7.0.12

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-63978.json"