GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel dma-fence: lost RCU protection after signalling allows use-after-free of fence name strings

UnscoredCVE-2026-98243Kernel, userspace & hypervisorcurated

Impact

An earlier fix changed the dma-fence timeline/driver name accessors to test the ops pointer instead of the signalled bit. Because ops is cleared only for implementations that provide neither a release nor a wait callback - which is not the case for most drivers - those implementations lost their RCU protection once a fence was signalled, so the returned string can be read after the backing object is freed. dma-fence is the synchronisation primitive every GPU and accelerator driver builds on, and these names are read by debugfs, tracepoints and sync-file introspection, so the read can be triggered from ordinary observability paths on a busy GPU node. A use-after-free read of kernel memory is an information leak and a potential crash; the record does not claim a demonstrated privilege escalation and carries no CVSS score.

Who can reach it

Local: a process that can observe fences while they signal - debugfs or tracepoint access, or a tenant exercising a driver's sync-file and fence-info interfaces through a GPU device node. No remote reach; no authentication beyond local access to those interfaces.

What to do

Take the stable kernel update (v3 of the patch) that checks both the signalling state and the ops pointer, then drain and reboot each node. Restricting debugfs and tracefs to administrators reduces the easiest trigger in the meantime. The record names only the two stable commits, not a fixed release version.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.