CVE-2026-97910: ASoC: sprd: validate compress buffer sizes against fixed allocations
In the Linux kernel, the following vulnerability has been resolved:
ASoC: sprd: validate compress buffer sizes against fixed allocations
sprdplatformcompropen() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprdplatformcomprcopy() derives all copy lengths from the user controlled runtime->fragmentsize and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragmentsize fragments for an u32 overflow in sndcompresscheckinput(), so a local user can configure a logical buffer of up to ~4GB via SNDRVCOMPRESSSETPARAMS, far exceeding the fixed allocations.
A fragmentsize larger than the 32K IRAM data area makes the stage 0 copyfromuser() overflow past the IRAM allocation, and a buffersize larger than the 2M DDR buffer makes the wrapping copy at the end of sprdplatformcomprcopy() write fully user controlled data past the buffer. No SNDRVPCMTRIGGERSTART is needed, a write() in SETUP state reaches the copy callback directly.
Reject parameters that do not fit into the fixed buffers in setparams(), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the ASoC sprd compress driver, reject SET_PARAMS values that exceed the fixed allocations: limit fragment_size to 32K for the stage 0 IRAM buffer and ensure the total buffer size fits within the 2M stage 1 DDR buffer; advertise a maximum fragment size of 32K rather than 128K.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue applies to Linux systems using the sprd ASoC compressed-audio driver. Exploitation requires local user access to configure the compressed stream and issue writes through that interface.
Does an attacker need to start audio playback before exploiting the flaw?
No. A write issued while the stream is in the SETUP state reaches the vulnerable copy callback directly, so SNDRV_PCM_TRIGGER_START is not required.
What input does an attacker control?
An attacker can set runtime fragment and buffer parameters through SNDRV_COMPRESS_SET_PARAMS and control the write length. Oversized fragment sizes can exceed the fixed 32K IRAM data area, while oversized buffer sizes can cause writes beyond the fixed 2M DDR buffer.
How can I determine whether the fix is present?
Check whether the sprd compressed-stream set_params path rejects parameters that exceed the fixed buffer allocations and whether the advertised maximum fragment size is corrected to 128K. The listed stable-kernel references identify commits containing the resolution.