Skip to main content

Linux Kernel EUVDEUVD-2026-64551

| CVE-2026-74614 HIGH
2026-08-22 Linux GHSA-m75m-8448-cc2j
8.4
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
8.4 HIGH
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Race condition requires precise suspend/resume timing (AC:H), and local vsock socket access implies at minimum low privilege (PR:L), not unauthenticated.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 25, 2026 - 06:40 vuln.today
CVSS changed
Aug 25, 2026 - 06:22 NVD
8.4 (HIGH)
Patch available
Aug 22, 2026 - 16:32 EUVD
CVE Published
Aug 22, 2026 - 15:31 cve.org
HIGH 8.4
CVE Published
Aug 22, 2026 - 15:31 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: read virtqueues under worker locks

Commit bd50c5dc182b ("vsock/virtio: add support for device suspend/resume") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue.

Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.

AnalysisAI

Use-after-free memory corruption in the Linux kernel vsock/virtio subsystem arises from a race condition between virtqueue worker threads and VM suspend/resume cycles. Worker threads (RX, TX, event) read their virtqueue pointer before acquiring the protective mutex and checking the run flag; a worker delayed across a freeze/restore transition retains a dangling pointer to a freed queue while the restoration installs replacement queues. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Recon
Establish active vsock connections in guest VM
Delivery
Hypervisor initiates VM suspend/resume cycle
Exploit
Worker thread preempted across freeze/restore boundary
Install
Worker retains stale pointer to freed virtqueue
C2
Use-after-free access triggers memory corruption
Execute
Kernel memory read/write primitive achieved
Impact
Privilege escalation or kernel crash

Vulnerability AssessmentAI

Exploitation Exploitation requires: (1) the vmw_vsock_virtio_transport kernel module loaded and active, meaning vsock over virtio is in use - not the VMCI transport; (2) active vsock worker threads processing RX, TX, or event data at the moment a VM suspend/resume cycle occurs; (3) a worker thread that is delayed (preempted or sleeping) precisely across the freeze/restore boundary, retaining a stale virtqueue pointer. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment The CVSS 8.4 score reflects worst-case kernel-level impact (C:H/I:H/A:H), but real-world exploitability is substantially constrained by the narrow race window - deliberate triggering requires a worker thread to be delayed precisely across a hypervisor-controlled suspend/resume cycle while actively processing vsock traffic, a timing condition that is difficult to orchestrate reliably from within a guest VM. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario A local attacker or malicious process within a VM with active vsock connections waits for or coincides with a hypervisor-initiated suspend/resume cycle. During the narrow window between virtqueue teardown and replacement, a delayed worker thread accesses the freed virtqueue through a dangling pointer, leading to use-after-free memory corruption that could be leveraged for kernel memory reads, writes, or a denial-of-service crash. …
Remediation Apply the vendor-released kernel patch for the appropriate stable branch - fixed versions are 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, and 7.2, available via the Linux stable kernel tree at git.kernel.org (see commit references: 941329ce14c5, 29dd10583bf9, a1fb0c5b8a7c, eae099c764c7, bd43a7ec668b, 1cecb4202afd, ebac8f6b1ef0). … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours, inventory all Linux hypervisors and VMs using vsock/virtio and verify patch availability through your vendor (RHEL, Ubuntu, CentOS, etc.). …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

Share

EUVD-2026-64551 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy