CVE-2026-97910

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sprd: validate compress buffer sizes against fixed allocations<br /> <br /> sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data<br /> area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but<br /> sprd_platform_compr_copy() derives all copy lengths from the user<br /> controlled runtime-&gt;fragment_size and the write() count, never<br /> comparing them against the physical buffer sizes. The compress core<br /> only checks fragment_size * fragments for an u32 overflow in<br /> snd_compress_check_input(), so a local user can configure a logical<br /> buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the<br /> fixed allocations.<br /> <br /> A fragment_size larger than the 32K IRAM data area makes the stage 0<br /> copy_from_user() overflow past the IRAM allocation, and a buffer_size<br /> larger than the 2M DDR buffer makes the wrapping copy at the end of<br /> sprd_platform_compr_copy() write fully user controlled data past the<br /> buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP<br /> state reaches the copy callback directly.<br /> <br /> Reject parameters that do not fit into the fixed buffers in<br /> set_params(), and fix the advertised max fragment size: 128K never<br /> fitted into the 32K IRAM buffer. The caps values may have been carried over<br /> from the qdsp6 driver, which allocates its buffers according to the<br /> advertised maxima, unlike this driver. With 32K as max fragment size<br /> the advertised limits are self-consistent: 32K * 64 = 2M equals the<br /> DDR buffer size.<br /> <br /> Discovered by Atuin - Automated Vulnerability Discovery Engine.