In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to… (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 list_splice_init() in handshake_net_exit() 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 (list_splice_init(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 handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_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 remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list 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 test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file 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 hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel relates to the net/handshake code where the arguments to list_splice_init() in handshake_net_exit() were reversed. This caused the local 'requests' list to be moved incorrectly, leaving pending handshake requests unprocessed when a network namespace is destroyed. These requests retained references to socket files and handshake_req allocations, causing resource leaks. Fixing the splice direction introduced a race condition with list corruption during concurrent cancel operations. The patch added a draining guard under a lock to prevent concurrent removal, used list_del_init() to avoid LIST_POISON issues, and pinned socket file references during draining to prevent premature freeing. This resolves the improper cleanup of handshake requests and prevents list corruption races.
Potential Impact
Pending handshake requests that were not accepted could remain allocated and keep references to socket files when a network namespace is destroyed, leading to resource leaks. Additionally, a race condition could cause list corruption during concurrent cancellation of handshake requests, potentially destabilizing kernel data structures related to network handshakes.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to correct the list splice operation and add synchronization to prevent list corruption races. Users should apply the official kernel update that includes this patch. Since no specific patch links or vendor advisories are provided, check the Linux kernel's official repositories or security advisories for the fixed version and apply updates accordingly. No alternative mitigations are indicated.
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to… (CVE-2026-63978)
Description
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() 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 (list_splice_init(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 handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_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 remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list 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 test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file 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 hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel relates to the net/handshake code where the arguments to list_splice_init() in handshake_net_exit() were reversed. This caused the local 'requests' list to be moved incorrectly, leaving pending handshake requests unprocessed when a network namespace is destroyed. These requests retained references to socket files and handshake_req allocations, causing resource leaks. Fixing the splice direction introduced a race condition with list corruption during concurrent cancel operations. The patch added a draining guard under a lock to prevent concurrent removal, used list_del_init() to avoid LIST_POISON issues, and pinned socket file references during draining to prevent premature freeing. This resolves the improper cleanup of handshake requests and prevents list corruption races.
Potential Impact
Pending handshake requests that were not accepted could remain allocated and keep references to socket files when a network namespace is destroyed, leading to resource leaks. Additionally, a race condition could cause list corruption during concurrent cancellation of handshake requests, potentially destabilizing kernel data structures related to network handshakes.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to correct the list splice operation and add synchronization to prevent list corruption races. Users should apply the official kernel update that includes this patch. Since no specific patch links or vendor advisories are provided, check the Linux kernel's official repositories or security advisories for the fixed version and apply updates accordingly. No alternative mitigations are indicated.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-2g7m-7wmg-84j3
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63978"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27aa2a4a8d598912e54c
Added to database: 07/19/2026, 19:38:18 UTC
Last enriched: 07/19/2026, 20:03:26 UTC
Last updated: 07/20/2026, 21:52:03 UTC
Views: 10
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.