Skip to main content

Linux Kernel CVE-2026-68240

| EUVDEUVD-2026-55341 HIGH
2026-08-10 Linux GHSA-hg58-rvxm-hmcv
High
Disputed · 8.8 Vendor: Linux
Share

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

AC:H assigned because triggering the error path requires allow_mixed=false plus a mid-batch EOPNOTSUPP - not a trivially reproducible condition - versus NVD's AC:L.

3.1 AV:L/AC:H/PR:L/UI:N/S:C/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:H/SI:H/SA:H
SUSE
2.5 LOW
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
Red Hat
5.5 LOW
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 03:29 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
8.8 (HIGH)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 12:01 cve.org
HIGH 8.8
CVE Published
Aug 10, 2026 - 12:01 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

drm/gpusvm: publish dpagemap early to avoid device mapping leak on error

drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created.

Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings.

This issue was found by Sashiko AI review.

AnalysisAI

GPU Shared Virtual Memory (SVM) page mapping in the Linux kernel's drm/gpusvm subsystem leaks device mappings when a partial page-acquisition operation fails mid-sequence, leaving IOMMU-level mappings orphaned and unrecoverable through the normal cleanup path. Local users with GPU access on affected kernels - ranging from the introduction of drm/gpusvm through Linux 6.18 and 7.1 stable series - can trigger the condition by causing a later page in a batch to fail with -EOPNOTSUPP when ctx->allow_mixed is false, bypassing device_unmap() in __drm_gpusvm_unmap_pages(). No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog, though NVD assigns a CVSS of 8.8 due to potential changed-scope impact on GPU/IOMMU mappings.

Technical ContextAI

The drm/gpusvm subsystem in the Linux kernel DRM framework manages Shared Virtual Memory for discrete GPU drivers (such as Intel xe), enabling unified CPU-GPU address spaces backed by device page tables and IOMMU mappings. The function drm_gpusvm_get_pages() iterates over a range of pages and maps each to a device. The first successful device mapping stores a dpagemap reference locally but - before the fix - did not commit it to svm_pages->dpagemap until the entire operation succeeded. If any subsequent page in the batch failed (concretely, -EOPNOTSUPP when ctx->allow_mixed is false, preventing mixed device/system page types in a single SVM region), the code jumped to the err_unmap label. At that point, svm_pages->dpagemap was still NULL, causing __drm_gpusvm_unmap_pages() to skip device_unmap() entirely, leaving the already-mapped device pages permanently orphaned in the GPU page table. While NVD lists CWE as N/A, this is structurally a CWE-459 (Incomplete Cleanup) or CWE-772 (Missing Release of Resource after Effective Lifetime) pattern - the resource (IOMMU/device mapping) is allocated but not freed on the error path because a prerequisite pointer was never set.

RemediationAI

Upgrade to a patched Linux kernel: version 6.18.44, 7.1.6, or 7.2-rc4 or later, which incorporate the fix commits available at https://git.kernel.org/stable/c/e8362523fd1b61712f7d996802f9b5dee545c7e6, https://git.kernel.org/stable/c/72e4fca5529e45b5beebad79d804de442f632324, and https://git.kernel.org/stable/c/7f708f51e3955bda0d77a0b67ab9bea6c97fea99 respectively. Distribution users should monitor their vendor's kernel update channel (Debian, Ubuntu, RHEL, SUSE, etc.) for backported patches. As a compensating control where GPU SVM is not operationally required, administrators can restrict unprivileged user access to GPU device nodes (e.g., tightening permissions on /dev/dri/* or using device cgroups) - this prevents untrusted users from triggering the drm/gpusvm code path but disables GPU compute and render access for those users entirely, which may be unacceptable in HPC or workstation environments. No workaround preserves full GPU functionality while mitigating this issue; patching is the only complete fix.

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

Share

CVE-2026-68240 vulnerability details – vuln.today

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