CVE-2026-80832 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: qce - fix CCM AAD buffer underallocation
The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist.
The allocation size is currently calculated as:
ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN
while the DMA length is set to:
ALIGN(assoclen + adata_header_len, 16)
Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2:
allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48
As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as:
alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8
Fix the allocation by adding the maximum possible AAD header length before alignment:
ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16)
This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the Linux kernel's Qualcomm Crypto Engine (QCE) driver represents a critical memory safety flaw within the implementation of the CCM authenticated encryption mode with CBC-MAC. This issue stems from an incorrect calculation of buffer allocation size relative to the actual data length programmed into the Direct Memory Access scatterlist. In cryptographic operations, particularly those involving hardware accelerators like the QCE engine, precise alignment and sizing of input buffers are paramount for both security and functional correctness. The specific function qce_aead_ccm_prepare_buf_assoclen is responsible preparing the associated data buffer but fails to account for how padding interacts with addition when determining memory requirements. This discrepancy creates a scenario where the hardware reads beyond the bounds of the allocated kernel memory, leading to undefined behavior that manifests as cryptographic failures rather than immediate system crashes or exploitable code execution in most standard configurations due to the nature of the operation being performed on non-sensitive control paths during self-tests.
The technical root cause lies in the mathematical properties of alignment functions used in C programming and Linux kernel development. The original allocation logic utilized ALIGN(assoclen, 16) plus a constant header length MAX_CCM_ADATA_HEADER_LEN to determine buffer size. However, the DMA engine was programmed with a length derived from ALIGN(assoclen + adata_header_len, 16). Because alignment is not distributive over addition, these two values can diverge significantly depending on the input lengths. For instance, if the associated data length is exactly aligned to sixteen bytes and additional header data requires padding up to the next multiple of sixteen, the DMA engine will request access to more memory than was allocated. In a concrete example where assoclen equals thirty-two bytes and the actual header length is two bytes with a maximum possible header size of six bytes, the allocation results in thirty-eight bytes while the hardware attempts to read forty-eight bytes. This mismatch means that five extra bytes are included in the CBC-MAC computation from uninitialized or unrelated memory regions adjacent to the buffer.
The operational impact of this vulnerability primarily affects the integrity and authenticity guarantees provided by CCM mode encryption. Since the QCE hardware incorporates these out-of-bounds bytes into the authentication tag calculation, the resulting cryptographic digest will be incorrect even if the actual plaintext and ciphertext are processed correctly. This leads directly to verification failures during self-tests and potentially in production environments where associated data is used for integrity checks such as packet headers or protocol metadata. The error manifests as a mismatch between expected and computed tags, causing legitimate connections or operations to fail authentication checks. While this does not typically allow an attacker to decrypt data or execute arbitrary code directly through the crypto API itself, it undermines trust in the security subsystem by producing false negatives for integrity verification. In scenarios where automated systems rely on these self-tests for health monitoring, such failures could trigger unnecessary service restarts or alerting mechanisms, impacting availability and operational stability.
From a classification perspective, this vulnerability aligns with CWE-131: Incorrect Calculation of Buffer Size, which describes errors in determining the size required to store data without considering edge cases involving padding or alignment boundaries. It also relates closely to CWE-787: Out-of-bounds Write if one considers that writing incorrect derived values into authentication structures constitutes a form of state corruption within the cryptographic context. Furthermore, while not an exploitation vector for remote code execution in this specific instance due to the nature of crypto self-tests and kernel-space isolation, it falls under ATT&CK technique T1499: Endpoint Denial of Service if leveraged to cause persistent service degradation through repeated authentication failures. The flaw highlights a common pitfall in systems programming where assumptions about arithmetic operations on aligned data structures are not rigorously validated against hardware specifications.
To mitigate this vulnerability, the allocation logic must be corrected to ensure that sufficient memory is reserved for all potential padding requirements before alignment is applied. The fix involves changing the calculation from ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN to ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16). This approach guarantees that the buffer size accounts for the maximum possible header length prior to rounding up to the nearest multiple of sixteen bytes. By performing addition before alignment, developers ensure that even if assoclen is already aligned, any additional data requiring padding will still result in a correctly sized allocation. This adjustment prevents the hardware from accessing memory outside the allocated region and ensures that only valid associated data contributes to the CBC-MAC computation. Maintaining strict parity between buffer allocation sizes and DMA transfer lengths is essential for maintaining both security integrity and functional reliability in kernel-level cryptographic implementations.