Описание
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.
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.
Отчет
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.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
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 ...
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
In the Linux kernel, the following vulnerability has been resolved: r ...
EPSS
5.5 Medium
CVSS3