Skip to main content

Linux Kernel CVE-2025-40336

HIGH
2025-12-09 416baaa9-dc9f-4396-8d5f-8c081fb06d67
8.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
8.8 HIGH

Local GPU-device access needed so AV:L/PR:L; low complexity to misalign a range; scope change (S:C) as memory outside the mm is mapped, giving high confidentiality/integrity/availability impact.

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

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

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

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 07:37 vuln.today
CVE Published
Dec 09, 2025 - 16:17 cve.org
HIGH 8.8

DescriptionCVE.org

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

drm/gpusvm: fix hmm_pfn_to_map_order() usage

Handle the case where the hmm range partially covers a huge page (like 2M), otherwise we can potentially end up doing something nasty like mapping memory which is outside the range, and maybe not even mapped by the mm. Fix is based on the xe userptr code, which in a future patch will directly use gpusvm, so needs alignment here.

v2:

  • Add kernel-doc (Matt B)
  • s/fls/ilog2/ (Thomas)

AnalysisAI

Local privilege-escalation and memory-disclosure flaw in the Linux kernel's DRM GPU SVM (Shared Virtual Memory) subsystem, where incorrect use of hmm_pfn_to_map_order() mishandles an HMM range that only partially covers a huge page (e.g. 2MB), causing the driver to map physical memory outside the intended range - memory that may not even belong to the faulting process's address space. Affecting recent kernels carrying the drm/gpusvm code (associated with the Intel Xe GPU driver's userptr/SVM path), a local user with GPU access can trigger cross-boundary mappings leading to information disclosure or memory corruption. There is no public exploit identified at time of analysis, and EPSS is low at 0.19% (9th percentile).

Technical ContextAI

The affected component is the Direct Rendering Manager GPU SVM layer (drm/gpusvm), which lets a GPU share a unified virtual address space with a process using HMM (Heterogeneous Memory Management). hmm_pfn_to_map_order() reports the mapping order (page size, e.g. order 9 = 2MB huge page) for a PFN so the driver can build large device mappings efficiently. The bug is a boundary/alignment defect: when an HMM range only partially overlaps a huge page, the returned order was applied without clamping to the range, so the driver could construct a mapping extending beyond the requested range into memory not mapped by the process's mm_struct. The fix aligns the logic with the Intel Xe userptr code (which will later consume gpusvm directly) and switches fls to ilog2 for correct order computation. No CWE was assigned, but the root-cause class is out-of-bounds mapping/access (CWE-125/CWE-787 family) arising from improper enforcement of memory range bounds.

Affected ProductsAI

The Linux kernel is affected, specifically builds that include the drm/gpusvm subsystem (the newer GPU Shared Virtual Memory code tied to the Intel Xe driver's userptr/SVM path); this is bleeding-edge/recent-kernel code rather than legacy trees. No CPE strings were provided in the input and NVD did not enumerate exact affected version ranges, so precise vulnerable versions are not independently confirmed - affected commits are tracked in the kernel stable tree. The fix is recorded in the stable commits at https://git.kernel.org/stable/c/08e9fd78ba1b9e95141181c69cc51795c9888157 and https://git.kernel.org/stable/c/c50729c68aaf93611c855752b00e49ce1fdd1558.

RemediationAI

Update to a Linux kernel stable release that incorporates the gpusvm fix; the upstream fix is available as the stable-tree commits 08e9fd78ba1b9e95141181c69cc51795c9888157 and c50729c68aaf93611c855752b00e49ce1fdd1558 (https://git.kernel.org/stable/c/08e9fd78ba1b9e95141181c69cc51795c9888157 and https://git.kernel.org/stable/c/c50729c68aaf93611c855752b00e49ce1fdd1558), but a specific tagged patched release version is not independently confirmed from the provided data, so consume the fix through your distribution's kernel update once it lands. As a compensating control until patched, restrict local access to the GPU by tightening permissions on the DRM render/device nodes (e.g. /dev/dri/renderD*) to trusted users and groups only, which blocks the unprivileged local trigger path at the cost of denying GPU/compute access to restricted users; on systems that do not require Intel Xe GPU SVM/userptr functionality, avoid loading or exposing the affected driver. Because the vector is local (AV:L), standard mitigations against untrusted local users - minimizing multi-tenant local shell access and enforcing least privilege - materially reduce exposure.

Vendor StatusVendor

SUSE

Severity: Moderate
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-2025-40336 vulnerability details – vuln.today

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