CVE-2026-68148

What it actually does

CVE-2026-68148 is a Linux kernel use-after-free flaw in fscrypt legacy v1 direct-key handling. The global fscrypt_direct_keys cache failed to compare the filesystem super_block pointer when reusing a cached direct key. As a result, encrypted inodes from different mounted filesystems using v1 encryption policies with FSCRYPT_POLICY_FLAG_DIRECT_KEY could share the same fscrypt_direct_key object. If one filesystem superblock is later torn down while another inode still references the shared key object, the stale super_block pointer can be used during fscrypt_destroy_inline_crypt_key(), potentially causing kernel memory corruption, kernel crash, or, depending on exploitability and kernel hardening, privilege escalation from local code execution.

Why it matters to the business

The most likely operational impact is host instability or crashes on Linux systems using fscrypt legacy v1 direct-key encryption across multiple filesystems. In higher-risk scenarios, a local attacker with the ability to create, mount, or interact with affected encrypted filesystems could attempt to turn the kernel memory corruption into elevated privileges. The issue is newly published, not known to be in CISA KEV, not associated with ransomware campaigns, and has no reported public exploit maturity, so urgency is lower than for actively exploited kernel flaws; however, kernel vulnerabilities should still be prioritized for systems that permit local users, containers, removable media, or untrusted filesystem images.

How an attack unfolds

An attacker would need local interaction with an affected Linux kernel and access to functionality that exercises fscrypt legacy v1 direct-key encryption. They would arrange for multiple encrypted filesystems or superblocks to use v1 fscrypt policies with FSCRYPT_POLICY_FLAG_DIRECT_KEY such that the kernel incorrectly reuses a cached fscrypt_direct_key object across different superblocks. The attacker would then trigger teardown of one filesystem or eviction paths while another inode still references the shared key object, leaving the key object with a pointer to a freed super_block. A later fscrypt cleanup path can dereference that stale pointer in fscrypt_destroy_inline_crypt_key(), producing a use-after-free condition. In practical terms, exploitation is likely local and configuration-dependent; the immediate observable outcome may be a kernel oops, panic, or filesystem-related crash, while reliable privilege escalation would require additional exploit development against the specific kernel build and mitigations.

How to fix it

Upgrade to a Linux kernel version that includes the fscrypt fix adding the missing superblock comparison in find_or_insert_direct_key(), ensuring distinct fscrypt_direct_key structures are created per super_block. Because no specific distribution package names or fixed versions were provided, use vendor advisories for the relevant Linux distribution, appliance, container host, hypervisor host, or embedded kernel and install the first kernel build that backports this fix. Reboot into the patched kernel and verify the running kernel version, not just the installed package version. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting the ability to mount filesystems or use removable/untrusted filesystem images, disabling or avoiding legacy fscrypt v1 direct-key policies where feasible, preferring fscrypt v2 policies, and applying standard kernel hardening and least-privilege controls around containers and user namespaces.

How to confirm the fix worked

Confirm exposure by checking whether systems run a Linux kernel version that predates the vendor fix and whether fscrypt is in use with legacy v1 policies using the direct-key flag. Validate remediation by verifying the running kernel after reboot with uname or distribution package tools and confirming the vendor changelog references the fscrypt direct-key superblock check or find_or_insert_direct_key() fix. Where source validation is possible, confirm the fs/crypto key-management code compares the super_block when locating or inserting fscrypt_direct_key entries. Functional validation should include mounting and using fscrypt-enabled filesystems after patching and confirming there are no kernel oops, panic, or fscrypt-related errors during encrypted filesystem mount, access, inode eviction, and unmount operations.

Typical attack path

1. Gain local ability to run code or otherwise interact with filesystem mount/encryption operations on a vulnerable Linux system.
2. Create, mount, or access multiple fscrypt-enabled filesystems using legacy v1 encryption policies with FSCRYPT_POLICY_FLAG_DIRECT_KEY.
3. Cause inodes from different superblocks to reference what the vulnerable kernel treats as the same cached fscrypt_direct_key entry.
4. Unmount, evict, or otherwise tear down one filesystem/superblock while another inode still holds a reference to the shared key object.
5. Trigger fscrypt key destruction or inline crypto cleanup that uses the stale super_block pointer.
6. Cause a kernel crash or attempt to shape the use-after-free into local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel logs, persistent journal logs, crash dumps, and endpoint telemetry. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel entries, pstore/ramoops, kdump/vmcore artifacts, audit logs for mount and unmount activity, and EDR telemetry for privileged mount or loop-device operations. Focus on crashes or warnings around fscrypt direct-key handling, encrypted filesystem mount/unmount activity, inode eviction, and inline crypto key destruction. Search for kernel oops, BUG, KASAN, KFENCE, or general-protection-fault reports that include fscrypt functions such as find_or_insert_direct_key() or fscrypt_destroy_inline_crypt_key(). Correlate these events with recent local user activity, container escape attempts, use of CAP_SYS_ADMIN, loopback-mounted disk images, removable media, or repeated mounting/unmounting of encrypted filesystems. Because no public exploit indicators or threat actors are currently reported, detection should be behavior- and crash-artifact-based rather than relying on a known malicious payload signature.

• fscrypt_destroy_inline_crypt_key
• find_or_insert_direct_key
• fscrypt_direct_key
• fscrypt_direct_keys
• FSCRYPT_POLICY_FLAG_DIRECT_KEY
• BUG: KASAN: use-after-free
• KASAN: use-after-free in fscrypt
• KFENCE: use-after-free
• general protection fault
• kernel BUG at fs/crypto
• Oops:
• RIP: 0010:fscrypt_destroy_inline_crypt_key
• RIP: 0010:find_or_insert_direct_key
• use-after-free
• super_block
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• /proc/vmcore

What your security team should do

• Inventory Linux systems that use fscrypt, especially servers, mobile/embedded Linux devices, container hosts, developer workstations, and systems that process removable or untrusted filesystem images.
• Prioritize patching systems where untrusted local users, containers, build jobs, forensic tooling, removable media, or disk-image processing can exercise filesystem mount or encryption paths.
• Track distribution and appliance vendor advisories for the backported kernel fix, then deploy and reboot into the fixed kernel.
• Prefer fscrypt v2 policies over legacy v1 direct-key policies where operationally feasible.
• Restrict mount capabilities, loop-device access, privileged containers, CAP_SYS_ADMIN, user namespaces, and access to untrusted block devices until patching is complete.
• Monitor for kernel oops, panic, KASAN, or BUG messages involving fscrypt, find_or_insert_direct_key, fscrypt_destroy_inline_crypt_key, super_block, or use-after-free.
• Treat unexplained crashes in fscrypt-enabled environments as potentially security-relevant and preserve kernel logs, crash dumps, and recent mount/encryption activity for investigation.