CVE-2021-47192

{"id": "CVE-2021-47192", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.3, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "LOW"}, "impactScore": 1.4, "exploitabilityScore": 3.9}]}, "published": "2024-04-10T19:15:47.710", "references": [{"url": "https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-667"}]}], "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\u00f3n agregada con: commit f0f82e2476f6 (\"scsi: core: Fix capacity set to zero after offlinining device\") El problema es que despu\u00e9s de la recuperaci\u00f3n de iSCSI, iscsid llamar\u00e1 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\u00e1 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\u00e1 verdadero (el estado del host todav\u00eda est\u00e1 en recuperaci\u00f3n) y la E/S simplemente se volver\u00e1 a poner en cola. scsi_send_eh_cmnd() nunca podr\u00e1 tomar el state_mutex para finalizar el manejo de errores. Para evitar el punto muerto, mueva el c\u00f3digo relacionado con el rescan a despu\u00e9s de que eliminemos el state_mutex. Esto tambi\u00e9n agrega una verificaci\u00f3n para ver si ya estamos en el estado de ejecuci\u00f3n. Esto evita escaneos adicionales y ayuda al caso iscsid donde si la clase de transporte ya ha puesto en l\u00ednea el dispositivo durante su proceso de recuperaci\u00f3n, entonces no necesitamos espacio de usuario para hacerlo nuevamente y posiblemente bloquear ese daemon."}], "lastModified": "2025-04-30T16:26:13.617", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "2432EB65-24F3-4C7E-9C36-92BE00674FF3", "versionEndExcluding": "5.4.162", "versionStartIncluding": "5.4.143"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "970F8F7D-4D7C-41F2-9CFC-5213C9C730D8", "versionEndExcluding": "5.10.82", "versionStartIncluding": "5.10.61"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "896351CB-835A-4A66-B61F-FDCE8A0EFD31", "versionEndExcluding": "5.15.5", "versionStartIncluding": "5.13.13"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.16:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "357AA433-37E8-4323-BFB2-3038D6E4B414"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}