Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - scsi：libsas：在發出 SMP 命令之前，在主機上修正 HA 還原 smp_execute_task_sg（） 呼叫 pm_runtime_get_sync（） 期間的 SMP IO 鎖死。當該命令本身從 HA 還原路徑發出時，get_sync（） 會鎖死：它會等待正在進行的還原 （裝置RPM_RESUMING），而繼續會在 sas_drain_work（） 中封鎖，等待相同的 SMP IO 完成。鎖死需要一個擴展器連接的 SATA 磁盤。在 sas_resume_ha（） -> sas_drain_work（） 期間，DISCE_RESUME -> sas_resume_sata（） -> ata_sas_port_resume（） 要求ATA_EH_RESET，而此類磁碟的硬重設是透過 SMP PHY 控制 （sas_ata_hard_reset（） -> sas_phy_reset（） -> sas_smp_phy_control（） -> smp_execute_task_sg（）） 完成的。
    透過 lldd_control_phy（） 和 SSP 裝置的直接連接 SATA 重置使用 TMF，因此兩者都不會達到此目標。
    將 get_sync（）/put_sync（） 配對替換為 pm_runtime_get_noresume（）/pm_runtime_put（）。
    smp_execute_task_sg（） 只需要在 SMP 正在傳輸時延遲自動暫停，並且不得嘗試恢復主機：從 HA 恢復路徑本身發出的同步恢復是鎖死的原因，當 sas_resume_ha（） 運行時，hw_init 已經重新初始化了硬件，因此可以在沒有硬件的情況下訪問設備。仍需提供使用參考。探索工作通常會在事件工作程式的 PM 參照中執行，在 sas_notify_port_event（） 通知時間取得，並保留，直到處理常式排清 disco 佇列為止。不過，sas_rediscover_ex_phy（） 會從重新驗證背景工作程式本身內重新排隊DISCE_REVALIDATE_DOMAIN，而且 flush_workqueue（） 不會等候在執行期間排入佇列的工作項目，因此鏈結重新驗證會在沒有外部 PM 參照的情況下執行 - 如果沒有 get_noresume（），其 SMP 可能會爭用自動暫停。
    對於 BSG 路徑，sas_smp_handler（） 是唯一可能發現主機自動暫停的呼叫端：擴展器 SMP 要求不會通過任何 SCSI 裝置要求佇列，因此該路徑中沒有其他任何內容會讓主機保持喚醒狀態。使用 pm_runtime_resume_and_get（） 恢復它並檢查結果。（CVE-2026-99202）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - scsi：libsas：修复发出 SMP 命令之前 HA 恢复 smp_execute_task_sg（） 调用主机上的 pm_runtime_get_sync（） 期间的 SMP IO 死锁。当该命令本身从 HA 恢复路径发出时，get_sync（） 会死锁：它会等待正在进行的恢复（设备RPM_RESUMING），而恢复会在 sas_drain_work（） 中阻断，等待相同的 SMP IO 完成。死锁需要连接扩展器的 SATA 磁盘。在 sas_resume_ha（） -> sas_drain_work（） 期间，DISCE_RESUME -> sas_resume_sata（） -> ata_sas_port_resume（） 请求ATA_EH_RESET，此类磁盘的硬重置通过 SMP PHY CONTROL （sas_ata_hard_reset（） -> sas_phy_reset（） -> sas_smp_phy_control（） -> smp_execute_task_sg（））完成。
    通过 lldd_control_phy（） 和 SSP 设备进行的直连 SATA 重置会使用 TMF，因此两者都不会达到此问题。
    将 get_sync（）/put_sync（） 对替换为 pm_runtime_get_noresume（）/pm_runtime_put（）。
    smp_execute_task_sg（） 只需要在 SMP 正在运行时暂停自动暂停，且不得尝试恢复主机：从 HA 恢复路径本身发出的同步恢复会造成死锁，当 sas_resume_ha（） 运行时，hw_init 已经重新初始化硬件，因此无需初始化硬件即可访问设备。仍然需要使用参考。发现工作通常在事件工作线程的 PM 引用中运行，在 sas_notify_port_event（） 通知时取得并保留到处理程序刷新 disco 队列为止。但是，sas_rediscover_ex_phy（） 会从重新验证工作线程本身内部重新DISCE_REVALIDATE_DOMAIN排队，而 flush_workqueue（） 不会等待执行期间排队的工作项目，因此链式重新验证运行时没有外部 PM 引用 - 没有 get_noresume（），其 SMP 可能会争用自动暂停。
    对于 BSG 路径，sas_smp_handler（） 是唯一可能发现主机已自动暂停的调用程序：expander SMP 请求不会通过任何 SCSI 设备请求队列，因此该路径中没有其他任何内容使主机保持唤醒。使用 pm_runtime_resume_and_get（） 在该位置恢复并检查结果。（CVE-2026-99202）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - scsi:libsas:SMP コマンドを発行する前にホスト上で HA が smp_execute_task_sg() 呼び出しpm_runtime_get_sync() を再開する際の SMP IO デッドロックを修正します。そのコマンド自体が HA 再開パスから発行されると、get_sync() はデッドロックします。進行中の再開 (デバイスが RPM_RESUMING の場合) を待機しますが、同じ SMP IO が完了するのを待つsas_drain_work() で再開がブロックされます。デッドロックには、エキスパンダーが取り付けられた SATA ディスクが必要です。sas_resume_ha() -> sas_drain_work() の間、 DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() がATA_EH_RESETをリクエストします。このようなディスクのハードリセットは SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()) を介して行われます。
    lldd_control_phy() および SSP デバイスは TMF を使用して直接接続 SATA リセットを行うため、どちらもこれにヒットしません。
    get_sync()/put_sync() ペアを pm_runtime_get_noresume()/pm_runtime_put() に置き換えます。
    smp_execute_task_sg() は SMP の実行中にのみ自動中断を保留する必要があり、ホストの再開を試みてはなりません。HA 再開パス自体から発行された同期再開がデッドロックのものです。sas_resume_ha() が実行される頃には、hw_init はハードウェアを再初期化しているため、ハードウェアがなくてもデバイスはアクセス可能です。使用法のリファレンスは引き続き必要です。ディスカバリー作業は通常、イベントワーカーの PM 参照内で実行され、sas_notify_port_event() 通知時に取得され、ハンドラーがディスコキューをフラッシュするまで保持されます。しかし、sas_rediscover_ex_phy() は再検証ワーカー自身の内部からDISCE_REVALIDATE_DOMAINを再キューに入れ、flush_workqueue() は実行中にキューに入れられた作業アイテムを待機しないため、連鎖的な再検証は外部 PM 参照なしで実行されます。get_noresume() がないと、その SMP が自動中断を競合する可能性があります。
    BSG パスでは、sas_smp_handler() はホストが自動中断状態にあることを発見する唯一の呼び出し元です。エキスパンダー SMP リクエストは SCSI デバイスのリクエストキューを通過しません。したがって、そのパス内の他のものはホストをスリープ状態に保ちません。そこで pm_runtime_resume_and_get() で再開し、結果を確認します。(CVE-2026-99202)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-99202)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
373324	Linux Distros 未修補弱點：CVE-2026-99202	Nessus	Misc.	10/28/2026	11/7/2026	medium
373324	Linux Distros 未修补的漏洞：CVE-2026-99202	Nessus	Misc.	10/28/2026	11/7/2026	medium
373324	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99202	Nessus	Misc.	10/28/2026	11/7/2026	medium
373324	Linux Distros Unpatched Vulnerability : CVE-2026-99202	Nessus	Misc.	10/28/2026	11/7/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium