Описание
In the Linux kernel, the following vulnerability has been resolved:
IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition
The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
Ссылки
- Patch
- Patch
- Patch
- Patch
- Patch
- Patch
Уязвимые конфигурации
Одно из
EPSS
4.7 Medium
CVSS3
Дефекты
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
In the Linux kernel, the following vulnerability has been resolved: I ...
In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
Уязвимость функции spin_lock_irqsave() модуля drivers/infiniband/sw/rdmavt/qp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
EPSS
4.7 Medium
CVSS3