CVE-2026-72300 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: topology: validate vendor array size before parsing
sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available.
Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size.
The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below.
Cast sizeof(*array) to int when validating the declared array size. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides within the Linux kernel's sound subsystem specifically in the SOF (Sound Open Firmware) topology parsing functionality where improper validation of vendor array sizes can lead to potential exploitation. This issue affects the sof_parse_token_sets() function which processes topology private data during audio device configuration. The flaw occurs during iteration over topology data structures where the parser reads array->size without first ensuring that sufficient data remains to properly parse a complete snd_soc_tplg_vendor_array header structure.
The technical implementation flaw stems from inadequate bounds checking in the parsing loop condition which only verifies that some data exists rather than confirming that complete header structures are available before reading field values. When processing malformed topology files containing truncated vendor arrays, the parser attempts to read the size field before a full vendor-array header has been properly consumed from memory. This creates a potential for out-of-bounds memory access patterns that could be exploited by malicious actors to manipulate kernel memory or execute arbitrary code.
This vulnerability directly relates to CWE-129 Input Validation and CWE-787 Out-of-bounds Read, both of which are commonly exploited in kernel space attacks targeting buffer management flaws. The issue falls under the ATT&CK technique T1068 Exploitation for Privilege Escalation and T1547.001 Registry Run Keys/Startup Folder where successful exploitation could allow an attacker to gain elevated privileges through kernel memory corruption.
The operational impact of this vulnerability extends beyond simple parsing errors as it represents a potential pathway for privilege escalation attacks within the Linux audio subsystem. Attackers could craft malicious topology files that, when loaded by the system, trigger the out-of-bounds read condition and potentially lead to denial of service or code execution in kernel space. The vulnerability is particularly concerning in embedded systems or devices where audio configuration files might be processed from untrusted sources.
Mitigation strategies should focus on implementing proper bounds checking before any field access operations within the topology parser. The fix requires validating that sufficient private data remains to contain a complete snd_soc_tplg_vendor_array header structure before attempting to read array->size. Additionally, the size validation logic must preserve signed comparison semantics by casting sizeof(*array) to int when comparing against asize values.
Security implementations should also consider implementing stricter input validation for all topology files and potentially adding kernel memory protection mechanisms such as stack canaries or memory sanitization routines. The fix addresses both the immediate parsing issue and prevents potential integer underflow scenarios that could bypass size checks due to type promotion behavior between int and size_t types. These defensive measures align with secure coding practices recommended in the Linux kernel security guidelines and help prevent similar vulnerabilities from occurring in other parser implementations within the same subsystem.