PT-2026-98574 · Linux · Linux
CVE-2026-97910
·
Publicado
2026-09-25
·
Atualizado
2026-09-25
CVSS v3.1
7.8
Alta
| Vetor | AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
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.
Correção
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux