Look up another CVE · open CVE-2026-98324 in the interactive tracker
CVE-2026-98324
dmaengine: pxa: fix double counting of the hw descriptors
Published 2026-10-06 (13 days ago) by the Linux kernel CNA. Subsystem drivers/dma. Debian urgency: unimportant.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-98324 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
pxad_alloc_desc() was converted from kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT) to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc itself - but only where the compiler has __builtin_counted_by_ref(), so from gcc 15.1 or clang 22.1 on. The loop below it still increments nb_desc, which makes it come out doubled there and correct elsewhere. nb_desc is what pxad_free_desc() iterates over and what set_updater_desc() indexes from, so set it explicitly and drop the increment. The error path has to lower it to the number of descriptors allocated so far, otherwise pxad_free_desc() would free entries that were never allocated.
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/pxa_dma.c
- What this is
- PXA2xx/PXA3xx SUPPORTMAINTAINERS section matched on drivers/dma/pxa* · linux-arm-kernel@lists.infradead.org · Maintained
- Kernel module
- none to look for. The file would have gone into pxa_dma, and Debian does not compile it into that module, so finding pxa_dma in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_DMADEVICES|CONFIG_PXA_DMA' /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 does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_DMADEVICES, CONFIG_PXA_DMA
- 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
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 7.0 | 7.2.8 | 1de93785f32b |
| 7.0 | 7.3 | f6504be006aa |
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 fault is in pxad_alloc_desc()/set_updater_desc() in drivers/dma/pxa_dma.c and is triggered by any local I/O that makes a PXA DMA client prep a transfer, e.g. read() on SD/MMC storage via pxamci -> dmaengine_prep_slave_sg() -> pxad_prep_slave_sg(). No remote protocol supplies the bad state.
- AC:LAttack complexity, low
- On builds with gcc>=15.1 or clang>=22.1 (the current default toolchains), kzalloc_flex() already sets nb_desc=N and the loop's nb_desc++ makes it 2N on every allocation, so every DMA prep overruns hw_desc[]. Controlling the out-of-bounds slot only needs ordinary slab grooming of the neighbouring kmalloc object.
- PR:LPrivileges required, low
- An unprivileged local user can start the vulnerable path just by reading a file on PXA MMC-backed storage (or using SPI/audio devices that use pxa_dma). No capability check sits between the read and pxad_prep_slave_sg().
- UI:NUser interaction, none
- The attacker drives the I/O that leads to pxad_alloc_desc() and set_updater_desc() through their own syscalls. No victim action is needed.
- S:UScope, unchanged
- Corruption stays within kernel slab and dma_pool memory under the same kernel authority, with no VM or IOMMU boundary crossed.
- C:HConfidentiality impact, high
- set_updater_desc(), is_desc_completed() and pxad_residue() read pointers from hw_desc[2N-1] and hw_desc[2N-2], past the kzalloc_flex allocation into adjacent slab memory, and dereference them. A groomed neighbouring object gives a pointer-controlled read.
- I:HIntegrity impact, high
- set_updater_desc() writes ddadr/dsadr/dtadr/dcmd (16 bytes) through the out-of-bounds pointer hw_desc[nb_desc-1], and pxad_free_desc() calls dma_pool_free() on up to N out-of-bounds pointers. With a groomed neighbour this is a controlled-address write plus an invalid free.
- A:HAvailability impact, high
- Every pxa_dma transfer dereferences pointers past the allocation and frees nonexistent dma_pool entries in pxad_free_desc(), causing an oops or pool corruption on the first MMC/SPI DMA.