CVE-2026-89607

What it actually does

The eCryptfs Tag 3 packet parser accepted an unbounded encrypted_key_size and, on the passphrase path with AES-192, used that length for kernel decryption and memcpy. That produces two out-of-bounds writes: crypto_skcipher_decrypt overflows the 64-byte decrypted_key buffer into the parent ecryptfs_auth_tok, and memcpy overflows crypt_stat->key, corrupting adjacent kernel fields (root_iv, keysig_list, and mutexes). The result is kernel memory corruption with possible oops/panic, local privilege escalation, or further kernel-object corruption. The PKI (Tag 65) path already enforced ECRYPTFS_MAX_KEY_BYTES; this flaw was the missing equivalent check.

Why it matters to the business

A logged-in user on a Linux host that uses eCryptfs can crash the machine or potentially take full control of it, taking encrypted-home and other eCryptfs workloads offline and putting host confidentiality and integrity at risk. Impact is highest on shared, multi-user, and jump-host systems. There is no CISA KEV listing, no reported ransomware use, and no public exploit 36 days after publication, so urgency is driven by local kernel compromise potential rather than mass remote attacks. Hosts that never load eCryptfs are not exposed.

How an attack unfolds

A local attacker who can cause the kernel to parse an eCryptfs header supplies a Tag 3 packet that selects AES-192 (cipher code 0x08) and sets encrypted_key_size above 64 bytes. parse_tag_3_packet() records that size without clamping it. decrypt_passphrase_encrypted_session_key() then decrypts into a 64-byte buffer and copies decrypted_key_size bytes into crypt_stat->key, overflowing into neighboring fields. AES-192 is required because it sets crypt_stat->key_size independently so setkey succeeds while the packet size still exceeds the buffer. The attacker needs only local access and the ability to mount or open the crafted eCryptfs object; no remote service or extra user interaction is required. Successful corruption typically appears as a kernel oops or, depending on layout and timing, as elevated privileges. No named threat actors or in-the-wild campaigns are associated with this issue.

How to fix it

Install the Linux kernel update that rejects oversized encrypted_key_size in parse_tag_3_packet by bounding it to ECRYPTFS_MAX_KEY_BYTES (64) and reboot into the patched kernel. Use your distribution’s kernel security advisory or stable-tree backport that contains this eCryptfs change; no product-specific fixed version list was supplied with this record, so treat any kernel still containing the unbounded parse as vulnerable. If you cannot patch immediately, prevent untrusted users from using eCryptfs: unload/blacklist the ecryptfs module, remove eCryptfs fstab/systemd mounts, and restrict CAP_SYS_ADMIN/mount rights. AES-192 eCryptfs configurations are the enabling path and should be patched or disabled first.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory includes the parse_tag_3_packet bound to ECRYPTFS_MAX_KEY_BYTES, then reboot and verify uname -r matches that package. Check that lsmod/modinfo ecryptfs reflects the updated module and that legitimate eCryptfs mounts still work. Systems with no ecryptfs in /proc/filesystems, lsmod, fstab, or systemd mount units are out of scope. Do not validate by feeding oversized Tag 3 packets on production hosts.

Typical attack path

1. Gain a local unprivileged account on a Linux system that can use eCryptfs
2. Present a Tag 3 packet that uses AES-192 and an encrypted_key_size greater than 64 bytes
3. Trigger kernel parse/decrypt of that packet (eCryptfs mount or open of the encrypted file/tree)
4. Cause out-of-bounds writes into ecryptfs_auth_tok and ecryptfs_crypt_stat
5. Use the resulting kernel memory corruption for a host crash (oops/panic) or local privilege escalation

How to detect it

This is local kernel memory corruption with no public exploit, so look for crashes and local mount activity rather than network callbacks. Search dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and kdump/vmcore for oops/BUG/panic traces naming eCryptfs functions (parse_tag_3_packet, decrypt_passphrase_encrypted_session_key) or list/mutex corruption under ecryptfs_crypt_stat. Correlate unexpected reboots with eCryptfs mount or file-open events. Review audit logs for unprivileged users mounting type=ecryptfs or introducing new encrypted trees shortly before a crash. Missing persistent kernel logs after a reboot does not prove the bug was unused.

• parse_tag_3_packet
• decrypt_passphrase_encrypted_session_key
• ecryptfs_crypt_stat
• Oops:.*ecryptfs
• Call Trace:.*ecryptfs_
• BUG:.*ecryptfs
• unable to handle kernel.*ecryptfs
• mount.*type=ecryptfs
• fstype=ecryptfs
• modprobe ecryptfs

What your security team should do

• Patch and reboot hosts that load ecryptfs or mount eCryptfs filesystems; this is a local high-impact kernel memory-corruption bug
• Inventory eCryptfs usage (module, fstab, systemd mounts, encrypted home directories) to rank exposure
• If patching is delayed, blacklist ecryptfs and block new eCryptfs mounts for untrusted users
• Hunt kernel logs and crash dumps for historical eCryptfs oopses; there is no KEV listing or public exploit, so treat confirmed crashes as high-priority forensics rather than assumed mass compromise
• Do not prioritize this as a remotely wormable issue; focus on multi-user and shared Linux hosts