CyberSecBulletin
CVE-2026-63978NVD status: Analyzed

Linux: Concurrent Execution using Shared Resource with Improper Synchronization

Published Updated By the CyberSecBulletin desk

CVE-2026-63978 is a critical-severity concurrent execution using shared resource with improper synchronization vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions ee4b2ba9d30155f9945811cd3c0c1b06d45787a9, 9ec20c9a5a04f2c3f1cf65d21f886d7aaa6189cd, 2bf24a7e190aae0ea47c78099938ae056c622e44 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.49% chance of exploitation within 30 days, which is low compared with other CVEs.

Patch this week

Critical severity: a successful attack would have severe impact.

What to do

  1. Update Linux to ee4b2ba9d30155f9945811cd3c0c1b06d45787a9 or 9ec20c9a5a04f2c3f1cf65d21f886d7aaa6189cd or 2bf24a7e190aae0ea47c78099938ae056c622e44 or 8c35539db0ab0bfa1ea44efab00b053261a69469, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.6.160 or 6.12.93 or 6.18.44 or 7.0.12, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux3b3009ea8abb713b022d94fba95ec270cf6e7eae up to, but not including, ee4b2ba9d30155f9945811cd3c0c1b06d45787a9; 3b3009ea8abb713b022d94fba95ec270cf6e7eae up to, but not including, 9ec20c9a5a04f2c3f1cf65d21f886d7aaa6189cd; 3b3009ea8abb713b022d94fba95ec270cf6e7eae up to, but not including, 2bf24a7e190aae0ea47c78099938ae056c622e44; 3b3009ea8abb713b022d94fba95ec270cf6e7eae up to, but not including, 8c35539db0ab0bfa1ea44efab00b053261a69469; 3b3009ea8abb713b022d94fba95ec270cf6e7eae up to, but not including, ea5fe6a73ca57e5150b8a38b341aef2636eb72f0; 6.4ee4b2ba9d30155f9945811cd3c0c1b06d45787a9, 9ec20c9a5a04f2c3f1cf65d21f886d7aaa6189cd, 2bf24a7e190aae0ea47c78099938ae056c622e44, 8c35539db0ab0bfa1ea44efab00b053261a69469, ea5fe6a73ca57e5150b8a38b341aef2636eb72f0
LinuxLinux Kernel6.4 up to, but not including, 6.6.160; 6.7 up to, but not including, 6.12.93; 6.13 up to, but not including, 6.18.44; 6.19 up to, but not including, 7.0.12; 7.16.6.160, 6.12.93, 6.18.44, 7.0.12

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Concurrent Execution using Shared Resource with Improper Synchronization

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

How developers prevent this class of flaw

  • In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
  • Use thread-safe capabilities such as the data access abstraction in Spring.
  • Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

More Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities (CWE-362)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities

Spotted an error? Tell us.