Look up another CVE · open CVE-2026-64153 in the interactive tracker
CVE-2026-64153
drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64153 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 | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Commit "iommu: return full error code from iommu_map_sg[_atomic]()" changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. Store the return value in the appropriate type and in case of error, return it rather than WARNing. Patchwork: https://patchwork.freedesktop.org/patch/719685/
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/gpu/drm/msm/msm_iommu.c
- What this is
- DRM DRIVER for Qualcomm display hardwareMAINTAINERS section matched on drivers/gpu/drm/msm/ · linux-arm-msm@vger.kernel.org · Maintained
- Kernel module
- msm
Check it on the machine
grep -w CONFIG_DRM_MSM /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.
lsmod | grep -w msmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
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.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_DRM_MSM
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-07-19 (3 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15 | 5.15.209 | 3c2cdb7c07f6 |
| 5.15 | 6.1.175 | 3e3c3c95ef4f |
| 5.15 | 6.6.142 | 7256e54583ae |
| 5.15 | 6.12.92 | 3457807aeb88 |
| 5.15 | 6.18.34 | f4e37f3df436 |
| 5.15 | 7.0.11 | 3a45af377334 |
| 5.15 | 7.1 | 55e0f0d1c1a4 |
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 only through local DRM interfaces on Qualcomm devices: MSM_GEM_SUBMIT and framebuffer/atomic display commits pin GEM buffers into the display or legacy kernel-managed GPU IOMMU domain via ioctl on /dev/dri/renderD* or /dev/dri/card*.
- AC:LAttack complexity, low
- An attacker can reliably force iommu_map_sgtable() failures by exhausting IOMMU page-table space or memory through repeated GEM allocations and mapping operations they fully control, without depending on victim timing or uncontrollable layout.
- PR:LPrivileges required, low
- Exploitation requires only unprivileged access to the DRM render/display node (DRM_RENDER_ALLOW ioctls); on Android phones any app with GPU access can trigger the mapping path without root or special capabilities.
- UI:NUser interaction, none
- No victim interaction is required beyond the attacker's own DRM/GPU or framebuffer operations; the vulnerable msm_iommu_map() runs during their own buffer pin/map requests.
- S:CScope, changed
- Incorrect handling of IOMMU mapping errors can leave the display engine or Adreno GPU operating on IOVAs without the intended translation, crossing the IOMMU/DMA security boundary between device DMA and system physical memory.
- C:HConfidentiality impact, high
- If a failed IOMMU mapping is treated as successful, GPU or display DMA can read physical pages outside the intended buffer, enabling arbitrary physical memory disclosure; this is the same error-sign-conversion class that caused silent mapping failure in the parallel tegra fix.
- I:HIntegrity impact, high
- A successful-but-unmapped or mis-mapped IOVA lets the GPU (IOMMU_WRITE on typical buffers) or display write-back path corrupt physical memory outside the caller's GEM object, providing a DMA-based write primitive.
- A:HAvailability impact, high
- Repeated IOMMU mapping failures mishandled on the display or GPU path can cause IOMMU fault storms, GPU hangs, display pipeline stalls, or kernel WARN/oops conditions during fault handling.