CVE-2026-72314

A flaw of low impact was found in the Linux kernel's regulator core as shipped in Red Hat Enterprise Linux 9 and 10 and Red Hat In-Vehicle OS. The regulator_lock_two() function, which acquires two regulators through the wound/wait mutex interface, compares the lock-acquisition return value against -EDEADLOCK instead of the -EDEADLK value that ww_mutex_lock() actually returns. On most architectures the two error constants have the same value, so the comparison happens to be correct and the bug is invisible; they differ only on MIPS, SPARC, and PowerPC, and in practice the regulator core is built on MIPS only of those. On such a system, when lock contention occurs, the genuine -EDEADLK backoff signal is not recognized, so instead of dropping the held lock and retrying the acquisition in canonical order, the code triggers a WARN_ON and returns with only one of the two regulators held. This incorrect lock state can lead to system instability or a local denial of service. Triggering the issue requires local access and a specific regulator lock-contention scenario, and there is no confidentiality or integrity impact. Earlier Red Hat Enterprise Linux releases (RHEL 7, RHEL 8, and the RHEL 9.2 z-stream) are not affected because the vulnerable code is not present in those kernels. For the affected streams the fix is currently deferred: given the low impact and the fact that the flawed comparison is only observable on architectures where EDEADLK and EDEADLOCK differ (practically MIPS only), the residual risk is low. The upstream CVE record assigns a higher severity (CVSS 7.8) than Red Hat (CVSS 5.5, moderate) because it assumes high confidentiality and integrity impacts; this flaw is an error-code comparison bug in a locking path that affects availability only, which is why Red Hat rates the overall impact as low.