CVE-2026-89607 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet
parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes:
1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent
ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and
mutexes in ecryptfs_crypt_stat.
Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES.
The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check.
Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte
check is removed as redundant.
[tyhicks: Adjust the code comment to refer to macros representing the
buffer sizes rather than mentioning the buffer size values since they may change in the future]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified within the Linux kernel's eCryptfs implementation stems from a critical input validation failure in the parse_tag_3_packet function. This specific code path is responsible for processing Tag 3 packets, which are part of the OpenPGP message format used to encapsulate encrypted session keys during passphrase-based decryption operations. The core technical flaw lies in the absence of bounds checking on the encrypted_key_size field extracted from the packet body. Specifically, the kernel fails to verify that this size value does not exceed ECRYPTFS_MAX_KEY_BYTES, which is defined as sixty-four bytes. This oversight allows an attacker or a malformed input source to supply a key size significantly larger than what the underlying cryptographic buffers and structures are designed to accommodate, leading directly to memory corruption issues when subsequent decryption routines attempt to process the oversized data.
The operational impact of this flaw manifests through two distinct out-of-bounds write operations that occur during the execution of decrypt_passphrase_encrypted_session_key. First, the function assigns the unchecked encrypted_key_size to decrypted_key_size and proceeds to call crypto_skcipher_decrypt. This cryptographic routine writes the specified number of bytes into a local buffer named decrypted_key, which is statically allocated with only sixty-four bytes of space. When the input size exceeds this limit, the write operation overflows beyond the boundaries of decrypted_key, spilling data into adjacent memory regions belonging to the parent ecryptfs_auth_tok structure. This initial corruption compromises the integrity of authentication tokens and associated metadata stored in that stack frame or heap allocation, depending on the specific context of the call.
The second stage of exploitation involves a subsequent memcpy operation where the kernel copies decrypted_key_size bytes from the now-corrupted buffer into crypt_stat->key. The target array is also limited to sixty-four bytes. Consequently, this write corrupts critical fields within the ecryptfs_crypt_stat structure, including root_iv, keysig_list, and various mutexes used for synchronization. Corruption of these structures can lead to severe system instability, potential privilege escalation if an attacker can control the overwritten data to manipulate kernel logic or pointers, and denial of service through crashes or undefined behavior in subsequent cryptographic operations that rely on the integrity of these state variables.
This vulnerability is specifically exploitable when AES-192 encryption is utilized, identified by cipher code 0x08. The reason for this specific dependency lies in how the kernel handles key sizes for different algorithms. For AES-192, the crypt_stat->key_size is set to twenty-four bytes independently of the encrypted_key_size value provided in the packet. This discrepancy allows crypto_skcipher_setkey to succeed because it validates against the actual algorithmic requirement rather than the potentially malicious input size. In contrast, other cipher configurations might fail earlier or handle sizes differently, making AES-192 the primary vector for this specific out-of-bounds write scenario due to its permissive key setup logic combined with the lack of upper-bound validation on the packet data.
From a standards perspective, this vulnerability is classified under CWE-787: Out-of-Bounds Write, as it involves writing data beyond the allocated buffer boundaries, leading to memory corruption and potential code execution or system crash. It also aligns with CWE-20: Improper Input Validation, since the root cause is the failure to properly validate the size of input data against expected constraints before processing. In terms of attack vectors, this relates to ATT&CK technique T1564.003: Hidden Window or Process, as an attacker might attempt to hide malicious activity by exploiting kernel-level memory corruption, although more broadly it represents a local privilege escalation path if the vulnerability can be triggered with sufficient privileges or through crafted filesystem images mounted by privileged processes.
The remediation strategy implemented in the fix involves strictly bounding encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES rather than the larger ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES value of five hundred and twelve bytes. This adjustment ensures that only keys fitting within the sixty-four-byte limit are processed, thereby preventing the overflow conditions described earlier. The previous check limiting size to five hundred and twelve bytes is removed as redundant because it did not prevent writes exceeding the actual buffer capacity of sixty-four bytes used in critical operations. By enforcing a tighter constraint consistent with the maximum key length for supported symmetric ciphers like AES-256, the kernel ensures that all subsequent memory allocations and copies remain within safe boundaries.
This fix also highlights an inconsistency in validation logic across different decryption paths within eCryptfs. The PKI decryption path, handled by parse_tag_65_packet, already includes a check to ensure decrypted_key_size does not exceed ECRYPTFS_MAX_KEY_BYTES. However, the passphrase-based path lacked this safeguard until now. Aligning these two code paths ensures consistent security postures regardless of whether keys are encrypted via public key infrastructure or symmetric passphrases. The inclusion of comments referencing macros rather than hardcoded values further enhances maintainability and future-proofing against changes in buffer sizes, ensuring that developers explicitly understand the constraints imposed by cryptographic standards on kernel memory management.