Use of Out-of-range Pointer Offset The advisory has been revoked - it doesn't affect any version of package libperf (opens in a new tab)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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-LIBPERF-17513118
- published26 Jun 2026
- disclosed28 May 2026
Introduced: 28 May 2026
CVE-2026-46130 (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 libperf package and not the libperf package as distributed by Centos.
In the Linux kernel, the following vulnerability has been resolved:
dm-verity-fec: fix reading parity bytes split across blocks (take 3)
fec_decode_bufs() assumes that the parity bytes of the first RS codeword it decodes are never split across parity blocks.
This assumption is false. Consider v->fec->block_size == 4096 && v->fec->roots == 17 && fio->nbufs == 1, for example. In that case, each call to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes.
Considering that the parity data for each message block starts on a block boundary, the byte alignment in the parity data will iterate through 272*i mod 4096 until the 3 parity blocks have been consumed. On the 16th call (i=15), the alignment will be 4080 bytes into the first block. Only 16 bytes remain in that block, but 17 parity bytes will be needed. The code reads out-of-bounds from the parity block buffer.
Fortunately this doesn't normally happen, since it can occur only for certain non-default values of fec_roots and when the maximum number of buffers couldn't be allocated due to low memory. For example with block_size=4096 only the following cases are affected:
fec_roots=17: nbufs in [1, 3, 5, 15]
fec_roots=19: nbufs in [1, 229]
fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195]
fec_roots=23: nbufs in [1, 89]
Regardless, fix it by refactoring how the parity blocks are read.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2482662
- https://access.redhat.com/security/cve/CVE-2026-46130
- https://git.kernel.org/stable/c/3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb
- https://git.kernel.org/stable/c/430a05cb926f6bdf53e81460a2c3a553257f3f61
- https://git.kernel.org/stable/c/d47281b9a4472cfd73122393e79fbe76b651e46a
- https://git.kernel.org/stable/c/03348b440f69417dc3a3c71d8271cff6b05f67fb
- https://git.kernel.org/stable/c/dac69d1b76049d7e5f565089a6a7f4502a85b9de