CVE-2026-68147

What it actually does

This is a Linux kernel use-after-free flaw in the fscrypt inline encryption path. When an fscrypt block crypto key is destroyed, the kernel calls fscrypt_get_devices() to enumerate block devices and evict the key from each device. The vulnerable implementation used a dynamically allocated device-pointer array; if that allocation failed, particularly during inode eviction under direct memory reclaim, fscrypt_destroy_inline_crypt_key() could zeroize and free the blk_crypto_key without first calling blk_crypto_evict_key(). A later block crypto operation could then reference the freed key object, causing kernel memory corruption. The issue is most relevant to filesystems using fscrypt inline encryption with multi-device support, currently described as f2fs with a hardcoded limit of eight block devices.

Why it matters to the business

Successful exploitation could crash affected Linux systems or potentially allow kernel-level memory corruption, which may lead to denial of service and, depending on exploitability in a given kernel build and configuration, possible privilege escalation. Systems using encrypted filesystems with inline block-layer encryption are the primary concern. The vulnerability is recently published, is not currently listed in CISA KEV, is not marked as ransomware-used, and has no stated public exploit maturity, but kernel memory safety flaws should still be prioritized for routine patching because exploitability can change quickly after patch details are available.

How an attack unfolds

An attacker would need a path to influence filesystem activity that creates, uses, evicts, or destroys fscrypt inline-encryption keys on an affected Linux kernel. The attacker attempts to drive the system into a low-memory or direct-reclaim condition while causing inode eviction or key destruction on an affected encrypted filesystem. If fscrypt_get_devices() fails its dynamic allocation during this path, the vulnerable cleanup logic can free the blk_crypto_key without evicting it from the block crypto layer. Subsequent block crypto operations may dereference the stale key pointer, producing a kernel use-after-free. In practical terms, exploitation would likely require local access or workload control on a system using the affected fscrypt inline-encryption configuration, and reliable exploitation beyond denial of service would depend on kernel configuration, hardening, allocator behavior, and reachable filesystem operations.

How to fix it

Apply the Linux kernel update that includes the fscrypt fix changing fscrypt_get_devices() handling to avoid the vulnerable dynamic allocation failure path. If using a distribution kernel, install the vendor-provided kernel security update rather than attempting to patch individual source files manually. Reboot into the fixed kernel and ensure old vulnerable kernels are not selected by default at boot. If an immediate patch is not possible, reduce exposure by limiting untrusted local access to systems using fscrypt inline encryption, avoiding affected encrypted f2fs multi-device configurations where feasible, and monitoring for kernel crashes or memory-corruption warnings. No exact fixed package versions were provided in the input, so remediation should be tracked through the relevant Linux distribution or kernel vendor advisory for this CVE.

How to confirm the fix worked

Confirm the running kernel includes the fscrypt fix for this issue, not merely that an updated kernel package is installed. Validate with distribution tooling such as package changelogs, kernel advisory metadata, or source commit history for the fscrypt_get_devices() change. After reboot, verify the active kernel version with uname -r and compare it to the vendor-fixed kernel version. For source-built kernels, confirm the fs/crypto code no longer uses the vulnerable dynamic allocation pattern for this device enumeration path and that fscrypt_destroy_inline_crypt_key() cannot skip blk_crypto_evict_key() because of allocation failure. Also inventory whether systems use fscrypt inline encryption and f2fs or other filesystems with block inline crypto, since systems without that configuration are less exposed.

Typical attack path

1. Obtain local access or another ability to trigger filesystem operations on a Linux system using fscrypt inline encryption with an affected kernel.
2. Identify or create activity involving encrypted files, inode eviction, or key lifecycle operations on an affected filesystem such as f2fs using inline encryption.
3. Apply memory pressure to increase the chance that fscrypt_get_devices() fails allocation during key destruction or inode eviction under direct reclaim.
4. Trigger fscrypt_destroy_inline_crypt_key() so the blk_crypto_key is zeroized and freed without being evicted from the block crypto layer.
5. Cause subsequent block crypto activity that references the stale key pointer.
6. Leverage the resulting use-after-free for a kernel crash, denial of service, or potentially further memory-corruption exploitation if reliable primitives are available.

How to detect it

There are no public, CVE-specific exploitation indicators in the provided data, and exploitation maturity is listed as none. Detection should focus on evidence of attempted triggering or resulting kernel memory corruption. Review kernel logs, persistent journald records, dmesg output, crash dumps, kdump/vmcore artifacts, endpoint telemetry, and hypervisor reset events for use-after-free, slab corruption, KASAN reports, or kernel oops/panic messages involving fscrypt, blk_crypto, inline encryption, f2fs, inode eviction, or direct reclaim. Look for repeated low-memory conditions followed by filesystem encryption activity and kernel crashes. On systems with kernel sanitizers or debug builds, prioritize KASAN reports referencing fscrypt_destroy_inline_crypt_key(), fscrypt_get_devices(), blk_crypto_evict_key(), blk_crypto_start_using_key(), or blk_crypto_config_supported(). For production systems, correlate unexpected reboots or kernel panics with local user activity, container workloads, memory-pressure events, and encrypted filesystem operations. Absence of these artifacts does not prove non-exploitation, because successful kernel exploitation may leave limited logs and crashes may truncate volatile evidence.

• fscrypt_get_devices
• fscrypt_destroy_inline_crypt_key
• blk_crypto_evict_key
• blk_crypto_start_using_key
• blk_crypto_config_supported
• blk_crypto_key
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in fscrypt
• use-after-free in blk_crypto
• kernel BUG at fs/crypto
• kernel panic
• Oops:
• general protection fault
• slab-use-after-free
• f2fs
• fscrypt
• blk_crypto
• inline encryption
• direct reclaim

What your security team should do

• Identify Linux systems using fscrypt inline encryption, especially f2fs deployments and systems using hardware or block-layer inline encryption.
• Prioritize kernel updates for exposed systems that allow local users, containers, untrusted workloads, or tenant-controlled filesystem activity.
• Track the relevant distribution or kernel vendor advisory for the exact fixed kernel versions and deploy them through normal kernel patching processes.
• Reboot systems after patch installation and verify the active running kernel is the fixed version.
• Review recent kernel logs for fscrypt, blk_crypto, f2fs, KASAN, slab, or use-after-free warnings that may indicate attempted triggering or instability.
• Restrict untrusted local access and workload scheduling on affected systems until patching is complete.
• Ensure crash dump collection, kernel log forwarding, and endpoint telemetry are enabled for high-value Linux systems so exploitation attempts are not lost after reboot.