Skip to main content

Linux Kernel EUVDEUVD-2026-55533

| CVE-2026-68148 HIGH
2026-08-10 Linux GHSA-r7wr-xw9j-768v
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

AC:H reflects the requirement to simultaneously mount two v1 DIRECT_KEY filesystems with coinciding key material and time the unmount correctly; all other metrics align with the provided vector.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
6.4 MEDIUM
AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 02:31 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
7.8 (HIGH)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 11:59 cve.org
UNKNOWN (no severity yet)
CVE Published
Aug 10, 2026 - 11:59 cve.org
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

Use-after-free in the Linux kernel fscrypt subsystem's find_or_insert_direct_key() function allows a low-privileged local attacker to potentially read sensitive kernel memory, corrupt data structures, or crash the system. The global fscrypt_direct_keys hash table-used exclusively by the legacy v1 encryption policy path with FSCRYPT_POLICY_FLAG_DIRECT_KEY-matched cached master-key entries by cryptographic material without comparing the super_block pointer, enabling inodes from distinct filesystems to share a single fscrypt_direct_key and extend its lifetime past superblock teardown. No public exploit is identified at time of analysis, and EPSS stands at 0.12% (2nd percentile), indicating negligible observed exploitation activity.

Technical ContextAI

The vulnerability originates in the fscrypt (filesystem-layer encryption) subsystem of the Linux kernel, introduced at commit 22e9947a4b2ba255888541bd0111cf00b9b16586. The fscrypt_direct_keys table is a process-global hash map caching struct fscrypt_direct_key objects for filesystems using the legacy v1 encryption policy with the FSCRYPT_POLICY_FLAG_DIRECT_KEY flag-a mechanism that permits master keys to be supplied via process-subscribed keyrings rather than per-superblock keyring infrastructure. Each cached entry embeds a super_block pointer, used by fscrypt_destroy_inline_crypt_key() at inode eviction time. The root cause is a missing super_block comparison in the lookup function: when two inodes from different mounted filesystems share identical raw key material, they resolve to the same fscrypt_direct_key entry. Upon unmounting the first filesystem, its superblock is freed; any remaining inode on the second filesystem that still holds a reference to the shared entry now carries a dangling pointer-a use-after-free (analogous to CWE-416, though no formal CWE is assigned). The v2 policy equivalent, which stores keys in super_block::s_master_keys, is architecturally isolated and unaffected. Affected CPE: cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*.

RemediationAI

Upgrade to a fixed Linux kernel release: 6.6.148 or later on the 6.6 stable branch, 6.12.101 or later on the 6.12 stable branch, 7.1.6 or later on the 7.1 stable branch, 6.18.42 or later on the 6.18 stable branch, or any mainline release at or after 7.2-rc5. Patch commits for cherry-picking into custom builds are available at https://git.kernel.org/stable/c/330249609b70778094a7a36f5b6bcfa6362121d4, https://git.kernel.org/stable/c/deff41898a5ae3a47db5fa1896a494aa95efda5d, https://git.kernel.org/stable/c/95376fe9c145be35566991df99c53134943d992f, https://git.kernel.org/stable/c/466f187b501a5ac8e1ea2ccf3ccd5c46108d8830, and https://git.kernel.org/stable/c/b5fa40226e71c17847b9ff2816c6ca4133d0d994. If immediate patching is not feasible, the primary compensating control is to avoid simultaneously mounting more than one fscrypt-encrypted filesystem under v1 policies with FSCRYPT_POLICY_FLAG_DIRECT_KEY; this eliminates the shared-entry condition that causes the bug, at the cost of constraining multi-volume encrypted storage configurations. A longer-term architectural mitigation is migrating all encrypted volumes to v2 fscrypt policies, which use per-superblock key storage and are wholly unaffected-note that this requires re-encryption of existing data and careful coordination of key provisioning.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-55533 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy