CVE-2026-97910

Status: UPDATED  |  Advisory ID: CVE-2026-97910

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

ASoC: sprd: validate compress buffer sizes against fixed allocations

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References