Skip to main content

Linux Kernel CVE-2026-72367

| EUVDEUVD-2026-59266 HIGH
2026-08-15 Linux GHSA-r9wm-p769-97j8
8.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

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

Race condition requires local file access and precise timing (AC:H, AV:L, PR:L); integrity and availability highly impacted via filesystem corruption; confidentiality impact is low (information disclosure tag, not direct memory read).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:L/VI:H/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:L/A:H
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Aug 17, 2026 - 08:49 vuln.today
CVSS changed
Aug 17, 2026 - 06:22 NVD
8.8 (HIGH)
Patch available
Aug 15, 2026 - 07:20 EUVD
CVE Published
Aug 15, 2026 - 05:56 cve.org
HIGH 8.8
CVE Published
Aug 15, 2026 - 05:56 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

iomap: guard io_size EOF trim against concurrent truncate underflow

iomap: fix zero padding data issue in concurrent append writes changed ioend accounting so that io_size tracks only valid data within EOF. This trims io_size when a writeback range extends past end_pos:

ioend->io_size += map_len; if (ioend->io_offset + ioend->io_size > end_pos) ioend->io_size = end_pos - ioend->io_offset;

However, if end_pos ends up below ioend->io_offset, the subtraction becomes negative and is stored in size_t io_size, causing an unsigned wrap to a huge value. This can happen when writeback continues past byte-level EOF up to a block-aligned range, or when a concurrent truncate shrinks the file after end_pos was sampled in iomap_writeback_handle_eof().

A wrapped io_size can mislead append detection and corrupt completion-time size handling, since filesystem end_io paths consume io_size for decisions such as on-disk EOF updates and unwritten/COW completion ranges.

Fix this by clamping io_size to zero when EOF has moved to or before the ioend start offset. This preserves the original intent of trimming io_size to valid in-EOF data while avoiding the underflow.

AnalysisAI

Unsigned integer underflow in the Linux kernel iomap writeback subsystem allows a low-privileged user to corrupt filesystem EOF metadata and on-disk size tracking. The flaw occurs in the io_size EOF trim path when a concurrent truncate shrinks the file after end_pos is sampled, causing end_pos to fall below ioend->io_offset; the resulting negative subtraction wraps to a huge value in the size_t io_size field. This corrupted io_size is then consumed by end_io paths for decisions including on-disk EOF updates, unwritten extent completion, and COW range handling. No public exploit has been identified at time of analysis, and EPSS is very low at 0.21% (11th percentile), though the official CVSS scores this 8.8 High with full C/I/A impact.

Technical ContextAI

The vulnerability resides in the Linux kernel iomap layer (fs/iomap/), which is the generic block-mapping framework underlying multiple Linux filesystems including XFS, ext4, and others. Specifically, the flaw is in iomap_writeback_handle_eof(), introduced by a prior commit ('iomap: fix zero padding data issue in concurrent append writes') that changed ioend accounting to track only valid in-EOF data. The accounting computes io_size as end_pos - ioend->io_offset, but io_size is typed as size_t (unsigned). When end_pos is less than ioend->io_offset - possible because writeback can extend to block-aligned boundaries past byte-level EOF, or because a racing truncate(2) reduces the file size after end_pos was sampled - the subtraction underflows and wraps to a very large value (e.g., 2^64 - delta on 64-bit). No CWE was formally assigned, but this is a classic CWE-191 (Integer Underflow) combined with CWE-362 (Race Condition). Affected CPE: cpe:2.3:a:linux:linux across a broad commit range starting at 51d20d1dacbec589d459e11fc88fbca419f84a99.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel version: 7.2-rc2, 6.18.40, or 7.1.5 as applicable to your stable branch. The fix clamps io_size to zero when end_pos has moved to or below ioend->io_offset, preventing the unsigned underflow. Upstream fix commits are available at the kernel.org stable tree links in the references. For systems that cannot be immediately patched, a compensating control is to reduce workloads that combine high-frequency concurrent append writes with concurrent truncate operations on the same files, which narrows the race window; however this is an operational workaround with significant trade-offs and does not eliminate the risk. Filesystems using the iomap layer (XFS, ext4 with iomap writeback paths) should be prioritized. Distribution vendors (Red Hat, Ubuntu, SUSE, Debian) will ship backported fixes into their stable kernels; consult ENISA EUVD-2026-59266 and NVD at https://nvd.nist.gov/vuln/detail/CVE-2026-72367 for advisory updates.

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 Availability Extension 16.0 Affected

Share

CVE-2026-72367 vulnerability details – vuln.today

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