CVE-2026-74418: Linux kernel · dma-fence: Fix potential tracepoint null pointer dereferences
Affects Linux kernelSource GCVE Database
Not known to be exploited.
Data as of 26 Oct 2026, 14:05 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 11% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Exploitation evidence
Disclosed: evidence found.
CVE published 17 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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
AI-suggested
A fix for this vulnerability has been implemented in the Linux kernel by modifying the dma-fence tracepoint handling to prevent null pointer dereferences. Users should apply the official kernel updates that include this fix.
Description
In the Linux kernel, the following vulnerability has been resolved: dma-fence: Fix potential tracepoint null pointer dereferences Trace_dma_fence_signaled, trace_dma_fence_wait_end and trace_dma_fence_destroy can all currently dereference a null fence->ops pointer after it has been reset on fence signalling. Lets use the safe string getters for most tracepoints to avoid this class of a problem, while for the signal tracepoint we move it to before ops are cleared to avoid losing the driver and timeline name information. Apart from moving it we also need to add a new tracepoint class to bypass the safe name getters since the signaled bit is already set. For dma_fence_init we also need to use the new tracepoint class since the rcu read lock is not held there, and we can do the same for the enable signaling since there we are certain the fence cannot be signaled while we are holding the lock and have even validated the fence->ops.
References
- nvd.nist.gov/vuln/detail/CVE-2026-74418 (opens in a new tab)
- git.kernel.org/stable/c/4e01fc9a5bc49b04fad403ffa71299b35e132ca8 (opens in a new tab)
- git.kernel.org/stable/c/e94b9f01543cc6a83538c2c2cc645a424d3015ca (opens in a new tab)
- ubuntu.com/security/CVE-2026-74418 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2026-74418 (opens in a new tab)
- git.kernel.org/linus/e94b9f01543cc6a83538c2c2cc645a424d3015ca (opens in a new tab)