Skip to main content

Linux Kernel EUVDEUVD-2026-32358

| CVE-2026-45892 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-xq2x-f6m4-2hrp
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

AC:H because trigger requires transient memory pressure coinciding with a specific split-failure path; all other metrics align with NVD assignment.

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

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 25, 2026 - 21:33 vuln.today
CVSS changed
Jun 25, 2026 - 21:22 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5

DescriptionNVD

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

ext4: drop extent cache after doing PARTIAL_VALID1 zeroout

When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.

Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent.

0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data

|<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten.

0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data

ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N.

0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ]

Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree.

0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ]

Fix this issue by always cached extent status entry after zeroing out the second part.

AnalysisAI

Stale unwritten extent retention in the Linux kernel ext4 filesystem's in-memory extent status cache allows a local low-privileged user to trigger filesystem state inconsistency with high availability impact. The flaw manifests in ext4_split_extent() when a PARTIAL_VALID1 zeroout operation succeeds but the subsequent split at the first boundary fails due to temporary memory pressure, leaving the extent status tree out of sync with on-disk extent data. Patched stable releases are available; no public exploit or CISA KEV listing has been identified at time of analysis, and EPSS exploitation probability sits at 0.02% (5th percentile).

Technical ContextAI

The ext4 filesystem uses an extent tree on disk and an in-memory extent status (ES) cache for performance. When converting unwritten (pre-allocated) extents to written state via buffered I/O without dioread_nolock enabled, ext4_split_extent() attempts a two-phase split: first splitting at the upper boundary (B to N) with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT, then splitting at the lower boundary (0 to A) with EXT4_EXT_DATA_VALID2. If the first split call to ext4_split_extent_at() fails due to transient resource exhaustion, it falls back to zeroing the B-to-N range and leaves the entire on-disk extent as unwritten. When the second split succeeds, the on-disk extent from A to N becomes written, but the ES cache still holds the stale unwritten entry for B to N - because no cache invalidation was performed after the zeroout. The fix ensures the ES cache is dropped after PARTIAL_VALID1 zeroout. The CPE affected is cpe:2.3:o:linux:linux_kernel across the 6.1, 6.6, 6.12, 6.18, and 6.19 stable series. No CWE was assigned by NVD; the root cause class is a cache coherency or state-management defect (analogous to CWE-459: Incomplete Cleanup).

RemediationAI

Update to a patched Linux kernel stable release: 6.6.130, 6.12.75, 6.18.14, or 6.19.4, as confirmed by EUVD-2026-32358 and upstream commits at git.kernel.org/stable (commits 6d882ea3b093, a1b962a821e7, c2ee51d684ad, d8ee559fccde, f0931a5c1700, and 28db4bfc6f82 among others). Linux 7.0 also contains the fix. Distribution maintainers for Debian, Ubuntu, RHEL, SUSE, and others should be consulted for backported package updates. If immediate patching is not possible, mounting ext4 filesystems with the dioread_nolock mount option avoids the specific code path that triggers the vulnerability - this changes I/O locking semantics and may affect performance under concurrent I/O workloads, so test in staging before deploying. Restricting local user access to systems with large pre-allocated ext4 files (e.g., virtual machine disk images, database files using fallocate) reduces exposure. NVD advisory: https://nvd.nist.gov/vuln/detail/CVE-2026-45892.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected

Share

EUVD-2026-32358 vulnerability details – vuln.today

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