Skip to content
VulniPulse
Medium6.4Vendor: HighRed Hat Linux

Medium [CVE-2026-68148] Linux kernel: Use-after-free in fscrypt due to missing superblock check

This medium-severity Red Hat Linux advisory covers CVE-2026-68148.

CVE-2026-68148 Published Aug 10, 2026Updated by vendor Aug 10, 2026
Affected products & platforms
Red Hat LinuxUnclassified
Open vendor advisory

Android app · Google Play

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery

Summary

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.

A missing superblock check in the `find_or_insert_direct_key()` function could allow inodes from different filesystems to incorrectly share encryption keys.

Affected versions

No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.

Official advisory · medium-confidence parse· fetched 1 hour ago·verify at source

Fixed versions

No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.

Official advisory · medium-confidence parse· fetched 1 hour ago·verify at source

Mitigation

The source record does not include mitigation steps. That is not a statement that no fix exists — read the vendor advisory below for the authoritative guidance.

Official advisory · medium-confidence parse· fetched 1 hour ago·verify at source

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.