Skip to main content

Linux Kernel CVE-2026-53190

| EUVDEUVD-2026-39281 MEDIUM
2026-06-25 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-vc55-8273-pjx9
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local access inside a virtio-gpu VM with low privileges needed to trigger the fence error path; only availability impact from progressive memory leak.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 06, 2026 - 12:55 vuln.today
CVSS changed
Jul 06, 2026 - 12:52 NVD
5.5 (MEDIUM)
Patch available
Jun 25, 2026 - 10:32 EUVD
CVE Published
Jun 25, 2026 - 09:16 nvd
MEDIUM 5.5
CVE Published
Jun 25, 2026 - 09:16 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

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

drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait()

dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put().

When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each.

Add dma_fence_put(itr.chain) before the early return.

AnalysisAI

Reference-count leak in the Linux kernel's drm/virtio GPU driver allows a local low-privilege user inside a QEMU/KVM virtual machine to gradually exhaust kernel memory, causing a guest denial of service. The bug exists in virtio_gpu_dma_fence_wait(), where an early error return from inside dma_fence_unwrap_for_each() leaves a dma_fence reference acquired by dma_fence_unwrap_first() unreleased - the only such early-return site in the entire kernel tree. No public exploit is identified at time of analysis and EPSS sits at 0.18% (7th percentile), consistent with the absence from CISA KEV and the non-trivial conditions required to trigger repeated fence-wait failures.

Technical ContextAI

The drm/virtio driver implements GPU paravirtualization for QEMU/KVM guests using the virtio-gpu device. GPU synchronization is managed through the kernel's dma_fence API, which tracks completion of GPU commands via reference-counted fence objects. The macro dma_fence_unwrap_for_each() iterates over a fence chain; its internal helper dma_fence_unwrap_first() takes an extra reference on the chain pointer via dma_fence_get(). Under normal loop completion, dma_fence_unwrap_next() releases this reference through the dma_fence_chain_walk() → dma_fence_put() path. The defect, introduced at commit eba57fb5498f2858768321e64570caea188455b8 (Linux 6.5 era), is that when virtio_gpu_do_fence_wait() returns an error code mid-iteration, the function exits early without calling dma_fence_put(itr.chain), leaking one reference per failed invocation. No CWE is formally assigned by NVD, but the root cause class is CWE-401 (Missing Release of Memory Before Removing Last Reference) - a classic kernel driver error-path resource leak.

RemediationAI

Update the Linux kernel to a patched stable release corresponding to the deployed branch: 7.0.13, 6.18.36, 6.12.94, or 6.6.143, or any 7.1 final release. The minimal one-line fix (adding dma_fence_put(itr.chain) before the early return) is available in all five upstream stable commits referenced above at git.kernel.org/stable. For environments unable to patch promptly, the most actionable compensating control is to remove or disable the virtio-gpu device from the QEMU/KVM VM configuration, which eliminates the vulnerable code path entirely; note that this also disables guest GPU acceleration, which may be unacceptable for graphics or compute workloads. No other workarounds (network filtering, SELinux policy) are applicable given the local, driver-internal nature of the bug. Physical GPU deployments and non-virtio drivers are unaffected and require no action.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

CVE-2026-53190 vulnerability details – vuln.today

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