Expired Pointer Dereference Affecting libperf package, versions *


Severity

Recommended
0.0
high
0
10

Based on CentOS security rating.

Threat Intelligence

EPSS
0.16% (6th 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-LIBPERF-18381763
  • published29 Jul 2026
  • disclosed25 Jul 2026

Introduced: 25 Jul 2026

NewCVE-2026-64265  (opens in a new tab)
CWE-825  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 libperf.

NVD Description

Note: Versions mentioned in the description apply only to the upstream libperf package and not the libperf package as distributed by Centos. See How to fix? for Centos:10 relevant fixed versions and status.

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

fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req

When fuse_resend() moves a request from fpq->processing back to fiq->pending, it sets FR_PENDING and clears FR_SENT but does not remove the requests intr_entry from fiq->interrupts. If the request had FR_INTERRUPTED set from a prior signal, intr_entry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuse_remove_pending_req() sees FR_PENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intr_entry. The stale intr_entry causes use-after-free when fuse_read_interrupt() iterates fiq->interrupts:

  • list_del_init(&req->intr_entry) -> UAF write on freed slab
  • req->in.h.unique -> UAF read, data leaked to userspace

Remove intr_entry from fiq->interrupts in fuse_resend() for interrupted requests before they are placed back on fiq->pending.

Add a WARN_ON if the intr_entry is not empty on request destruction.

CVSS Base Scores

version 3.1