CVE-2026-74754: scsi: core: pair EH runtime PM get and put
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: pair EH runtime PM get and put
shost->ehnoresume is currently consulted twice in one error handling iteration: once before scsiautopmgethost() and once again before scsiautopmputhost().
That is racy when a PM-triggered error path flips shost->ehnoresume while the SCSI EH thread is still running.
The problem flow looks like this: PM path ufshcdsetdevpwrmode() shost->ehnoresume = 1 ufshcdexecutestartstop <-- trigger EH ... shost->ehnoresume = 0
EH path scsierrorhandler() if (!shost->ehnoresume) scsiautopmgethost() <-- skipped ... if (!shost->ehnoresume) scsiautopmputhost() <-- executed later
In that case one EH iteration can skip autoresume on entry and still drop a runtime PM reference on exit. That leaves an unmatched runtime PM put and can trigger a runtime PM usage count underflow.
Fix this by making ehnoresume a regular bool so it can be accessed with READONCE() and WRITEONCE(). Snapshot it once per EH iteration and use that snapshot for both runtime PM get and put decisions.
Affected Software
Event History
Frequently Asked Questions
Under what conditions can this occur?
The issue requires a SCSI error-handling iteration to overlap with a power-management-triggered error path that changes shost->eh_noresume. In the described flow, the EH thread skips the runtime PM get while eh_noresume is set, then later performs the runtime PM put after the flag has been cleared.
What is the operational impact if the issue is triggered?
The mismatched runtime PM operations can cause a runtime PM usage-count underflow. The affected behavior is in the Linux kernel SCSI core error-handling path.
How does the fix prevent the race?
The fix makes eh_noresume a regular bool accessed with READ_ONCE() and WRITE_ONCE(). It snapshots the value once for each error-handling iteration and uses that same value for both the runtime PM get and put decisions.