CVE-2026-74405 in Linux
Summary
by MITRE • 08/15/2026
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 ]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability represents a critical race condition in the Linux kernel's power management subsystem, specifically within the On-Demand Performance (OPP) framework that manages device power and performance states. The issue occurs when multiple CPU cores attempt to simultaneously add new OPP entries while other cores perform lookups for existing entries, creating a timing window where object initialization and visibility are not properly synchronized. The vulnerability is classified under CWE-362, which details race conditions in concurrent programming scenarios where the order of operations creates exploitable timing windows.
The technical flaw manifests when dev_pm_opp_add_dynamic() function executes the list insertion operation before completing the initialization of the OPP object's reference counting mechanism. During this window, dev_pm_opp_find_freq_exact() can locate the partially initialized OPP entry, increment its reference count through kref_get(), and subsequently decrement it through kref_put() operations that occur during cleanup or lookup completion. This sequence results in corrupted reference counts and potential memory corruption where the kernel may prematurely free memory associated with an object that is still being referenced or whose reference counting mechanism is not yet fully functional.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially leading to system instability, crashes, or even privilege escalation opportunities within the kernel space. Attackers could exploit this race condition by creating high-frequency concurrent access patterns to OPP management functions, causing unpredictable behavior in device power management operations that are critical for system stability. The vulnerability affects systems using the Linux kernel's power management framework and impacts any hardware platform utilizing OPP tables for dynamic frequency scaling.
Mitigation strategies include implementing proper synchronization mechanisms before making objects visible to concurrent threads, ensuring all object initialization occurs completely before any visibility operations such as list insertion. The fix requires reordering the sequence of operations in the OPP addition function to initialize the kref counter and table references before inserting the new OPP entry into the global list structure. This approach aligns with ATT&CK technique T1068, which addresses privilege escalation through kernel vulnerabilities, and follows established security practices for preventing race conditions in concurrent systems. System administrators should ensure kernel updates are applied promptly to address this vulnerability, particularly on systems running high-performance computing workloads where OPP management is heavily utilized. The solution demonstrates proper defensive programming practices that align with industry standards for concurrent object management in kernel space environments.