Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:17.957Z",
  "pubdate": "2026-09-25T11:17:17.957Z",
  "executiveSummary": "The Linux kernel ASoC (ALSA System on Chip) component for Spreadtrum (sprd) hardware contains a critical heap-based buffer overflow vulnerability. The flaw originates from the driver's failure to validate user-supplied compress buffer sizes against fixed physical memory allocations.\nSpecifically, the sprd_platform_compr_copy() function relies on parameters defined by the user in the runtime configuration without enforcing bounds checks against the 32K IRAM (stage 0) or 2M DDR (stage 1) pre-allocated buffers. An attacker can exploit this by configuring a logical buffer size of up to 4GB via the SNDRV_COMPRESS_SET_PARAMS ioctl.\nThis vulnerability allows a local, unprivileged user to trigger an out-of-bounds write, enabling memory corruption, potential code execution, or system instability. The attack does not require a transition to the triggered state, as the copy callback is invoked directly from the SETUP state via write(). The severity is high due to the potential for kernel-level memory corruption.",
  "technicalDetails": "The vulnerability resides in the interaction between the user-controlled fragment size configurations in the sprd audio driver and the fixed buffer allocations in the sprd_platform_compr_copy function. During initialization, sprd_platform_compr_open() allocates two distinct memory regions: a 32K IRAM buffer for stage 0 and a 2M DDR buffer for stage 1.\nThe root cause is an insufficient validation mechanism in sprd_platform_compr_copy(), which derives the length of memory operations directly from runtime->fragment_size and the user-provided write() count. While the generic compress core performs a rudimentary check for u32 overflow in snd_compress_check_input(), it fails to compare the requested buffer configuration against the hardware-specific physical limits (32K/2M).\nAn attacker can exploit this by issuing an SNDRV_COMPRESS_SET_PARAMS ioctl to set a fragment size that exceeds the 32K IRAM capacity or a total buffer size exceeding the 2M DDR allocation. When a write() system call is subsequently executed, the copy_from_user() operation attempts to move data into these undersized buffers. Because the bounds are not checked, the driver writes into adjacent kernel memory. The payload behavior involves overwriting kernel heap structures, which can lead to privilege escalation or arbitrary code execution within the kernel context.\nThe attack flow is as follows: 1) The attacker opens the compress device; 2) The attacker invokes SNDRV_COMPRESS_SET_PARAMS to configure an oversized buffer; 3) The attacker initiates a write() system call, which the kernel processes without verifying if the requested size fits into the allocated IRAM/DDR buffers; 4) The driver performs an out-of-bounds copy operation from user space, corrupting kernel heap memory.\nThe vulnerability is exacerbated by incorrect advertisement of limits in the driver's capability structures, which erroneously suggested a maximum fragment size of 128K, far exceeding the physical 32K IRAM constraint inherited by the driver design. The fix requires explicit validation of parameters in set_params() and re-alignment of the advertised maxima to match the physical 32K/2M constraints."
}