FKIE_CVE-2026-23110

Vulnerability from fkie_nvd - Published: 2026-02-04 17:16 - Updated: 2026-02-06 17:16
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Wake up the error handler when final completions race against each other The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count. This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands. Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task. This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.
Impacted products
Vendor Product Version

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Wake up the error handler when final completions race against each other\n\nThe fragile ordering between marking commands completed or failed so\nthat the error handler only wakes when the last running command\ncompletes or times out has race conditions. These race conditions can\ncause the SCSI layer to fail to wake the error handler, leaving I/O\nthrough the SCSI host stuck as the error state cannot advance.\n\nFirst, there is an memory ordering issue within scsi_dec_host_busy().\nThe write which clears SCMD_STATE_INFLIGHT may be reordered with reads\ncounting in scsi_host_busy(). While the local CPU will see its own\nwrite, reordering can allow other CPUs in scsi_dec_host_busy() or\nscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to\nsee a host busy equal to the host_failed count.\n\nThis race condition can be prevented with a memory barrier on the error\npath to force the write to be visible before counting host busy\ncommands.\n\nSecond, there is a general ordering issue with scsi_eh_inc_host_failed(). By\ncounting busy commands before incrementing host_failed, it can race with a\nfinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does\nnot see host_failed incremented but scsi_eh_inc_host_failed() counts busy\ncommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),\nresulting in neither waking the error handler task.\n\nThis needs the call to scsi_host_busy() to be moved after host_failed is\nincremented to close the race condition."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:\n\nscsi: core: Despertar al manejador de errores cuando las finalizaciones finales compiten entre s\u00ed\n\nEl ordenamiento fr\u00e1gil entre marcar comandos como completados o fallidos, de modo que el manejador de errores solo se despierte cuando el \u00faltimo comando en ejecuci\u00f3n se complete o agote el tiempo de espera, tiene condiciones de carrera. Estas condiciones de carrera pueden hacer que la capa SCSI no despierte al manejador de errores, dejando la E/S a trav\u00e9s del host SCSI atascada ya que el estado de error no puede avanzar.\n\nPrimero, hay un problema de ordenamiento de memoria dentro de scsi_dec_host_busy(). La escritura que borra SCMD_STATE_INFLIGHT puede reordenarse con lecturas que cuentan en scsi_host_busy(). Si bien la CPU local ver\u00e1 su propia escritura, la reordenaci\u00f3n puede permitir que otras CPU en scsi_dec_host_busy() o scsi_eh_inc_host_failed() vean un recuento de ocupaci\u00f3n elevado, lo que hace que ninguna CPU vea un host ocupado igual al recuento de host_failed.\n\nEsta condici\u00f3n de carrera puede evitarse con una barrera de memoria en la ruta de error para forzar que la escritura sea visible antes de contar los comandos de host ocupados.\n\nSegundo, hay un problema de ordenamiento general con scsi_eh_inc_host_failed(). Al contar los comandos ocupados antes de incrementar host_failed, puede competir con un comando final en scsi_dec_host_busy(), de modo que scsi_dec_host_busy() no ve host_failed incrementado, pero scsi_eh_inc_host_failed() cuenta los comandos ocupados antes de que SCMD_STATE_INFLIGHT sea borrado por scsi_dec_host_busy(), lo que resulta en que ninguno despierte la tarea del manejador de errores.\n\nEsto requiere que la llamada a scsi_host_busy() se mueva despu\u00e9s de que host_failed se incremente para cerrar la condici\u00f3n de carrera."
    }
  ],
  "id": "CVE-2026-23110",
  "lastModified": "2026-02-06T17:16:25.900",
  "metrics": {},
  "published": "2026-02-04T17:16:21.880",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/219f009ebfd1ef3970888ee9eef4c8a06357f862"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/64ae21b9c4f0c7e60cf47a53fa7ab68852079ef0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6d9a367be356101963c249ebf10ea10b32886607"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9fdc6f28d5e81350ab1d2cac8389062bd09e61e1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/cc872e35c0df80062abc71268d690a2f749e542e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/fe2f8ad6f0999db3b318359a01ee0108c703a8c3"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…