Skip to main content
VulnerabilityPublished Updated

CVE-2026-72095: Linux kernel · dma-fence: Make dma_fence_dedup_array() robust against 0-count input

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051 : patch Linux kernel soon.

Data as of 26 Oct 2026, 10:24 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051, 77a9298741f8f9e8b963c977f5582ab21c6d3427, 7aa8f3dba53422465dbe1be8dbb7240304462bb2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 15 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051, 77a9298741f8f9e8b963c977f5582ab21c6d3427 or 7aa8f3dba53422465dbe1be8dbb7240304462bb2.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 575ec9b0c2f11f40535ea737ed5a64792780d1ef, < e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051
Fixed in
  • e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051
LinuxLinuxAffected
  • ≥ 575ec9b0c2f11f40535ea737ed5a64792780d1ef, < 77a9298741f8f9e8b963c977f5582ab21c6d3427
Fixed in
  • 77a9298741f8f9e8b963c977f5582ab21c6d3427
LinuxLinuxAffected
  • ≥ 575ec9b0c2f11f40535ea737ed5a64792780d1ef, < 7aa8f3dba53422465dbe1be8dbb7240304462bb2
Fixed in
  • 7aa8f3dba53422465dbe1be8dbb7240304462bb2
LinuxLinuxAffected
  • =6.16
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: dma-fence: Make dma_fence_dedup_array() robust against 0-count input dma_fence_dedup_array() returns 1 when called with num_fences == 0: the for-loop body never executes, j stays at 0, and the final `return ++j` yields 1. This contradicts both the kernel-doc ("Return: Number of unique fences remaining in the array") and the natural expectation that 0 input gives 0 output. The caller __dma_fence_unwrap_merge() bails out via the `if (count == 0 || count == 1)` fast path and so is save. But amdgpu_userq_wait_*() could reach the dedup call with a zero local count and dereference an uninitialized fence slot in the array. Make the contract match the documentation by returning 0 early. This also skips an unnecessary sort() call on an empty array.

References

Community reviews

Loading reviews…