Expired Pointer Dereference Affecting libperf package, versions *


Severity

Recommended
0.0
high
0
10

Based on CentOS security rating.

Threat Intelligence

EPSS
0.61% (48th 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-19836153
  • published16 Sept 2026
  • disclosed11 Sept 2026

Introduced: 11 Sep 2026

NewCVE-2026-89689  (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:

nfsd: don't free session slots that are still in use

nfsd4_sequence() can free the very slot it is currently processing. When the session shrinker has reduced se_target_maxslots below se_fchannel.maxreqs, the shrink path checks three conditions before calling free_session_slots():

  1. se_target_maxslots < maxreqs (shrink was advertised)
  2. slot->sl_generation == se_slot_gen (slot is up-to-date)
  3. seq->maxslots <= se_target_maxslots (client acknowledges)

However, seq->slotid is never checked against se_target_maxslots. A client using a slot in the range [se_target_maxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sa_highest_slotid <= se_target_maxslots to acknowledge the reduction.

free_session_slots() then kfrees every slot at index >= se_target_maxslots, including the caller's own slot. The function continues to write sl_seqid, sl_flags, sl_generation, and stores the dangling pointer in cstate->slot. Later, nfsd4_store_cache_entry() copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that address.

Additionally, a concurrent thread processing SEQUENCE on a different high-numbered slot can have its slot freed out from under it. NFSD4_SLOT_INUSE is set under nn->client_lock before the lock is released, so any concurrent thread past SEQUENCE will have its slot marked. However, free_session_slots() does not check NFSD4_SLOT_INUSE before freeing.

Fix both problems by:

  1. Checking that the current request's slotid is below the shrink boundary.
  2. Scanning slots in the to-be-freed range for NFSD4_SLOT_INUSE and deferring the shrink if any are active.

CVSS Base Scores

version 3.1