Skip to main content

Linux Kernel CVE-2026-64031

| EUVDEUVD-2026-45604 HIGH
2026-07-19 Linux GHSA-22cv-hg25-xph5
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

Local access to read affected files (AV:L/PR:L); a timing-dependent race window makes AC:H; kernel memory corruption supports high C/I/A within the unchanged scope.

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
HIGH
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
Jul 20, 2026 - 16:58 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 17:03 EUVD
CVE Published
Jul 19, 2026 - 15:39 cve.org
HIGH 7.8
CVE Published
Jul 19, 2026 - 15:39 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

erofs: fix managed cache race for unaligned extents

After unaligned compressed extents were introduced, the following race could occur:

[Thread 1] [Thread 2] (z_erofs_fill_bio_vec) <handle a Z_EROFS_PREALLOCATED_FOLIO folio> ... filemap_add_folio (1) (z_erofs_bind_cache) <the same folio is found..> .. .. folio_attach_private (2) filemap_add_folio (3) again

Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO.

Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1].

This only impacts unaligned data compression (-E48bit with zstd, for example).

[1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well.

AnalysisAI

Local privilege escalation / memory-corruption potential in the Linux kernel's EROFS filesystem arises from a managed-cache race condition affecting unaligned compressed extents. When two threads process the same Z_EROFS_PREALLOCATED_FOLIO for different pclusters, one thread can call filemap_add_folio() a second time on a folio whose private state was not yet cleared, corrupting the managed page cache. Rated CVSS 7.8 (AV:L), it affects EROFS images built with unaligned data compression (e.g. -E48bit with zstd); EPSS is low (0.17%, 6th percentile), it is not in CISA KEV, and no public exploit identified at time of analysis.

Technical ContextAI

EROFS (Enhanced Read-Only File System) is a compressed, read-only filesystem used widely in Android system/vendor partitions, container images, and appliance firmware. The bug lives in the zdata decompression path: z_erofs_fill_bio_vec() handles a preallocated folio and calls filemap_add_folio() (step 1) but only later attaches the pcluster via folio_attach_private() (step 2). Because folio->private still holds the sentinel Z_EROFS_PREALLOCATED_FOLIO between those steps, a concurrent z_erofs_bind_cache() on a different pcluster can find the same managed folio and call filemap_add_folio() again (step 3). This is a classic time-of-check/time-of-use data race (CWE-362, race condition; the CWE field is N/A in the source data) on shared page-cache state. The regression was introduced when unaligned compressed extents were added; the fix clears folio->private before the folio becomes visible in the managed cache, so a competing pcluster instead waits on the locked folio, mirroring the fix in commit 9e2f9d34dd12 for crafted overlapped pclusters.

RemediationAI

Vendor-released patch: update to a fixed stable kernel (e.g. the 6.18.34, 7.0.11, or 7.1 stable releases, or backport commits 425d32d6288d7d845e486af9419bbedccd8c9103 / 649932fc3815eda2f24eb4de4b3a5e94886ee0b9 / 038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b from git.kernel.org/stable). Apply your distribution's corresponding kernel security update and reboot. If immediate patching is not possible, the practical compensating control is to avoid the trigger: do not build or mount EROFS images that use unaligned data compression (do not pass -E48bit / equivalent zstd unaligned options when generating images with mkfs.erofs), and rebuild affected images with aligned compression - the trade-off is a modest loss of compression density. Restrict the ability of untrusted users to mount attacker-supplied EROFS images (e.g. via automount, USB, or container image import), since mounting a crafted image is the realistic delivery path; the trade-off is reduced convenience for removable-media and container workflows. Verify fixed version against your distro advisory before declaring remediation complete.

Vendor StatusVendor

SUSE

Severity: Important
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

CVE-2026-64031 vulnerability details – vuln.today

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