CVE-2026-89605

What it actually does

A resource-management defect in the Linux kernel eCryptfs messaging path leaks message-context objects. ecryptfs_send_message_locked() moves a context from the free list onto the allocated list before calling ecryptfs_send_miscdev(); if that send fails, the context is not returned to the free list and the caller pointer is not cleared, so the slot can never be reused. Repeated failures exhaust the finite context pool and cause subsequent eCryptfs daemon communication—and therefore encrypted-filesystem operations that depend on it—to fail. The vector is local with low privileges (AV:L/PR:L). Despite a CVSS 7.8 vector that scores confidentiality, integrity, and availability as High, the described flaw is a kernel object leak that produces denial of service of eCryptfs rather than a demonstrated memory-corruption or code-execution primitive.

Why it matters to the business

Linux hosts that use eCryptfs (encrypted home directories, private directories, or other stacked encrypted mounts) can lose the ability to perform encrypted-file operations, disrupting users and applications that depend on those mounts. Any local low-privileged account is enough to drive the leak, so shared workstations, jump hosts, multi-user servers, and other systems that offer shell access carry more operational risk than tightly locked-down single-user machines. The CVE is not in CISA KEV, is not tied to ransomware, has exploit maturity None, and has no named in-the-wild use 36 days after publication, so it is not an emergency mass-exploitation event—but High-severity local kernel DoS still warrants timely kernel updates wherever eCryptfs is present or loadable.

How an attack unfolds

An attacker who already has an unprivileged local login on a Linux system where eCryptfs is built, loaded, or mountable induces repeated failures of kernel-to-userspace message sends (for example by disrupting the eCryptfs userspace daemon or the misc-device channel while driving eCryptfs operations). Each failed send permanently consumes a message context. Once the pool is exhausted, legitimate eCryptfs messaging fails and encrypted mounts stop servicing cryptographic requests, producing a local denial of service. There is no network-facing vector in the advisory, no public exploit, and no associated APT or ransomware campaign.

How to fix it

Install a Linux kernel that includes the eCryptfs fix which, on ecryptfs_send_miscdev() failure, moves the message context back to the free list and clears the caller pointer. This record does not list distro package versions; use the vendor advisory for the kernel you run (distribution linux-image/kernel RPMs or a stable/mainline tree that contains the ecryptfs send-failure cleanup) and reboot onto the new kernel. If eCryptfs is not required, mitigate by blacklisting the ecryptfs module, ensuring it is not loaded, and not mounting type=ecryptfs filesystems. Restrict local interactive access on hosts that must keep eCryptfs. There is no complete configuration-only fix on an unpatched kernel.

How to confirm the fix worked

Verify the running kernel package against the distribution or upstream advisory that mentions the eCryptfs message-context release on send failure, then reboot and confirm uname/package versions. Inventory exposure: whether the ecryptfs module is loaded, whether /dev/ecryptfs exists, and whether any mounts are type ecryptfs. Treat a host as exposed if a vulnerable kernel can load eCryptfs even when no encrypted mount is currently active. After patching, re-check that eCryptfs mounts (if still used) operate normally and that kernel logs no longer show persistent messaging-pool exhaustion under failed-send conditions.

Typical attack path

1. Obtain a local unprivileged account on a Linux host where the eCryptfs kernel code is present (module loaded or built-in) and usable.
2. Create conditions under which ecryptfs_send_miscdev() fails, such as an unavailable or unresponsive userspace daemon or a blocked /dev/ecryptfs channel.
3. Repeatedly exercise eCryptfs operations that allocate a message context and attempt to send it to userspace.
4. Allow leaked contexts to remain on the allocated list until the free pool is exhausted.
5. Cause subsequent eCryptfs daemon communication and encrypted-filesystem operations to fail, denying service to those mounts.

How to detect it

No public exploit or named actor activity is associated with this issue, so hunt for local resource-exhaustion of eCryptfs rather than a unique implant. Review kernel logs (dmesg, journalctl -k, distro kern.log) for repeated eCryptfs daemon send failures around suspected abuse. Check for crashes, restarts, or absence of the eCryptfs userspace daemon, unexpected opens of /dev/ecryptfs, and sudden failures or hangs of eCryptfs mounts. Correlate with local authentication and session logs to see which unprivileged accounts were active. The leak itself lives in kernel memory and does not drop distinctive files, registry keys, or network beacons; lack of those artifacts does not rule out attempted abuse.

• Error attempting to send message to userspace daemon
• /dev/ecryptfs
• ecryptfsd
• type=ecryptfs
• Failed to find daemon for euid

What your security team should do

• Patch and reboot kernels first on multi-user hosts that load eCryptfs or mount encrypted home/private directories.
• Where eCryptfs is unused, blacklist the ecryptfs module to remove the code path.
• Because this is not KEV and has no known exploit, fold it into the normal high-severity kernel cycle unless eCryptfs is business-critical on shared systems.
• Reduce unnecessary local logins and unprivileged shell access; the attack requires a local account.
• Watch kernel and eCryptfs daemon logs for repeated send failures and sudden encrypted-mount errors before and after patching.