GHSA-HMWW-PHV2-5F63
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 15:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-97910"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:17Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: sprd: validate compress buffer sizes against fixed allocations\n\nsprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data\narea) and the stage 1 DDR buffer (2M data area) with fixed sizes, but\nsprd_platform_compr_copy() derives all copy lengths from the user\ncontrolled runtime-\u003efragment_size and the write() count, never\ncomparing them against the physical buffer sizes. The compress core\nonly checks fragment_size * fragments for an u32 overflow in\nsnd_compress_check_input(), so a local user can configure a logical\nbuffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the\nfixed allocations.\n\nA fragment_size larger than the 32K IRAM data area makes the stage 0\ncopy_from_user() overflow past the IRAM allocation, and a buffer_size\nlarger than the 2M DDR buffer makes the wrapping copy at the end of\nsprd_platform_compr_copy() write fully user controlled data past the\nbuffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP\nstate reaches the copy callback directly.\n\nReject parameters that do not fit into the fixed buffers in\nset_params(), and fix the advertised max fragment size: 128K never\nfitted into the 32K IRAM buffer. The caps values may have been carried over\nfrom the qdsp6 driver, which allocates its buffers according to the\nadvertised maxima, unlike this driver. With 32K as max fragment size\nthe advertised limits are self-consistent: 32K * 64 = 2M equals the\nDDR buffer size.\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.",
"id": "GHSA-hmww-phv2-5f63",
"modified": "2026-09-25T15:31:43Z",
"published": "2026-09-25T12:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97910"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38a9bb5221bcdece5507299f739c6751d8fc16b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a4ce92d150b9e7ecf1a710a34d8cdeb590d3751"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8064b73997f137c00a7e2e38295a763f9423928b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff63b0adc4f6a5b61c8393d204fac44c594c4d39"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.