Integer Underflow The advisory has been revoked - it doesn't affect any version of package perf  (opens in a new tab)


Threat Intelligence

EPSS
0.6% (49th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS10-PERF-18991150
  • published20 Aug 2026
  • disclosed15 Aug 2026

Introduced: 15 Aug 2026

CVE-2026-72367  (opens in a new tab)
CWE-191  (opens in a new tab)

Amendment

The Centos security team deemed this advisory irrelevant for Centos:10.

NVD Description

Note: Versions mentioned in the description apply only to the upstream perf package and not the perf package as distributed by Centos.

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.