{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-04-14T18:51:35.727","vulnerabilities":[{"cve":{"id":"CVE-2021-47192","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2024-04-10T19:15:47.710","lastModified":"2025-04-30T16:26:13.617","vulnStatus":"Analyzed","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: sysfs: Fix hang when device state is set via sysfs\n\nThis fixes a regression added with:\n\ncommit f0f82e2476f6 (\"scsi: core: Fix capacity set to zero after\nofflinining device\")\n\nThe problem is that after iSCSI recovery, iscsid will call into the kernel\nto set the dev's state to running, and with that patch we now call\nscsi_rescan_device() with the state_mutex held. If the SCSI error handler\nthread is just starting to test the device in scsi_send_eh_cmnd() then it's\ngoing to try to grab the state_mutex.\n\nWe are then stuck, because when scsi_rescan_device() tries to send its I\/O\nscsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery()\nwhich will return true (the host state is still in recovery) and I\/O will\njust be requeued. scsi_send_eh_cmnd() will then never be able to grab the\nstate_mutex to finish error handling.\n\nTo prevent the deadlock move the rescan-related code to after we drop the\nstate_mutex.\n\nThis also adds a check for if we are already in the running state. This\nprevents extra scans and helps the iscsid case where if the transport class\nhas already onlined the device during its recovery process then we don't\nneed userspace to do it again plus possibly block that daemon."},{"lang":"es","value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: sysfs: Fix hang when device state is set via sysfs Esto corrige una regresión agregada con: commit f0f82e2476f6 (\"scsi: core: Fix capacity set to zero after offlinining device\") El problema es que después de la recuperación de iSCSI, iscsid llamará al kernel para establecer el estado del dev en running, y con ese parche ahora llamamos a scsi_rescan_device() con el state_mutex retenido. Si el hilo del controlador de errores SCSI está empezando a probar el dispositivo en scsi_send_eh_cmnd() entonces va a intentar capturar el state_mutex. Entonces estamos atascados, porque cuando scsi_rescan_device() intenta enviar su E\/S, scsi_queue_rq() llama a -> scsi_host_queue_ready() -> scsi_host_in_recovery() que devolverá verdadero (el estado del host todavía está en recuperación) y la E\/S simplemente se volverá a poner en cola. scsi_send_eh_cmnd() nunca podrá tomar el state_mutex para finalizar el manejo de errores. Para evitar el punto muerto, mueva el código relacionado con el rescan a después de que eliminemos el state_mutex. Esto también agrega una verificación para ver si ya estamos en el estado de ejecución. Esto evita escaneos adicionales y ayuda al caso iscsid donde si la clase de transporte ya ha puesto en línea el dispositivo durante su proceso de recuperación, entonces no necesitamos espacio de usuario para hacerlo nuevamente y posiblemente bloquear ese daemon."}],"metrics":{"cvssMetricV31":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:L\/I:N\/A:N","baseScore":5.3,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"NONE"},"exploitabilityScore":3.9,"impactScore":1.4}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-667"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.4.143","versionEndExcluding":"5.4.162","matchCriteriaId":"2432EB65-24F3-4C7E-9C36-92BE00674FF3"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.10.61","versionEndExcluding":"5.10.82","matchCriteriaId":"970F8F7D-4D7C-41F2-9CFC-5213C9C730D8"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.13.13","versionEndExcluding":"5.15.5","matchCriteriaId":"896351CB-835A-4A66-B61F-FDCE8A0EFD31"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.16:rc1:*:*:*:*:*:*","matchCriteriaId":"357AA433-37E8-4323-BFB2-3038D6E4B414"}]}]}],"references":[{"url":"https:\/\/git.kernel.org\/stable\/c\/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/a792e0128d232251edb5fdf42fb0f9fbb0b44a73","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/bcc0e3175a976b7fa9a353960808adb0bb49ead8","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/edd783162bf2385b43de6764f2d4c6e9f4f6be27","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/a792e0128d232251edb5fdf42fb0f9fbb0b44a73","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/bcc0e3175a976b7fa9a353960808adb0bb49ead8","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]},{"url":"https:\/\/git.kernel.org\/stable\/c\/edd783162bf2385b43de6764f2d4c6e9f4f6be27","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]}]}}]}