CVE-2026-97910 Affecting linux-6.12 package, versions <6.12.111-1~deb12u1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DEBIAN12-LINUX612-20506939
- published5 Oct 2026
- disclosed25 Sept 2026
Introduced: 25 Sep 2026
NewCVE-2026-97910 (opens in a new tab)How to fix?
Upgrade Debian:12 linux-6.12 to version 6.12.111-1~deb12u1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream linux-6.12 package and not the linux-6.12 package as distributed by Debian.
See How to fix? for Debian:12 relevant fixed versions and status.
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.
References
- https://security-tracker.debian.org/tracker/CVE-2026-97910
- https://git.kernel.org/stable/c/38a9bb5221bcdece5507299f739c6751d8fc16b2
- https://git.kernel.org/stable/c/7a4ce92d150b9e7ecf1a710a34d8cdeb590d3751
- https://git.kernel.org/stable/c/8064b73997f137c00a7e2e38295a763f9423928b
- https://git.kernel.org/stable/c/ff63b0adc4f6a5b61c8393d204fac44c594c4d39
- https://git.kernel.org/stable/c/1467e3989c6edf79d3898c78aa47027f31ee5acb
- https://git.kernel.org/stable/c/2e27144ba4b98bb3eb14aaccd4b088e2e69844e3
- https://git.kernel.org/stable/c/2fada8276117215407afd1f59de5d2fe22aff01f
- https://git.kernel.org/stable/c/ad796a1bc1875da2ebb616ea9bc1f2994273fd02