CVE-2026-99037 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-crypt: reject the lmk IV mode with AEAD ciphers
A "capi:" table line that pairs an AEAD cipher with the lmk IV mode, for example "capi:gcm(aes)-lmk" with the integrity:28:aead option, causes an oops when it is loaded. lmk sets tfms_count to 64, but crypt_alloc_tfms_aead only allocates one transform, so crypt_setkey reads past the end of the tfms_aead array and calls crypto_aead_setkey on the values it finds there.
lmk exists for compatibility with Loop-AES, which uses CBC, so refuse it with an AEAD cipher rather than allocate 64 AEAD transforms. The check cannot go in crypt_iv_lmk_ctr with the other lmk checks, because the IV constructor runs after crypt_set_key.
Note that this is not a security bug because the memory corruption can only be triggered by root.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The Linux kernel's device-mapper encryption subsystem, specifically dm-crypt, contains a critical implementation flaw related to the initialization of authentication-encrypted data (AEAD) ciphers when paired with the lmk initialization vector mode. This vulnerability manifests as a kernel oops or panic during the loading of specific cryptographic configurations that combine an AEAD cipher, such as GCM-AES via the CAPI interface, with the legacy lmk IV generation method. The root cause lies in a mismatch between memory allocation and usage expectations within the crypt_alloc_tfms_aead function versus the subsequent key setting operations performed by crypt_setkey. Specifically, the lmk mode is designed for compatibility with older Loop-AES implementations that rely on CBC encryption modes, where it sets the tfms_count variable to sixty-four to accommodate multiple transform objects required for parallel processing or specific legacy behaviors. However, when an AEAD cipher is selected, the allocation routine crypt_alloc_tfms_aead only allocates space for a single transform object rather than the array of sixty-four implied by the lmk configuration.
This discrepancy leads directly to a heap-based buffer overflow during the key setup phase. When crypt_setkey executes, it iterates through the expected number of transforms based on tfms_count and attempts to call crypto_aead_setkey for each entry in the tfms_aead array. Because only one transform was allocated but sixty-four are accessed, the function reads past the end of the valid memory region. This out-of-bounds access results in undefined behavior, typically causing a kernel crash or oops due to accessing invalid pointers or corrupted data structures located beyond the allocated buffer boundary. The vulnerability is triggered specifically when an administrator attempts to load a device-mapper table that specifies this incompatible combination, such as capi:gcm(aes)-lmk with integrity options enabled for AEAD processing.
From a security perspective, while the technical nature of the flaw constitutes a memory corruption issue akin to CWE-125 Out-of-bounds Read or CWE-787 Out-of-bounds Write depending on subsequent writes, it is classified as having limited practical exploitability in most standard deployment scenarios. The vulnerability requires root privileges to trigger because loading and configuring device-mapper encryption tables is an operation restricted to the superuser. Consequently, this aligns with ATT&CK technique T1068 Exploitation for Privilege Escalation, where an attacker would need prior administrative access to manipulate kernel cryptographic parameters. Therefore, while it represents a significant stability risk that can lead to denial of service through system crashes, it does not inherently provide a path for privilege escalation from unprivileged user space unless combined with other vulnerabilities or misconfigurations that allow lower-privilege users to influence device-mapper configurations.
The resolution involves modifying the dm-crypt initialization logic to explicitly reject the combination of AEAD ciphers with the lmk IV mode before any memory allocation occurs. By refusing this configuration at the control stage rather than during key setup, the kernel prevents the invalid state from ever being established. This fix acknowledges that lmk is a legacy feature intended for CBC-based workflows and has no valid use case in modern authenticated encryption contexts where integrity protection is handled by AEAD modes themselves. Administrators relying on dm-crypt with authentication should ensure they are using IV generation methods compatible with their chosen cipher suite, such as essiv or plain64, rather than the legacy lmk mode when employing algorithms like AES-GCM or AES-CCM via hardware acceleration interfaces.