CVE-2026-68148: Linux Kernel Use-After-Free Vulnerability

CVE-2026-68148 Overview

CVE-2026-68148 is a use-after-free vulnerability in the Linux kernel's fscrypt subsystem. The flaw resides in the find_or_insert_direct_key() function, which manages the legacy fscrypt_direct_keys table used by v1 encryption policies with the FSCRYPT_POLICY_FLAG_DIRECT_KEY flag set. The function fails to compare the super_block pointer when locating an existing direct key, allowing inodes from different filesystems to reference the same fscrypt_direct_key structure. This can extend a key's lifetime beyond its associated super_block, producing a use-after-free condition. The issue does not affect v2 policies, which store per-mode keys within super_block::s_master_keys.

Critical Impact
A local authenticated attacker with access to filesystems using v1 fscrypt direct-key policies can trigger a kernel use-after-free, leading to memory corruption, privilege escalation, or denial of service.

Affected Products

Linux kernel builds containing fscrypt v1 encryption policy support with FSCRYPT_POLICY_FLAG_DIRECT_KEY
Filesystems relying on fscrypt v1 direct-key policies (for example, ext4, F2FS, UBIFS)
Distributions shipping kernels prior to the fixed stable releases

Discovery Timeline

2026-08-10 - CVE-2026-68148 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68148

Vulnerability Analysis

The fscrypt_direct_keys table is a global cache that stores master keys used by v1 encryption policies configured with the direct-key flag. This table is intentionally global because keys can be supplied through the legacy process-subscribed keyring mechanism, which does not lend itself to per-super_block storage in super_block::s_master_keys.

Each struct fscrypt_direct_key embeds a super_block pointer so that fscrypt_destroy_inline_crypt_key() can be invoked when the last referencing inode is evicted. However, the lookup logic in find_or_insert_direct_key() compared only the key material and mode, omitting the super_block field. As a result, an inode belonging to one filesystem could reuse a fscrypt_direct_key originally associated with a different filesystem's super_block.

When the original filesystem is unmounted, its super_block is freed, but the cached key entry retains the dangling pointer. Subsequent operations that dereference the pointer, including inline crypt key destruction, access freed memory. The patch resolves the issue by ensuring lookups only match entries whose super_block pointer equals the current inode's super_block, creating distinct fscrypt_direct_key structures per filesystem.

Root Cause

The root cause is a missing equality check on the super_block pointer inside find_or_insert_direct_key(). The function's key-matching predicate was insufficient to isolate keys per filesystem, violating the lifetime assumption that a cached key's super_block remains valid for as long as the entry exists.

Attack Vector

Exploitation requires local access and the ability to mount filesystems or trigger operations against filesystems using v1 fscrypt policies with the direct-key flag. An attacker sharing an identical raw master key across two super_block instances, then unmounting one while inodes on the other continue to reference the cached entry, can drive the kernel into a use-after-free path. Successful exploitation can yield kernel memory corruption suitable for privilege escalation.

No public proof-of-concept exploit is currently available, and this issue is not listed in the CISA Known Exploited Vulnerabilities catalog. Refer to the upstream fix commits for exact patch context, including commit 33024960 and commit b5fa4022.

Detection Methods for CVE-2026-68148

Indicators of Compromise

Kernel oops or panic messages referencing fscrypt_destroy_inline_crypt_key, fscrypt_direct_key, or find_or_insert_direct_key in dmesg or /var/log/kern.log
KASAN reports flagging use-after-free reads or writes within fscrypt code paths on kernels with KASAN enabled
Unexpected filesystem unmount failures or crashes on systems using v1 fscrypt policies with the direct-key flag

Detection Strategies

Inventory kernels across the fleet and flag hosts running unpatched versions that expose fscrypt v1 direct-key policies
Audit filesystem creation and mount operations to identify use of FSCRYPT_POLICY_FLAG_DIRECT_KEY, which is uncommon in modern deployments
Correlate kernel crash telemetry with mount and unmount events on filesystems configured with fscrypt v1 policies

Monitoring Recommendations

Forward kernel logs to a centralized logging pipeline and alert on fscrypt-related stack traces or KASAN findings
Monitor unprivileged mount, keyctl, and add_key syscall activity from non-administrative users
Track process behavior on multi-tenant Linux hosts for repeated crash-and-restart patterns that suggest exploitation attempts

How to Mitigate CVE-2026-68148

Immediate Actions Required

Apply the fixed kernel package from your Linux distribution as soon as it is available and reboot affected systems
Restrict local shell access on multi-tenant systems until patching is complete
Migrate encrypted directories from v1 policies to v2 policies where feasible, since v2 per-mode keys are not affected

Patch Information

The fix has been merged into the upstream Linux kernel and backported to stable trees. Relevant commits include commit 33024960, commit 466f187b, commit 95376fe9, commit b5fa4022, and commit deff4189. Consult your distribution's security advisories for the corresponding package versions.

Workarounds

Avoid using v1 fscrypt policies with the FSCRYPT_POLICY_FLAG_DIRECT_KEY flag on shared or unpatched systems
Use v2 fscrypt policies, which manage master keys per super_block and are not exposed to this flaw
Limit which users can mount filesystems and add keys via the process-subscribed keyring mechanism

bash

# Verify running kernel version and check for the fix
uname -r

# Enumerate fscrypt policies on a target directory (requires fscryptctl or fscrypt tool)
fscryptctl get_policy /path/to/encrypted/dir

# Prefer v2 policies when setting new policies
fscryptctl set_policy --version=2 <key_identifier> /path/to/dir