Look up another CVE · open CVE-2026-98243 in the interactive tracker
CVE-2026-98243
dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v3
Published 2026-10-06 (13 days ago) by the Linux kernel CNA. Subsystem drivers/dma-buf. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-98243 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/dma-buf/dma-fence.c
include/linux/dma-fence.h
- What this is
- SYNC FILE FRAMEWORKMAINTAINERS section matched on drivers/dma-buf/dma-fence* · linux-media@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_DMA_SHARED_BUFFER /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_DMA_SHARED_BUFFER
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-10-06 (13 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/dma-buf
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.2 | 7.2.8 | a4db25b8949d |
| 7.2 | 7.3 | 3ed11c671ff7 |
| 7.1.5 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached through the local SYNC_IOC_FILE_INFO ioctl on a sync_file fd (sync_file_ioctl_fence_info -> sync_fill_fence_info -> dma_fence_timeline_name/dma_fence_driver_name). No network protocol carries data into this path.
- AC:LAttack complexity, low
- The attacker produces the whole state: create an xe exec queue, submit a job, export the out-fence as a sync_file, destroy the queue, wait for signal plus an RCU grace period, then call the ioctl. The kfree_rcu'd scheduler is then read deterministically.
- PR:LPrivileges required, low
- Needs an ordinary unprivileged user who can open a DRM render node (render group or seat ACL) to create exec queues and export syncobj fences as sync_files; no root or CAP_SYS_ADMIN is required.
- UI:NUser interaction, none
- The attacker performs every step through their own ioctls on objects they own; no other user or administrator has to act.
- S:UScope, unchanged
- The use-after-free is a kernel memory read inside the same kernel security authority; no VM, IOMMU or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- Since ops stays non-NULL after signal, drm_sched_fence_get_timeline_name dereferences fence->sched inside the freed xe guc exec-queue object and strscpy's the string at the loaded name pointer into info->obj_name, which is copied to userspace; a sprayed fake pointer gives a kernel read-out.
- I:NIntegrity impact, none
- The freed scheduler is only read: get_timeline_name/get_driver_name load a pointer and the caller copies a string from it. No write or indirect call goes through freed memory, so the code shows no write primitive.
- A:HAvailability impact, high
- If the freed scheduler slot is reused, sched->name becomes a garbage pointer; strscpy/snprintf on it can fault and oops the kernel, and an unprivileged user can trigger this repeatedly.