CVE-2022-49789

{"id": "CVE-2022-49789", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.8, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.8}]}, "published": "2025-05-01T15:16:02.143", "references": [{"url": "https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-415"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: zfcp: Fix double free of FSF request when qdio send fails\n\nWe used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache\nthe FSF request ID when sending a new FSF request. This is used in case the\nsending fails and we need to remove the request from our internal hash\ntable again (so we don't keep an invalid reference and use it when we free\nthe request again).\n\nIn 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32\nbit wide), but the rest of the zfcp code (and the firmware specification)\nhandles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x\nELF ABI]). For one this has the obvious problem that when the ID grows\npast 32 bit (this can happen reasonably fast) it is truncated to 32 bit\nwhen storing it in the cache variable and so doesn't match the original ID\nanymore. The second less obvious problem is that even when the original ID\nhas not yet grown past 32 bit, as soon as the 32nd bit is set in the\noriginal ID (0x80000000 = 2'147'483'648) we will have a mismatch when we\ncast it back to 'unsigned long'. As the cached variable is of a signed\ntype, the compiler will choose a sign-extending instruction to load the 32\nbit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once\nwe pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the\nrequest again all the leading zeros will be flipped to ones to extend the\nsign and won't match the original ID anymore (this has been observed in\npractice).\n\nIf we can't successfully remove the request from the hash table again after\n'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify\nthe adapter about new work because the adapter is already gone during\ne.g. a ChpID toggle) we will end up with a double free. We unconditionally\nfree the request in the calling function when 'zfcp_fsf_req_send()' fails,\nbut because the request is still in the hash table we end up with a stale\nmemory reference, and once the zfcp adapter is either reset during recovery\nor shutdown we end up freeing the same memory twice.\n\nThe resulting stack traces vary depending on the kernel and have no direct\ncorrelation to the place where the bug occurs. Here are three examples that\nhave been seen in practice:\n\n list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:62!\n monitor event: 0040 ilc:2 [#1] PREEMPT SMP\n Modules linked in: ...\n CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded\n Hardware name: ...\n Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\n Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6\n 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8\n 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800\n 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70\n Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336\n 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8\n #00000003cbeea1f4: af000000 mc 0,0\n >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78\n 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48\n 00000003cbeea204: b9040043 lgr %r4,%r3\n 00000003cbeea208: b9040051 lgr %r5,%r1\n 00000003cbeea20c: b9040032 lgr %r3,%r2\n Call Trace:\n [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140\n ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140)\n [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]\n [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: zfcp: Arregla doble liberaci\u00f3n de solicitud FSF cuando falla el env\u00edo de qdio Sol\u00edamos usar el tipo incorrecto de entero en 'zfcp_fsf_req_send()' para almacenar en cach\u00e9 el ID de solicitud FSF al enviar una nueva solicitud FSF. Esto se usa en caso de que el env\u00edo falle y necesitemos eliminar la solicitud de nuestra tabla hash interna nuevamente (para no mantener una referencia no v\u00e1lida y usarla cuando liberemos la solicitud nuevamente). En 'zfcp_fsf_req_send()' sol\u00edamos almacenar en cach\u00e9 el ID como 'int' (con signo y 32 bits de ancho), pero el resto del c\u00f3digo zfcp (y la especificaci\u00f3n del firmware) maneja el ID como 'unsigned long'/'u64' (sin signo y 64 bits de ancho [s390x ELF ABI]). Por un lado, esto presenta el problema obvio de que, cuando el ID supera los 32 bits (esto puede ocurrir con relativa rapidez), se trunca a 32 bits al almacenarlo en la variable de cach\u00e9, por lo que ya no coincide con el ID original. El segundo problema, menos obvio, es que, incluso cuando el ID original a\u00fan no supera los 32 bits, en cuanto se establece el bit 32 en el ID original (0x80000000 = 2'147'483'648), se produce una discrepancia al convertirlo a 'unsigned long'. Como la variable en cach\u00e9 es de tipo con signo, el compilador utilizar\u00e1 una instrucci\u00f3n de extensi\u00f3n de signo para cargar la variable de 32 bits en un registro de 64 bits (p. ej., 'lgf %r11,188(%r15)'). Entonces, una vez que pasamos la variable en cach\u00e9 a 'zfcp_reqlist_find_rm()' para eliminar la solicitud de nuevo, todos los ceros iniciales se invertir\u00e1n a unos para extender el signo y ya no coincidir\u00e1n con el ID original (esto se ha observado en la pr\u00e1ctica). Si no podemos eliminar correctamente la solicitud de la tabla hash de nuevo despu\u00e9s de que 'zfcp_qdio_send()' falle (esto sucede regularmente cuando zfcp no puede notificar al adaptador sobre el nuevo trabajo porque el adaptador ya se ha ido durante, por ejemplo, una conmutaci\u00f3n de ChpID), terminaremos con una doble liberaci\u00f3n. Liberamos incondicionalmente la solicitud en la funci\u00f3n de llamada cuando 'zfcp_fsf_req_send()' falla, pero debido a que la solicitud a\u00fan est\u00e1 en la tabla hash, terminamos con una referencia de memoria obsoleta, y una vez que el adaptador zfcp se reinicia durante la recuperaci\u00f3n o el apagado, terminamos liberando la misma memoria dos veces. Los seguimientos de pila resultantes var\u00edan seg\u00fan el kernel y no tienen correlaci\u00f3n directa con el lugar donde ocurre el error. A continuaci\u00f3n se muestran tres ejemplos que se han visto en la pr\u00e1ctica: corrupci\u00f3n de list_del. next-&gt;prev deber\u00eda ser 00000001b9d13800, pero era 00000000dead4ead. (next=00000001bd131a00) ------------[ cortar aqu\u00ed ]------------ \u00a1ERROR del kernel en lib/list_debug.c:62! evento de monitor: 0040 ilc:2 [#1] PREEMPT M\u00f3dulos SMP vinculados: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: cargado Nombre del hardware: ... Krnl PSW: 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 00000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 C\u00f3digo Krnl: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 &gt;00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Rastreo de llamadas: [&lt;00000003cbeea1f8&gt;] __list_del_entry_valid+0x98/0x140 ([&lt;00000003cbeea1f4&gt;] __list_del_entry_valid+0x94/0x140) [&lt;000003ff7ff502fe&gt;] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [&lt;000003ff7ff49cd0&gt;] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncado---"}], "lastModified": "2025-11-07T19:32:49.943", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "7EC2FFE7-F827-482A-B363-9F9180A0095A", "versionEndExcluding": "5.4.225", "versionStartIncluding": "2.6.34"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E2152F3D-E6D3-405D-B0BE-911B8B6E2EE6", "versionEndExcluding": "5.10.156", "versionStartIncluding": "5.5"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "51BBEF3B-79F5-4D4C-ADBA-F34DA0E2465C", "versionEndExcluding": "5.15.80", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "64F9ADD1-3ADB-4D66-A00F-4A83010B05F0", "versionEndExcluding": "6.0.10", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E7E331DA-1FB0-4DEC-91AC-7DA69D461C11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "17F0B248-42CF-4AE6-A469-BB1BAE7F4705"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E2422816-0C14-4B5E-A1E6-A9D776E5C49B"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1C6E00FE-5FB9-4D20-A1A1-5A32128F9B76"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc5:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "35B26BE4-43A6-4A36-A7F6-5B3F572D9186"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}