Skip to main content

Linux Kernel CVE-2025-40096

HIGH
2025-10-30 416baaa9-dc9f-4396-8d5f-8c081fb06d67
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

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

Local authenticated GPU-job submission gives AV:L/PR:L; reaching the double free needs an induced allocation failure so AC:H; impact is memory corruption/DoS not info-leak, hence C:N, I:H, A:H.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
5.8 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
Red Hat
7.0 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
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 07:40 vuln.today
CVE Published
Oct 30, 2025 - 10:15 cve.org
HIGH 7.8

DescriptionCVE.org

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

drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies

When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free.

Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this:

drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; }

for (; i < fence_count; i++) dma_fence_put(fences[i]);

Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it.

The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").

At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix.

But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case.

As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain.

While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.

AnalysisAI

Local memory corruption in the Linux kernel's DRM GPU scheduler (drm/sched) stems from a double free in drm_sched_job_add_resv_dependencies(), where a dma_fence reference that drm_sched_job_add_dependency() already consumed on its failure path is released a second time when the backing xarray fails to expand. Any local user able to submit GPU jobs on an affected kernel can trigger the flaw, leading to kernel memory corruption and denial of service. There is no public exploit identified at time of analysis, EPSS is low (0.19%), and it is not listed in CISA KEV.

Technical ContextAI

The bug lives in the DRM (Direct Rendering Manager) GPU scheduler shared by kernel graphics drivers such as amdgpu. Jobs submitted to the scheduler track dma_fence dependencies stored in an xarray. The helper drm_sched_job_add_dependency() is designed to consume (store or drop) the passed fence reference on both success and failure; when the xarray fails to grow, the caller in drm_sched_job_add_resv_dependencies() also called dma_fence_put() on that same fence, double-freeing a reference-counted object. This is a classic CWE-415 (Double Free) memory-management defect. The description traces the flaw to commit ebd5f74255b9 (which introduced dependency tracking), with intermediate partial fixes (9c2ba265352a, 4eaf02d6076c, 963d0b356935) that relocated rather than eliminated the double free. CWE is reported as N/A in the feed, but the root cause is unambiguously a double free of a dma_fence.

Affected ProductsAI

The Linux kernel DRM GPU scheduler (drm/sched) is affected across all versions from the introduction of dependency tracking (commit ebd5f74255b9) onward, spanning multiple maintained stable branches. No specific version numbers or CPE strings are provided in the feed; affected and fixed points are identified only by stable-tree commit hashes. Fixes are published at git.kernel.org: 4c38a63ae12ecc9370a7678077bde2d61aa80e9c, 57239762aa90ad768dac055021f27705dae73344, 5801e65206b065b0b2af032f7f1eef222aa2fd83, e5e3eb2aff92994ee81ce633f1c4e73bd4b87e11 and fdfb47e85af1e11ec822c82739dde2dd8dff5115, each a per-branch backport.

RemediationAI

Upstream fix available (commits, not a tagged release); a released patched version number is not independently confirmed from the provided data. Update to a stable kernel that includes the fix commit for your branch (4c38a63ae12e, 57239762aa90, 5801e65206b0, e5e3eb2aff92, or fdfb47e85af1 via git.kernel.org/stable), or install your distribution's kernel update once the backport lands, then reboot into the patched kernel. As this is a kernel graphics-scheduler defect there is no clean runtime toggle; if immediate patching is impossible, the practical compensating control is to restrict local access to GPU/DRM job submission by limiting which users can open render nodes (/dev/dri/renderD*), accepting the trade-off that this breaks GPU-accelerated workloads for those users.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/hpc/warewulf4-x86_64/sle-hpc-node:15.6.17.8.134 Image SLES15-SP6 Image SLES15-SP6-BYOS Image SLES15-SP6-BYOS-Azure Image SLES15-SP6-BYOS-EC2 Image SLES15-SP6-BYOS-GCE Image SLES15-SP6-CHOST-BYOS Image SLES15-SP6-CHOST-BYOS-Aliyun Image SLES15-SP6-CHOST-BYOS-Azure Image SLES15-SP6-CHOST-BYOS-EC2 Image SLES15-SP6-CHOST-BYOS-GCE Image SLES15-SP6-CHOST-BYOS-GDC Image SLES15-SP6-CHOST-BYOS-SAP-CCloud Image SLES15-SP6-EC2 Image SLES15-SP6-EC2-ECS-HVM Image SLES15-SP6-GCE Image SLES15-SP6-HPC-BYOS Image SLES15-SP6-HPC-BYOS-Azure Image SLES15-SP6-HPC-BYOS-EC2 Image SLES15-SP6-HPC-BYOS-GCE Image SLES15-SP6-HPC-EC2 Image SLES15-SP6-HPC-GCE Image SLES15-SP6-Hardened-BYOS Image SLES15-SP6-Hardened-BYOS-Azure Image SLES15-SP6-Hardened-BYOS-EC2 Image SLES15-SP6-Hardened-BYOS-GCE Image SLES15-SP6-SAP Image SLES15-SP6-SAP-Azure Image SLES15-SP6-SAP-EC2 Image SLES15-SP6-SAP-GCE Image SLES15-SP6-SAPCAL Image SLES15-SP6-SAPCAL-Azure Image SLES15-SP6-SAPCAL-EC2 Image SLES15-SP6-SAPCAL-GCE Affected
Container suse/sl-micro/6.0/baremetal-os-container:latest Container suse/sl-micro/6.0/toolbox:latest Affected
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.65 Image SLE-Micro Image SLE-Micro-Azure Image SLE-Micro-BYOS Image SLE-Micro-BYOS-Azure Image SLE-Micro-BYOS-EC2 Image SLE-Micro-BYOS-GCE Image SLE-Micro-EC2 Image SLE-Micro-GCE Affected
Container suse/sl-micro/6.0/kvm-os-container:2.1.3-6.88 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.105 Affected

Share

CVE-2025-40096 vulnerability details – vuln.today

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