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.

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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.
    (CVE-2026-63978)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
340681	Ubuntu 24.04 LTS / 26.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-8663-1)	Nessus	Ubuntu Local Security Checks	Local	high
340045	Ubuntu 26.04 LTS : Linux kernel (NVIDIA BaseOS) vulnerabilities (USN-8664-1)	Nessus	Ubuntu Local Security Checks	Local	high
333762	Photon OS 5.0: Linux PHSA-2026-5.0-92-0895	Nessus	PhotonOS Local Security Checks	Local	high
328493	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-1968)	Nessus	Amazon Linux Local Security Checks	Local	high
328224	Linux Distros Unpatched Vulnerability : CVE-2026-63978	Nessus	Misc.	Local	critical
322944	Photon OS 5.0: Linux PHSA-2026-5.0-0895	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2026-63978

critical

Tenable Plugins

high

high

high

high

critical

high