Homepage

Use After Free The advisory has been revoked - it doesn't affect any version of package libperf  (opens in a new tab)

Threat Intelligence

EPSS
0.13% (3rd 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-RHEL10-LIBPERF-18999699
  • published20 Aug 2026
  • disclosed15 Aug 2026
Report a new vulnerability Found a mistake?

Introduced: 15 Aug 2026

CVE-2026-74405  (opens in a new tab)
CWE-416  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:10.

NVD Description

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

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

OPP: Fix race between OPP addition and lookup

A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact():

CPU0 (add) CPU1 (lookup)

_opp_add() mutex_lock() list_add(&new_opp->node, head) mutex_unlock() _opp_table_find_key() mutex_lock() dev_pm_opp_get(opp) kref_get() mutex_unlock() kref_init(&new_opp->kref) dev_pm_opp_put() kref_put_mutex()

The newly added OPP is inserted into the list before its kref is initialized. A concurrent lookup can find this OPP and increment its reference count while it is still uninitialized, leading to refcount corruption and a potential premature free.

Fix this by initializing ->kref and ->opp_table before making the OPP visible via list_add(). This ensures any concurrent lookup observes a fully initialized object.

[ Viresh: Updated commit log ]