Look up another CVE · open CVE-2026-93178 in the interactive tracker
CVE-2026-93178
drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup
Published 2026-09-17 (31 days 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-93178 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.
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/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
- What this is
- AMD POWERPLAY AND SWSMUMAINTAINERS section matched on drivers/gpu/drm/amd/pm/ · amd-gfx@lists.freedesktop.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid, bookworm · linux-6.12?
- ?
- not established - no Makefile entry for the affected file
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.
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
Signals
- Published
- 2026-09-17 (31 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.16%, higher than 4.7% 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 |
|---|---|---|
| 4.5 | 5.10.270 | d9ef085114d1 |
| 4.5 | 5.15.221 | 6f08c001fa6e |
| 4.5 | 6.1.188 | ce0d8e72836c |
| 4.5 | 6.6.157 | 745297208d31 |
| 4.5 | 6.12.110 | f925d317d84d |
| 4.5 | 6.18.52 | 8a3db9f593b6 |
| 4.5 | 7.2.6 | 1664327ce797 |
| 4.5 | 7.3 | 3a8a05477cda |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 attacker-controlled ATOM_Tonga_SCLK_Dependency_Record.ucVddInd (and MCLK ucVddcInd / MM ucVddcInd) bytes enter via write() on /sys/class/drm/cardN/device/pp_table; amdgpu_set_pp_table → pp_dpm_set_pp_table copies them into hardcode_pp_table and amd_powerplay_reset → hwmgr_hw_init → pp_tables_v1_0_initialize re-parses them before smu7_patch_voltage_dependency_tables_with_lookup_table uses vddInd.
- AC:LAttack complexity, low
- A PowerPlay table whose ucVddInd/ucVddcInd is >= vddc_lookup_table or vddgfx_lookup_table count makes smu7_patch_voltage_dependency_tables_with_lookup_table perform a deterministic entries[voltage_id].us_vdd load; voltage_id is the attacker-chosen uint8_t and no race or memory-layout gate is required.
- PR:LPrivileges required, low
- pp_table is AMDGPU_DEVICE_ATTR_RW (S_IRUGO|S_IWUSR) and amdgpu_dpm_is_pp_table_allowed() enables it on SMU7 discrete ASICs (Tonga/Fiji/Polaris/VegaM); the same sysfs node was scored PR:L in CVE-2025-21780 and CVE-2026-74450 because AMD desktop/gaming udev rules routinely grant group write for overclocking tools.
- UI:NUser interaction, none
- The attacker writes the crafted PowerPlay table to pp_table themselves; no other user must plug in a GPU, mount an image, or confirm a prompt.
- S:UScope, unchanged
- The out-of-bounds us_vdd load targets the kmalloc_flex vddc_lookup_table/vddgfx_lookup_table in the host amdgpu driver and does not cross a KVM/Xen, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- get_vddc_lookup_table allocates only 16 phm_ppt_v1_voltage_lookup_record slots, but voltage_id is the attacker-supplied uint8_t ucVddInd (0-255), so entries[voltage_id].us_vdd reads two kernel-heap bytes at a chosen offset up to about 2.5KB past the object, repeatable across sclk, mclk, and mm dependency entries.
- I:NIntegrity impact, none
- The only stores are in-bounds writes of that 16-bit millivolt into sclk_table/mclk_table/mm_table entries[entry_id].vddc or .vddgfx; those fields are not used as pointers or as further unbounded indexes, so this is not an out-of-bounds write or control-flow hijack primitive.
- A:HAvailability impact, high
- voltage_id 255 walks about 2.5KB past the 16-entry lookup object and can fault on an unmapped or guard page; the same uploaded table can leave vdd_dep_on_sclk, vdd_dep_on_mclk, or mm_dep_table NULL so the ->count load oopses; garbage voltages later sent to the SMU can hang the GPU.