Bug 2516477 (CVE-2026-72314)

Summary:	CVE-2026-72314 kernel: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	rhel-process-autobot, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's regulator core. The `regulator_lock_two()` function, responsible for acquiring two regulators, incorrectly checks for an error code (`EDEADLOCK`) instead of the correct one (`EDEADLK`). On certain architectures, such as MIPS, SPARC, and PowerPC, this discrepancy means that if a lock contention occurs, the system fails to properly retry the lock acquisition. This can result in the system operating with an incorrect lock state, potentially leading to system instability or a denial of service.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 06:14:35 UTC

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

regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK

Compare against -EDEADLK, which is what ww_mutex_lock() actually
returns and what every other deadlock check in this file already uses.

Function regulator_lock_two() acquires two regulators via
regulator_lock_nested() -> ww_mutex_lock().  On contention,
ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop
the lock it holds and retry the acquisition in the canonical order.

However, regulator_lock_two() tests the return value against -EDEADLOCK
rather than -EDEADLK.  On most architectures, EDEADLK and EDEADLOCK are
the same value, so the comparison happens to be correct and the bug is
invisible.  But on MIPS, SPARC, and PowerPC, those two errors have
different values.  The test is wrong: a genuine -EDEADLK backoff no
longer matches -EDEADLOCK, so instead of unlocking and retrying, the
code falls into WARN_ON(ret) and returns with only one of the two
regulators locked.

In practice, this is a bug only on MIPS, because the regulator core is
not built or used on the other two platforms.

In general, EDEADLK is preferred over EDEADLOCK for new code.

Comment 1 gkamathe 2026-08-18 13:04:33 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081505-CVE-2026-72314-6e37@gregkh/T