CVE-2026-72314

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

State
Published
Severity
7.8 High
Published
Aug 15, 2026
Updated
Oct 16, 2026
Reserved
Aug 9, 2026

Read the record on cve.org

Description

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.

Scores

CVSSScoreVectorSource
3.17.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HLinux

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • 06140d6dfe720d80566f792b4e28a9cd60a67970 to before dc804f390fddd9c389edf0976356942e16878d8fAffected
  • 1e3056b8067c2e9b7741c4e588f0acacbe4bdafc to before 8e39aa63798ea0a797fd9341419f12ef91df3238Affected
  • 849ab4cf182b38e562ffcc1b494d510e948822dd to before 0c305eac40470a224671858a215963b070f9b2a9Affected
  • cba6cfdc7c3f1516f0d08ddfb24e689af0932573 to before 29a7953e9adea6c7f9e64947745b79158e7cea7fAffected
  • cba6cfdc7c3f1516f0d08ddfb24e689af0932573 to before e2063307ea3b6da74585129ba7b588e8243e2ef0Affected
  • cba6cfdc7c3f1516f0d08ddfb24e689af0932573 to before 346e2d666a29ae7233c56b356a0487eb1d42589bAffected
  • cba6cfdc7c3f1516f0d08ddfb24e689af0932573 to before 153d1b8b5bc30847eb70ad535f62f289aa9217e6Affected
  • cba6cfdc7c3f1516f0d08ddfb24e689af0932573 to before d38f8bd771c4999b797d7074b348cf201414bd34Affected
  • 5224ea575196db11c0a909a78ea426ccdb92f064Affected
  • 435c65af581a61ca249bd8f717c3a147dc119f11Affected
  • cdc042430ea9e07f77ce05a9d29e227dbdecc733Affected
  • 5.10.180 to before 5.10.261Affected
  • 5.15.111 to before 5.15.212Affected
  • 6.1.28 to before 6.1.178Affected
  • 5.4.243 to before 5.5Affected
  • 6.2.15 to before 6.3Affected
  • 6.3.2 to before 6.4Affected
LinuxLinux
  • 6.4Affected
  • before 6.4Not affected
  • 5.10.261 through 5.10.*Not affected
  • 5.15.212 through 5.15.*Not affected
  • 6.1.178 through 6.1.*Not affected
  • 6.6.145 through 6.6.*Not affected
  • 6.12.97 through 6.12.*Not affected
  • 6.18.40 through 6.18.*Not affected
  • 7.1.5 through 7.1.*Not affected
  • 7.2 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.