mirror of
https://github.com/0xMarcio/cve.git
synced 2025-05-06 10:41:43 +00:00
18 lines
1.6 KiB
Markdown
18 lines
1.6 KiB
Markdown
![]() |
### [CVE-2024-26627](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26627)
|
||
|

|
||
|

|
||
|

|
||
|
|
||
|
### Description
|
||
|
|
||
|
In the Linux kernel, the following vulnerability has been resolved:scsi: core: Move scsi_host_busy() out of host lock for waking up EH handlerInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with hostlock every time for deciding if error handler kthread needs to be waken up.This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requestsIf recovery is triggered in case that all requests are in-flight, eachscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is calledfor the last in-flight request, scsi_host_busy() has been run for (N * M -1) times, and request has been iterated for (N*M - 1) * (N * M) times.If both N and M are big enough, hard lockup can be triggered on acquiringhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).Fix the issue by calling scsi_host_busy() outside the host lock. We don'tneed the host lock for getting busy count because host the lock nevercovers that.[mkp: Drop unnecessary 'busy' variables pointed out by Bart]
|
||
|
|
||
|
### POC
|
||
|
|
||
|
#### Reference
|
||
|
No PoCs from references.
|
||
|
|
||
|
#### Github
|
||
|
- https://github.com/fkie-cad/nvd-json-data-feeds
|
||
|
|