Coordinated Vulnerability Disclosure - ALSA Project / tinycompress

Greetings ALSA Security Team,

I'm a vulnerability analyst at VulnCheck <https://www.vulncheck.com/> an exploit intelligence company and research CVE Numbering Authority (CNA), where I'm one of several folks who manage our coordinated vulnerability disclosure (CVD) program.

An external security researcher recently reported
<https://www.vulncheck.com/advisories/report> a potential vulnerability impacting ALSA Project / tinycompress
<https://github.com/alsa-project/tinycompress> and VulnCheck is acting as the intermediary and coordinator.

VulnCheck follows a 120-day disclosure policy
<https://www.vulncheck.com/vulnerability-disclosure-policy>, meaning we afford vendors/maintainers up to 120 days from the time of receiving the report to address the issue before publication of a CVE record and third-party advisory. For this vulnerability, that 120-day deadline falls on *January 19, 2027 (01/19/2027)*. Of note, patch publication constitutes public disclosure — if a patch is issued, we will publish the CVE record at that time rather than waiting for the full 120-day window.

The researcher has provided us with a comprehensive technical report, which we have attached to this email. Let us know if you have any questions for us about the CVD process or for the researcher regarding the reported vulnerability.

Thank you,

<https://www.vulncheck.com/>

Brandon Tarr
VulnCheck

# Out-of-Bounds Read in SOF Probe Packet Parser
**Package:** alsa-project/tinycompress
**Tested Versions:** v1.2.16 (commit 6d39f020bdc4af9dc586b48cecfed3c2a4e235ea, also current master HEAD)
---
## Affected Files
src/utils/sofprobeclient/probes_demux.c (validate_data_packet, around line 247)
---
## Root Cause
data_size_bytes (uint32_t, taken from the probe stream) is never capped after the initial 4096 byte allocation. validate_data_packet() computes checksump = (uint64_t*)(packet->data + packet->data_size_bytes) and dereferences it. total_data_to_copy is itself a uint32_t, so data_size_bytes + sizeof(uint64_t) truncates in 32 bits on every platform, meaning a huge data_size_bytes yields a small total_data_to_copy and the realloc path that would otherwise grow the buffer is never taken. The subsequent checksum read then lands outside the allocated packet buffer.
---
## PoC
Feed the parser a packet with data_size_bytes = 0xFFFFFFFF. Initial packet_size is 4096 and remains unchanged after parsing.
Confirmed output:
AddressSanitizer: SEGV (READ) ... probes_demux.c:247 in validate_data_packet.
---
## Impact
An attacker who controls the SOF DSP probe stream (the firmware/kernel path feeding sofprobeclient, or a test harness sending crafted packets) can crash the userspace probe client with a single malformed packet, causing a denial of service. This is not reachable by an unprivileged file or network attacker in normal use; it requires the ability to inject data into the probe stream.
---
## Suggested Remediation
Cap data_size_bytes to a sane maximum and reject oversized packets before use. Make total_data_to_copy a size_t and perform a checked addition instead of relying on uint32_t arithmetic.

---

# NULL Pointer Dereference on Failed Compress Device Open
**Package:** alsa-project/tinycompress
**Tested Versions:** v1.2.16 (commit 6d39f020bdc4af9dc586b48cecfed3c2a4e235ea, also current master HEAD)
---
## Affected Files
src/lib/compress.c (compress_get_error, line 81; compress_close, line 194)
---
## Root Cause
compress_get_error() and compress_close() dereference the compress pointer with no NULL guard. The cplay, crecord, and fcplay utilities call compress_get_error(compress) inside their own error branch (if (!compress || ...)), so a failed device open leads directly into the unguarded dereference.
---
## PoC
Call compress_get_error(NULL).
Confirmed output:
AddressSanitizer: SEGV on address 0x0 ... compress.c:81.
---
## Impact
Any failed compress device open (device busy, absent, or invalid card/device number) causes the calling utility to crash while trying to report the error, rather than exiting cleanly. This is trivially reached in normal operation and results in a denial of service of the calling process; it does not expose memory contents or allow code execution.
---
## Suggested Remediation
Add a NULL guard for compress inside compress_get_error() and compress_close(), and/or avoid calling them with a NULL compress pointer from cplay/crecord/fcplay.

Greetings ALSA Security Team,

This is the *second outreach* attempt for this case. Has there been any movement or can you provide any updates on the progress?

Thank you,

Thank you,

<https://www.vulncheck.com/>

Brandon Tarr
VulnCheck

Fixed in commits bellow:

https://github.com/alsa-project/tinycompress/commit/f42b48ac81382b9c595aaeb5117456d87abe14da
https://github.com/alsa-project/tinycompress/commit/87549f397f0cb533c8e2491e8ff781958bdedd36

Jaroslav

Jaroslav Kysela <[email protected]>
Linux Sound Maintainer; ALSA Project; Red Hat