Odebrany

CVE-2026-99202

opublikowano: 28.10.2026, 12:17

modyfikacja: 28.10.2026, 12:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

scsi: libsas: Napraw zakleszczenie SMP IO podczas wznawiania HA

smp_execute_task_sg() wywołuje wcześniej funkcję pm_runtime_get_sync() na hoście
wydanie polecenia SMP. Kiedy to polecenie jest samo wydane przez HA
wznowienia, funkcja get_sync() zatrzymuje się: czeka na trwające wznowienie
(urządzenie ma RPM_RESUMING), podczas gdy wznowienie jest zablokowane
sas_drain_work() czeka na zakończenie tego samego operacji we/wy SMP.

Zakleszczenie wymaga podłączonego dysku SATA z ekspanderem. Podczas
sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata()
-> ata_sas_port_resume() żąda ATA_EH_RESET i twardy reset dla
taki dysk odbywa się poprzez SMP PHY Control (sas_ata_hard_reset() ->
sas_phy_reset() -> sas_smp_phy_control() ->
smp_execute_task_sg()). Bezpośrednio podłączony SATA resetuje się
Urządzenia lldd_control_phy() i SSP używają TMF, więc żadne z nich nie trafia w to.

Zamień parę get_sync()/put_sync() na
pm_runtime_get_noresume()/pm_runtime_put(). Tylko smp_execute_task_sg().
musi wstrzymać automatyczne zawieszenie, gdy SMP jest w locie, i musi
nie próbuj wznawiać hosta: wznowienie synchronizacji wydane ze ścieżki wznowienia HA
samo w sobie powoduje zakleszczenie i do czasu uruchomienia sas_resume_ha() hw_init
ponownie zainicjował sprzęt, więc urządzenie jest dostępne
bez jednego.

Odniesienie do użycia jest nadal wymagane. Prace odkrywcze przebiegają normalnie
wewnątrz odniesienia do PM pracownika wydarzenia, pobranego z sas_notify_port_event()
powiadomić czas i przytrzymać, aż przewodnik spuści dyskotekę
kolejka. sas_rediscover_ex_phy(), jednak ponownie kolejkuje DISCE_REVALIDATE_DOMAIN
z samego procesu rewalidacyjnego, a funkcja Flush_workqueue() to robi
nie czekaj na elementy pracy ustawione w kolejce podczas wykonywania, tak aby były powiązane
ponowna walidacja przebiega bez zewnętrznego odniesienia PM - bez
get_noresume(), jego SMP może przyspieszyć automatyczne zawieszenie.

W przypadku ścieżki BSG jedyną funkcją wywołującą, która może znaleźć, jest sas_smp_handler().
host automatycznie zawieszony: żądania SMP ekspandera nie przechodzą przez żaden SCSI
kolejka żądań urządzeń, więc nic innego w tej ścieżce nie zatrzymuje hosta
obudzony. Wznów to za pomocą pm_runtime_resume_and_get() i sprawdź
wynik.

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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve