Bug 2516785 (CVE-2026-74418)

Summary: CVE-2026-74418 kernel: dma-fence: Fix potential tracepoint null pointer dereferences
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the `dma-fence` subsystem of the Linux kernel. This vulnerability allows for a null pointer dereference in tracepoint functions, such as `trace_dma_fence_signaled`, `trace_dma_fence_wait_end`, and `trace_dma_fence_destroy`, after a fence operation has been signaled and its internal pointers reset. An attacker could potentially exploit this to cause a system crash, leading to a denial of service.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 06:33:22 UTC 
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.
Comment 1 Keith Grant 2026-08-20 21:52:54 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081512-CVE-2026-74418-0a40@gregkh/T