Skip to main content

Linux Kernel EUVDEUVD-2026-24805

| CVE-2026-31463 CRITICAL
2026-04-22 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-rprr-w46r-7762
Information Disclosure Linux
9.8
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
SUSE
CRITICAL
qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Lifecycle Timeline

7
Analysis Generated
Apr 27, 2026 - 14:29 vuln.today
CVSS changed
Apr 27, 2026 - 14:22 NVD
9.8 (CRITICAL)
Patch released
Apr 27, 2026 - 14:16 nvd
Patch available
Patch available
Apr 22, 2026 - 16:33 EUVD
EUVD ID Assigned
Apr 22, 2026 - 14:22 euvd
EUVD-2026-24805
Analysis Generated
Apr 22, 2026 - 14:22 vuln.today
CVE Published
Apr 22, 2026 - 14:16 nvd
CRITICAL 9.8

DescriptionCVE.org

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

iomap: fix invalid folio access when i_blkbits differs from I/O granularity

Commit aa35dd5cbc06 ("iomap: fix invalid folio access after folio_end_read()") partially addressed invalid folio access for folios without an ifs attached, but it did not handle the case where 1 << inode->i_blkbits matches the folio size but is different from the granularity used for the IO, which means IO can be submitted for less than the full folio for the !ifs case.

In this case, the condition:

if (*bytes_submitted == folio_len) ctx->cur_folio = NULL;

in iomap_read_folio_iter() will not invalidate ctx->cur_folio, and iomap_read_end() will still be called on the folio even though the IO helper owns it and will finish the read on it.

Fix this by unconditionally invalidating ctx->cur_folio for the !ifs case.

AnalysisAI

Use-after-free vulnerability in Linux kernel iomap subsystem allows memory corruption when filesystem block size differs from I/O granularity. The flaw occurs during buffered read operations when ctx->cur_folio is accessed after ownership transfers to the I/O helper, potentially leading to data corruption, information disclosure, or system crashes. Affects Linux kernel 6.19.x series. CVSS 9.8 critical severity, but EPSS exploitation probability is very low (0.02%, 5th percentile). Vendor patches available via mainline kernel commits. No active exploitation or public POC identified at time of analysis.

Technical ContextAI

The vulnerability exists in the Linux kernel's iomap subsystem, specifically in the buffered I/O read path used by modern filesystems like XFS and ext4. The iomap layer handles page cache operations and I/O submission. The flaw involves improper lifetime management of folio (multi-page memory structure) pointers when inode block size (i_blkbits) matches folio size but differs from I/O granularity. When iomap_read_folio_iter() submits partial-folio I/O in the non-inline-filesystem-state (!ifs) case, it fails to invalidate ctx->cur_folio because bytes_submitted doesn't equal folio_len. Subsequently, iomap_read_end() accesses the folio after the I/O helper has already taken ownership, creating a use-after-free condition. This is a regression from commit aa35dd5cbc06 which only partially addressed folio lifetime issues. The affected code path handles buffered reads through iomap_readpage/iomap_readahead entry points used by filesystem read operations.

RemediationAI

Update to Linux kernel version 6.19.11 or later for the 6.19.x stable series, or upgrade to kernel 7.0 or later which includes the fix by default. The vendor patches are available in mainline stable kernel git repository as commits bd71fb3fea9945987053968f028a948997cba8cc and 4a927f670cdb0def226f9f85f42a9f19d9e09c88 accessible at https://git.kernel.org/stable/. For systems that cannot immediately upgrade, potential mitigations include avoiding iomap-based filesystems (switch to non-iomap implementations where possible), though this is impractical for most production environments. More realistic compensating control is to minimize use of configurations where filesystem block size differs from page/folio size, but this requires filesystem-level changes and may impact performance. Organizations using kernel 6.19.0 through 6.19.10 should prioritize patching to 6.19.11 or later. Systems not running 6.19.x series are not affected by this specific regression. No effective runtime workaround exists short of kernel replacement; rebooting with patched kernel is required.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-24805 vulnerability details – vuln.today
Back

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