Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local access to dma-buf device node
-
DeliveryTrigger fence signaling via ioctl
-
ExploitRace read of timeline/driver name string
-
ExecutionDereference freed RCU-protected memory
-
ImpactLeak kernel data or crash host
Vulnerability Assessment
| Exploitation Conditions | Requires local access to a kernel interface that exposes dma_fence objects (e.g., DRM/GPU, sync_file, or other DMA-buf consumers) and the ability to read a fence's timeline name or driver name string concurrently with the fence being signaled. The flaw only manifests for dma_fence implementations that implement a release or wait callback (so the ops pointer is NOT cleared on free), and exploitation hinges on winning the race window between signaling and the RCU-protected string read. Limiting factors: local-only attack vector (no remote reachability), a required low-privilege local account with device access, and race-condition timing that reduces reliability; patched kernels are not affected. |
| Impact | This is a locally-exploitable use-after-free in the Linux kernel's dma-buf/dma-fence subsystem, triggered when the RCU protection for a fence's timeline/driver-name string is lost after signaling because the ops pointer is not cleared for many dma_fence implementations. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H, 7.1) scores it HIGH with high confidentiality and availability impact, consistent with a UAF that can leak kernel memory or crash the system; however, the Tags label it only 'Denial Of Service,' which understates the C:H confidentiality dimension the vector asserts. All exploitation-probability signals point LOW: EPSS is 0.16% (5th percentile), the CVE is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis. Realistically this is a HIGH-CVSS but LOW-real-world-priority issue: exploitation requires local access with some privilege plus winning a signaling race window, and these dma-fence regressions are typically patched routinely through stable-tree updates rather than attacked opportunistically. One caveat: the flaw is a race condition (UAF after signaling), which the input CVSS rates AC:L - a race window more plausibly warrants AC:H, suggesting reliable exploitation is harder than the base score implies. No SSVC decision data was provided in the input. |
| Exploit ScenarioDerived | A local low-privileged user with access to a DMA-buf/dma-fence interface (e.g., via a GPU or media device node) repeatedly triggers fence signaling while concurrently reading the fence's timeline or driver name string, racing to dereference the string after the backing object is freed. Winning this race yields a kernel use-after-free that can disclose kernel memory contents or crash the system. No public proof-of-concept exploit is identified at time of analysis, and reliable exploitation depends on timing the race precisely. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Local use-after-free in the Linux kernel's dma-buf/dma-fence subsystem lets a low-privileged local user with access to a fence-exposing interface (DRM/GPU, sync_file, or other DMA-buf consumers) read freed kernel memory when a fence's timeline or driver name string is retrieved concurrently with the fence being signaled. The regression was introduced by an earlier NULL-pointer dereference fix that replaced the signaled-bit check with an ops-pointer check, which is insufficient because many dma_fence implementations never clear the ops pointer on free and thus lose the RCU protection that keeps the returned string alive. Impact is a kernel crash (denial of service) or disclosure of freed heap contents; exploitation requires local device access and winning a narrow race, and no public exploit has been identified at time of analysis (EPSS 0.16%, 5th percentile; no CISA KEV listing).
RemediationAI
Vendor-released patch: Linux 7.2.8 (stable) and Linux 7.3-rc4 (mainline), delivered through the upstream commits https://git.kernel.org/stable/c/a4db25b8949d6ff9c1a685a1273a015e8bab29db and https://git.kernel.org/stable/c/3ed11c671ff7ec58c8fd96410233c677df23f407; update to these or later kernel releases and note that distributions carrying the earlier NULL-dereference fix without this follow-up remain affected even on otherwise current kernels. Where immediate upgrades are not possible, compensating controls are necessarily restrictive because the vulnerable path is local kernel code: block untrusted local users from fence-exposing device nodes (for example /dev/dri/* and sync_file descriptors) via device cgroup or filesystem permissions, and drop GPU/media device access for unprivileged or containerized workloads using seccomp and device passthrough restrictions. The trade-off is loss of hardware-accelerated graphics, compute and media decode for those processes, and the mitigation does not help environments where the untrusted user legitimately requires that device access (such as multi-tenant GPU or desktop session scenarios), where the patch remains the only complete fix; no remote or network-side workaround exists since the attack vector is strictly local and race-dependent, with known exploitation limited by timing reliability.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
dma-buf is the Linux kernel framework for sharing buffers between device drivers, and dma_fence objects represent the completion of asynchronous work on those buffers; each fence carries human-readable timeline and driver name strings that userspace can read (for example through debugfs, sync_file, or DRM tracepoints) and that are protected by RCU because they can be released when the fence is signaled. An earlier fix for a potential NULL pointer dereference ("dma-buf: dma-fence: Fix potential NULL pointer dereference") changed the guard to test the ops pointer instead of the signaled bit. That guard only becomes safe if the ops pointer is cleared when neither the release nor the wait callback is implemented, which is not the case for many dma_fence implementations, so those implementations stop taking the RCU-protected path after signaling and the returned string can be freed while still being read (use-after-free, consistent with CWE-416; no CWE was formally assigned in the source data). The corrective patch re-adds the signaling-state check alongside the ops-pointer check, preserving both the NULL-dereference protection and the post-signaling RCU protection. Affected code is identified by CPE cpe:2.3:a:linux:linux and applies only to kernels carrying the regressing change; patched kernels, which include the fixes in stable branches 7.2.8 and 7.3-rc4, are not affected.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Local access to a dma-fence interface (AV:L, PR:L); exploitation requires winning a signaling race window (AC:H); UAF can leak kernel memory (C:H) and crash the host (A:H) with no integrity impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v3
The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference" changed the check to test for the ops pointer instead of the signaled bit to avoid a potential NULL dereference when the ops pointer has been cleared.
The problem is now that the ops pointer is cleared only when neither the release nor the wait callback is implemented and this isn't true for a lot of dma_fence implementations yet. So those implementations lost the RCU protection after signaling of the returned string resulting in potential use after free.
Add the signaling check additional to the ops pointer check so that we have both the protection against NULL dereference as well as the RCU protection after signaling for the returned string.
v2: improve comments to note RCU protection and explain why we check both signaling state and ops pointer v3: some comment improvements suggested by Philip
Executive ViewAI
A high-severity use-after-free in the Linux kernel's dma-buf/dma-fence subsystem (CVE-2026-98243) can let a local user with access to GPU/DRM, sync_file, or other DMA-buf consumer interfaces crash affected systems or read freed kernel memory. This affects Linux servers, endpoints, cloud instances, and GPU-accelerated workloads, where a crash could disrupt availability and freed-memory disclosure could expose sensitive residual data; however, exploitation requires local device access and a narrow race, and no public exploit identified at time of analysis. Patch available per vendor advisory, so leadership should prioritize remediation to reduce organizational exposure.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
EUVD-2026-93171
GHSA-r72r-63qh-x7gr
NVD
CVE.org
EPSS
Exploit-DB