FKIE_CVE-2026-99202

Vulnerability from fkie_nvd - Published: 2026-10-28 11:17 - Updated: 2026-10-30 13:21
Severity
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/08b95ef36a64c3ae4490794bed3c35d0c3354e85
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6078a5369f9e8d22bb03b8890cb0bb47c91a5017
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7004c18c38aaa2b87164b54dd77c320b4c63b89b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/81e097a064b28b4a1f6ca1a8b433e659c1bd64c0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ab91a558084fdb8cca4919ffb769ca4328e91bbd
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c9fb89246d9922ac0a45d504adb03e0bb971310c
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/scsi/libsas/sas_expander.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "ab91a558084fdb8cca4919ffb769ca4328e91bbd",
              "status": "affected",
              "version": "09357f067122e2e28ec52e27013a1660a1571618",
              "versionType": "git"
            },
            {
              "lessThan": "6078a5369f9e8d22bb03b8890cb0bb47c91a5017",
              "status": "affected",
              "version": "e50a6523a603594a6d92cdecfe11997d639410a3",
              "versionType": "git"
            },
            {
              "lessThan": "7004c18c38aaa2b87164b54dd77c320b4c63b89b",
              "status": "affected",
              "version": "c391b5899dd46485a5893696c12ae3e95a3a7325",
              "versionType": "git"
            },
            {
              "lessThan": "c9fb89246d9922ac0a45d504adb03e0bb971310c",
              "status": "affected",
              "version": "9e24b47ef81d43b3fb1b14294f09991640c79fcc",
              "versionType": "git"
            },
            {
              "lessThan": "08b95ef36a64c3ae4490794bed3c35d0c3354e85",
              "status": "affected",
              "version": "3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845",
              "versionType": "git"
            },
            {
              "lessThan": "81e097a064b28b4a1f6ca1a8b433e659c1bd64c0",
              "status": "affected",
              "version": "3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "b9c44a14062093e9fc2d6bddc696cfceadb482d7",
              "versionType": "git"
            },
            {
              "lessThan": "6.1.191",
              "status": "affected",
              "version": "6.1.183",
              "versionType": "semver"
            },
            {
              "lessThan": "6.6.161",
              "status": "affected",
              "version": "6.6.151",
              "versionType": "semver"
            },
            {
              "lessThan": "6.12.115",
              "status": "affected",
              "version": "6.12.103",
              "versionType": "semver"
            },
            {
              "lessThan": "6.18.59",
              "status": "affected",
              "version": "6.18.44",
              "versionType": "semver"
            },
            {
              "lessThan": "7.2",
              "status": "affected",
              "version": "7.1.8",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/scsi/libsas/sas_expander.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.2"
            },
            {
              "lessThan": "7.2",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.191",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.161",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.115",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.59",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.13",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libsas: Fix SMP IO deadlock during HA resume\n\nsmp_execute_task_sg() calls pm_runtime_get_sync() on the host before\nissuing an SMP command. When that command is itself issued from the HA\nresume path, the get_sync() deadlocks: it waits for the ongoing resume\n(the device is RPM_RESUMING), while the resume is blocked in\nsas_drain_work() waiting for that same SMP IO to complete.\n\nThe deadlock needs an expander-attached SATA disk. During\nsas_resume_ha() -\u003e sas_drain_work(), DISCE_RESUME -\u003e sas_resume_sata()\n-\u003e ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for\nsuch a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() -\u003e\nsas_phy_reset() -\u003e sas_smp_phy_control() -\u003e\nsmp_execute_task_sg()). Direct-attached SATA resets through\nlldd_control_phy() and SSP devices use TMFs, so neither hits this.\n\nReplace the get_sync()/put_sync() pair with\npm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only\nneeds to hold off autosuspend while the SMP is in flight, and it must\nnot try to resume the host: a sync resume issued from the HA resume path\nitself is what deadlocks, and by the time sas_resume_ha() runs, hw_init\nhas already reinitialized the hardware, so the device is accessible\nwithout one.\n\nThe usage reference is still required. Discovery work normally runs\ninside an event worker\u0027s PM reference, taken at sas_notify_port_event()\nnotify time and held until the handler has flushed the disco\nqueue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN\nfrom within the revalidation worker itself, and flush_workqueue() does\nnot wait for work items queued during execution, so that chained\nrevalidation runs with no outer PM reference - without the\nget_noresume(), its SMP could race autosuspend.\n\nFor the BSG path, sas_smp_handler() is the only caller which may find\nthe host autosuspended: expander SMP requests do not go through any SCSI\ndevice request queue, so nothing else in that path holds the host\nawake. Resume it there with pm_runtime_resume_and_get() and check the\nresult."
    }
  ],
  "id": "CVE-2026-99202",
  "lastModified": "2026-10-30T13:21:52.657",
  "metrics": {},
  "published": "2026-10-28T11:17:41.377",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/08b95ef36a64c3ae4490794bed3c35d0c3354e85"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6078a5369f9e8d22bb03b8890cb0bb47c91a5017"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7004c18c38aaa2b87164b54dd77c320b4c63b89b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/81e097a064b28b4a1f6ca1a8b433e659c1bd64c0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ab91a558084fdb8cca4919ffb769ca4328e91bbd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c9fb89246d9922ac0a45d504adb03e0bb971310c"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.