EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
- •No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS v2: —Exploit: None knownExposed services: Not assessed
No fix is confirmed yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for the fix.
The CVE record's CNA (kernel.org) lists Linux versions 6.1.183 up to but not including 6.1.191, 6.6.151 up to but not including 6.6.161, 6.12.103 up to but not including 6.12.115, 6.18.44 up to but not including 6.18.59 and 1 more range as affected, and Linux versions before 7.2 and 7.3 and later as unaffected. No release containing a fix is confirmed on record.
In the Linux kernel, the following vulnerability has been resolved:
scsi: libsas: Fix SMP IO deadlock during HA resume
smp_execute_task_sg() calls pm_runtime_get_sync() on the host before
issuing an SMP command. When that command is itself issued from the HA
resume path, the get_sync() deadlocks: it waits for the ongoing resume
(the device is RPM_RESUMING), while the resume is blocked in
sas_drain_work() waiting for that same SMP IO to complete.
The deadlock needs an expander-attached SATA disk. During
sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata()
-> ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for
such a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() ->
sas_phy_reset() -> sas_smp_phy_control() ->
smp_execute_task_sg()). Direct-attached SATA resets through
lldd_control_phy() and SSP devices use TMFs, so neither hits this.
Replace the get_sync()/put_sync() pair with
pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only
needs to hold off autosuspend while the SMP is in flight, and it must
not try to resume the host: a sync resume issued from the HA resume path
itself is what deadlocks, and by the time sas_resume_ha() runs, hw_init
has already reinitialized the hardware, so the device is accessible
without one.
The usage reference is still required. Discovery work normally runs
inside an event worker's PM reference, taken at sas_notify_port_event()
notify time and held until the handler has flushed the disco
queue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN
from within the revalidation worker itself, and flush_workqueue() does
not wait for work items queued during execution, so that chained
revalidation runs with no outer PM reference - without the
get_noresume(), its SMP could race autosuspend.
For the BSG path, sas_smp_handler() is the only caller which may find
the host autosuspended: expander SMP requests do not go through any SCSI
device request queue, so nothing else in that path holds the host
awake. Resume it there with pm_runtime_resume_and_get() and check the
result.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
- EG Severity
- Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
- EG Likelihood
- 0.2% within 30 daysSource: FIRST EPSS. FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.
The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it