CVE-2026-98342

What the bug is

dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()). Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed. The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list. Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed.

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/dmaengine.c

What this is

DMA GENERIC OFFLOAD ENGINE SUBSYSTEMMAINTAINERS section matched on drivers/dma/ · dmaengine@vger.kernel.org · Maintained

Check it on the machine

grep -wE 'CONFIG_DMADEVICES|CONFIG_DMA_ENGINE' /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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

• bookwormYnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le
• trixie, forky, sidYnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x

Y

built in where it is built at all; some flavours do not build it

Build switches

CONFIG_DMADEVICES, CONFIG_DMA_ENGINE

Reads as

all on means the file is compiled; any one off means it is not.

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

no vector published, unrated

Attack vector

not published

EPSS

0.18%, higher than 7.5% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

drivers/dma

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.29	5.10.271	ac8ce9f89638
2.6.29	5.15.222	14578c78405d
2.6.29	6.1.189	cbb3310a5167
2.6.29	6.6.158	8577a5ec4f7e
2.6.29	6.12.112	4448a539a0c3
2.6.29	6.18.54	fc1f4884f1d4
2.6.29	7.2.8	4aed7e47a10b
2.6.29	7.3	dc750422170a

Debian advisories