Look up another CVE · open CVE-2026-97910 in the interactive tracker
CVE-2026-97910
ASoC: sprd: validate compress buffer sizes against fixed allocations
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem sound/soc. Debian urgency: not yet assigned.
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-97910 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.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-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
sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.
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.
sound/soc/sprd/sprd-pcm-compress.c
- What this is
- SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC)MAINTAINERS section matched on sound/soc/ · linux-sound@vger.kernel.org · Supported
- Kernel module
- none to look for. The file would have gone into snd_soc_sprd_platform, and Debian does not compile it into that module, so finding snd_soc_sprd_platform in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_SND|CONFIG_SND_SOC|CONFIG_SND_SOC_SPRD' /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 5 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, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_SND, CONFIG_SND_SOC, CONFIG_SND_SOC_SPRD
- 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-09-25 (24 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.16%, higher than 4.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- sound/soc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.2 | 5.10.271 | 2fada8276117 |
| 5.2 | 5.15.222 | ad796a1bc187 |
| 5.2 | 6.1.189 | 2e27144ba4b9 |
| 5.2 | 6.6.158 | 1467e3989c6e |
| 5.2 | 6.12.111 | 38a9bb5221bc |
| 5.2 | 6.18.53 | ff63b0adc4f6 |
| 5.2 | 7.2.7 | 8064b73997f1 |
| 5.2 | 7.3 | 7a4ce92d150b |
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 bad values come from a local process holding an open /dev/snd/comprCxDy node. It sets fragment_size/fragments with the SNDRV_COMPRESS_SET_PARAMS ioctl and picks the count in write() (snd_compr_write -> sprd_platform_compr_copy). No remote protocol carries this data.
- AC:LAttack complexity, low
- snd_compress_check_input() only checks fragment_size*fragments for u32 overflow, and before the fix sprd_platform_compr_set_params() had no size check at all. The attacker picks fragment_size >32K or a buffer >2M, then write()s in SETUP state, and the overflow happens every time. There is no race and nothing depends on hardware state.
- PR:LPrivileges required, low
- Opening the compress offload node needs only the ordinary device-file access given to audio clients: the audio group on Unisoc Android builds, or the seat user's uaccess ACL on generic Linux. No capability is checked along set_params or write.
- UI:NUser interaction, none
- The attacker opens the device, sets parameters and writes data entirely on their own. No other user has to do anything.
- S:UScope, unchanged
- A kernel memory overflow reached from a local process stays inside the kernel's own security authority. No VM, IOMMU or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- copy_from_user() writes fully controlled data past the 32K IRAM area or the 2M+1K DDR compr_buffer, and the length is also controlled. That corrupts adjacent kernel memory, which is enough to build a read primitive and leak kernel data.
- I:HIntegrity impact, high
- In sprd_platform_compr_copy(), both the stage 0 copy (fragment_size - received_stage0 past iram_buffer) and the wrapping DDR copy (data_count - avail_bytes into compr_buffer.area) write attacker data of attacker-chosen length past a fixed allocation. That is an out-of-bounds write that can lead to privilege escalation.
- A:HAvailability impact, high
- Overwriting the DMA link lists, the DSP playinfo area or neighbouring pages with megabytes of attacker data reliably crashes the kernel or the audio DSP. A single write() is enough.