cve/2024/CVE-2024-26627.md

18 lines
1.6 KiB
Markdown
Raw Permalink Normal View History

2024-05-25 21:48:12 +02:00
### [CVE-2024-26627](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26627)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=6eb045e092ef%3C%20f5944853f7a9%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)
### 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