Race Condition Affecting libperf-devel package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux 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-RHEL9-LIBPERFDEVEL-14136234
  • published27 Nov 2025
  • disclosed19 Aug 2025

Introduced: 19 Aug 2025

CVE-2025-38584  (opens in a new tab)
CWE-362  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:9 libperf-devel.

NVD Description

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

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

padata: Fix pd UAF once and for all

There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.

This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.

In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.

Fix this by getting the next padata before the squeue->serial lock is released.

In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.

CVSS Base Scores

version 3.1