CVE-2026-68148 in Linuxinfo

Summary

by MITRE • 08/10/2026

In the Linux kernel, the following vulnerability has been resolved:

fscrypt: Add missing superblock check in find_or_insert_direct_key()

The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys).

The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted.

However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later.

Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs.

Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 08/10/2026

The vulnerability resides within the linux kernel's filesystem encryption implementation, specifically in the fscrypt subsystem where legacy direct key caching mechanisms fail to properly validate superblock contexts during key lookup operations. This issue affects the fscrypt_direct_keys table which serves as a global cache for master keys used by v1 encryption policies that employ the FSCRYPT_POLICY_FLAG_DIRECT_KEY flag. The fundamental flaw emerges from the absence of proper superblock verification when retrieving cached direct keys, creating a scenario where multiple filesystem instances can incorrectly reference the same cryptographic key structure despite having distinct underlying superblock contexts.

The technical implementation defect manifests in the find_or_insert_direct_key() function which fails to compare super_block pointers when locating existing direct key entries. This oversight allows the system to return a cached fscrypt_direct_key structure regardless of whether it corresponds to the current filesystem's superblock context, essentially creating a cross-filesystem key reference scenario. The fscrypt_direct_key structures themselves do contain super_block pointers intended for proper cleanup operations through fscrypt_destroy_inline_crypt_key(), but these pointers remain unused during lookup validation processes.

The operational impact of this vulnerability represents a critical use-after-free condition that can occur when inodes from different filesystems inadvertently reference the same cached key structure. When the original superblock context expires or is destroyed, the cached key may continue to exist in memory while its associated resources have been freed, leading to potential memory corruption and system instability. This scenario directly violates the principle of proper resource management and can enable arbitrary code execution through memory corruption attacks.

The fix implements a fundamental architectural correction by ensuring distinct fscrypt_direct_key structures are created for each unique super_block context rather than sharing cached entries across different filesystem instances. This approach aligns with established security principles from CWE category 416, which addresses use-after-free vulnerabilities, and follows ATT&CK technique T1059.007 for execution through memory corruption. The solution specifically targets the v1 policy encryption mechanism while noting that v2 policies avoid this issue entirely due to their per-superblock data structure design, demonstrating a proper separation of concerns in cryptographic implementation.

The vulnerability represents a classic case of insufficient context validation in global caching systems where resource lifetimes become decoupled from their original allocation contexts. This misalignment creates dangerous temporal coupling between filesystem operations and cryptographic key management, potentially allowing attackers to manipulate filesystem state through carefully crafted encryption policy interactions. The resolution ensures proper per-superblock key isolation while maintaining backward compatibility with existing legacy encryption mechanisms, following security best practices outlined in industry standards for kernel memory management and cryptographic implementation.

Responsible

Linux

Reservation

07/30/2026

Disclosure

08/10/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!