CVE-2022-49789
Estado: ModificadaAlta (7.8)—
In the Linux kernel, the following vulnerability has been resolved:
scsi: zfcp: Fix double free of FSF request when qdio send fails
We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again).
In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]).
Leer descripción completaMostrar menos
For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice).
If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice.
The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice:
Detalles técnicos trazas, registros y código del informe original
list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:62!
monitor event: 0040 ilc:2 [#1] PREEMPT SMP
Modules linked in: ...
CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded
Hardware name: ...
Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)
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
Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6
0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8
00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800
00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70
Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336
00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8
#00000003cbeea1f4: af000000 mc 0,0
>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
Call Trace:
[<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140
([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140)
[<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]
[<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]
---truncated---CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Puntuación base: 7.8
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.20%
- Percentil entre todas las CVEs puntuadas: 9
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
🎯 Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1068Exploitation for Privilege Escalationprivilege escalation75 % - Impacto principal
T1059Command and Scripting Interpreterexecution60 %
Vulnerabilidad local (AV:L/PR:L) que permite escalada de privilegios mediante double free en zfcp. El atacante con privilegios locales (PR:L) logra corrupción de memoria y ejecución de código al manipular el manejo incorrecto del tipo de dato en el cache del ID de FSF request.
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
🛡️ Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
CWE
- CWE-415
Referencias
- https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff
- https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96
- https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd
- https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f
- https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab
JSON original (NVD)
Mostrar
{
"id": "CVE-2022-49789",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "HIGH",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.9,
"exploitabilityScore": 1
},
{
"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
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
"lessThan": "1bf8ed585501bb2dd0b5f67c824eab45adfbdccd",
"versionType": "git"
},
{
"status": "affected",
"version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
"lessThan": "d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab",
"versionType": "git"
},
{
"status": "affected",
"version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
"lessThan": "11edbdee4399401f533adda9bffe94567aa08b96",
"versionType": "git"
},
{
"status": "affected",
"version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
"lessThan": "90a49a6b015fa439cd62e45121390284c125a91f",
"versionType": "git"
},
{
"status": "affected",
"version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
"lessThan": "0954256e970ecf371b03a6c9af2cf91b9c4085ff",
"versionType": "git"
}
],
"programFiles": [
"drivers/s390/scsi/zfcp_fsf.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.34"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "2.6.34",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.4.225",
"versionType": "semver",
"lessThanOrEqual": "5.4.*"
},
{
"status": "unaffected",
"version": "5.10.156",
"versionType": "semver",
"lessThanOrEqual": "5.10.*"
},
{
"status": "unaffected",
"version": "5.15.80",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "6.0.10",
"versionType": "semver",
"lessThanOrEqual": "6.0.*"
},
{
"status": "unaffected",
"version": "6.1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/s390/scsi/zfcp_fsf.c"
],
"defaultStatus": "affected"
}
]
}
],
"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": "Modified",
"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ón de solicitud FSF cuando falla el envío de qdio Solíamos usar el tipo incorrecto de entero en 'zfcp_fsf_req_send()' para almacenar en caché el ID de solicitud FSF al enviar una nueva solicitud FSF. Esto se usa en caso de que el envío falle y necesitemos eliminar la solicitud de nuestra tabla hash interna nuevamente (para no mantener una referencia no válida y usarla cuando liberemos la solicitud nuevamente). En 'zfcp_fsf_req_send()' solíamos almacenar en caché el ID como 'int' (con signo y 32 bits de ancho), pero el resto del código zfcp (y la especificación 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é, por lo que ya no coincide con el ID original. El segundo problema, menos obvio, es que, incluso cuando el ID original aún 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é es de tipo con signo, el compilador utilizará una instrucción de extensión 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é a 'zfcp_reqlist_find_rm()' para eliminar la solicitud de nuevo, todos los ceros iniciales se invertirán a unos para extender el signo y ya no coincidirán con el ID original (esto se ha observado en la práctica). Si no podemos eliminar correctamente la solicitud de la tabla hash de nuevo después 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ón de ChpID), terminaremos con una doble liberación. Liberamos incondicionalmente la solicitud en la función de llamada cuando 'zfcp_fsf_req_send()' falla, pero debido a que la solicitud aún está en la tabla hash, terminamos con una referencia de memoria obsoleta, y una vez que el adaptador zfcp se reinicia durante la recuperación o el apagado, terminamos liberando la misma memoria dos veces. Los seguimientos de pila resultantes varían según el kernel y no tienen correlación directa con el lugar donde ocurre el error. A continuación se muestran tres ejemplos que se han visto en la práctica: corrupción de list_del. next->prev debería ser 00000001b9d13800, pero era 00000000dead4ead. (next=00000001bd131a00) ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:62! evento de monitor: 0040 ilc:2 [#1] PREEMPT Módulos 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ódigo Krnl: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >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: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncado---"
}
],
"lastModified": "2026-08-04T10:17:56.377",
"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"
}