Look up another CVE · open CVE-2026-53173 in the interactive tracker
CVE-2026-53173
accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate()
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem drivers/accel. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53173 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.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The command stream parsing loop increments the index variable a second time when a 64-bit command word is encountered (bit 14 set), but does not re-check the loop bound before writing the second word: for (i = 0; i < size / 4; i++) { bocmds[i] = cmds[0]; if (cmd & 0x4000) { i++; bocmds[i] = cmds[1]; /* unchecked */ } } The buffer bocmds is backed by a DMA allocation of exactly size bytes from drm_gem_dma_create(ddev, size), giving valid indices [0, size/4-1]. When i == size/4 - 1 on entry to an iteration and bit 14 of cmds[0] is set, bocmds[size/4-1] is written in bounds, i is then incremented to size/4, and bocmds[size/4] writes four bytes past the end of the allocation. Userspace controls both the buffer contents and the size argument via the ioctl, making this a userspace-triggerable heap out-of-bounds write. Fix by checking the incremented index against the buffer bound before the second write and returning -EINVAL if the buffer is too small to contain the extended command.
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/accel/ethosu/ethosu_gem.c
- What this is
- ARM ETHOS-U NPU DRIVERMAINTAINERS section matched on drivers/accel/ethosu/ · dri-devel@lists.freedesktop.org · Supported
Check it on the machine
grep -wE 'CONFIG_DRM_ACCEL|CONFIG_DRM_ACCEL_ARM_ETHOSU' /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 2 releases. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_DRM_ACCEL, CONFIG_DRM_ACCEL_ARM_ETHOSU
- 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-06-25 (4 months 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.12%, higher than 1.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/accel
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.19 | 7.0.13 | db6cb3e35ceb |
| 6.19 | 7.1 | c0837b9cf6ea |
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 vulnerable code is reached through the local DRM accel ioctl `DRM_IOCTL_ETHOSU_CMDSTREAM_BO_CREATE` on `/dev/accel/accel*`, not through network, adjacent, or physical input.
- AC:LAttack complexity, low
- Userspace controls both the command stream contents and size, and can deterministically place a 64-bit command marker at the final word to trigger the unchecked second write. No race or external state is required.
- PR:LPrivileges required, low
- The driver ioctl has no capability, root, master, or authentication check, but the attacker must be a local user/process able to open the accelerator device node.
- UI:NUser interaction, none
- No victim action is needed after the attacker has local device access; a single ioctl with attacker-controlled arguments reaches the vulnerable function.
- S:UScope, unchanged
- This is kernel memory corruption within the same host security authority and does not cross a VM, IOMMU, or other distinct security boundary.
- C:HConfidentiality impact, high
- The bug is a userspace-triggered kernel heap/DMA allocation out-of-bounds write, which is defensibly exploitable as memory corruption and can lead to kernel compromise and disclosure of arbitrary kernel data.
- I:HIntegrity impact, high
- An out-of-bounds write of attacker-controlled command data past a kernel DMA-backed GEM allocation can corrupt adjacent memory and is treated as high-integrity-impact kernel memory corruption.
- A:HAvailability impact, high
- Even without full exploitation, corrupting memory past the allocation can crash or destabilize the kernel, giving high availability impact.