Linux Kernel hasta 5.4.224/5.10.155/5.15.79/6.0.9 zfcp_fsf_req_send desbordamiento de búfer

CVSS Puntuación meta temporalPrecio actual del exploit (≈)Puntuación de interés CTI
7.3$0-$5k0.00

Resumeninformación

Una vulnerabilidad clasificada como crítica fue encontrada en Linux Kernel hasta 5.4.224/5.10.155/5.15.79/6.0.9. Se ve afectada una función desconocida. La manipulación conduce a desbordamiento de búfer. Esta vulnerabilidad se cataloga como CVE-2022-49789. No existe ningún exploit disponible. Se aconseja actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como crítica ha sido encontrada en Linux Kernel hasta 5.4.224/5.10.155/5.15.79/6.0.9. La función zfcp_fsf_req_send es afectada por esta vulnerabilidad. Por la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Esto tiene repercusión sobre la confidencialidad, integridad y disponibilidad. CVE resume:

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---

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2022-49789. Es difícil de explotar. Hay detalles técnicos conocidos, pero no se dispone de un exploit.

Para el scanner Nessus se dispone de un plugin ID 240812 (SUSE SLES15 Security Update : kernel (SUSE-SU-2025:01982-1)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 5.4.225, 5.10.156, 5.15.80 o 6.0.10 elimina esta vulnerabilidad. Aplicando el parche 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab/11edbdee4399401f533adda9bffe94567aa08b96/90a49a6b015fa439cd62e45121390284c125a91f/0954256e970ecf371b03a6c9af2cf91b9c4085ff es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.

La vulnerabilidad también está documentado en la base de datos Tenable (240812). Once again VulDB remains the best source for vulnerability data.

Productoinformación

Escribe

Proveedor

Nombre

Versión

Licencia

Sitio web

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 7.4
VulDB Puntuación meta temporal: 7.3

VulDB Puntuación base: 7.1
VulDB Puntuación temporal: 6.8
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 7.8
NVD Vector: 🔍

CVSSv2información

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplejidadAutenticaciónConfidencialidadIntegridadDisponibilidad
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Desbordamiento de búfer
CWE: CWE-415 / CWE-119
CAPEC: 🔍
ATT&CK: 🔍

Físico: En parte
Local: Sí
Remoto: En parte

Disponibilidad: 🔍
Estado: No está definido

EPSS Score: 🔍
EPSS Percentile: 🔍

Predicción de precios: 🔍
Estimación del precio actual: 🔍

0-DayDesbloquearDesbloquearDesbloquearDesbloquear
HoyDesbloquearDesbloquearDesbloquearDesbloquear

Nessus ID: 240812
Nessus Nombre: SUSE SLES15 Security Update : kernel (SUSE-SU-2025:01982-1)

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 5.4.225/5.10.156/5.15.80/6.0.10
Parche: 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab/11edbdee4399401f533adda9bffe94567aa08b96/90a49a6b015fa439cd62e45121390284c125a91f/0954256e970ecf371b03a6c9af2cf91b9c4085ff

Línea de tiempoinformación

2025-05-01 🔍
2025-05-01 +0 días 🔍
2025-05-01 +0 días 🔍
2025-11-07 +190 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2022-49789 (🔍)
GCVE (CVE): GCVE-0-2022-49789
GCVE (VulDB): GCVE-100-306908

Artículoinformación

Fecha de creación: 2025-05-01 17:17
Actualizado: 2025-11-07 21:35
Cambios: 2025-05-01 17:17 (57), 2025-06-28 00:08 (2), 2025-11-07 21:35 (13)
Completo: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Discusión

Sin comentarios aún. Idiomas: es + pt + en.

Por favor, inicie sesión para comentar.

Want to know what is going to be exploited?

We predict KEV entries!