# CVE-2026-63978: net/handshake: Drain pending requests at net namespace exit

> A race condition in the Linux kernel's handshake subsystem can cause list corruption and memory leaks during network namespace exit, potentially leading to denial of service.

- **Severity:** Critical 9.8 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 19 Jul 2026
- **Updated:** 21 Oct 2026
- **Also known as:** AZL-92820, BELL-CVE-2026-63978, DEBIAN-CVE-2026-63978, GHSA-2g7m-7wmg-84j3, UBUNTU-CVE-2026-63978

## What is CVE-2026-63978?

CVE-2026-63978 is a critical vulnerability in Linux, published on 19 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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.

Weakness: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)

## Which versions are affected by CVE-2026-63978?


## How do I fix CVE-2026-63978?

Apply the vendor's patch.

## Is CVE-2026-63978 being exploited?

There is no known exploitation of CVE-2026-63978 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-63978 and fix it if it is affected.

What it is: CVE-2026-63978 is a critical vulnerability in Linux, published on 19 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-63978 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-63978/ (Markdown: https://insights.sbomify.com/CVE-2026-63978/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-63978
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-63978
- OSV: https://osv.dev/vulnerability/CVE-2026-63978

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-63978/
Summaries are generated and may contain mistakes; the official description above is the record.