Linux Kernel hasta 5.17.2 mm/usercopy.c virt_addr_valid desbordamiento de búfer

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

Resumeninformación

Una vulnerabilidad ha sido encontrada en Linux Kernel hasta 5.4.189/5.10.110/5.15.33/5.16.19/5.17.2 y clasificada como crítica. Se ve afectada una función desconocida del archivo mm/usercopy.c. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Esta vulnerabilidad se registra como CVE-2022-49067. No hay ningún exploit disponible. Se sugiere actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.4.189/5.10.110/5.15.33/5.16.19/5.17.2 y clasificada como crítica. La función virt_addr_valid del archivo mm/usercopy.c 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. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc: Arreglar virt_addr_valid() para Book3E de 64 bits y mpe de 32 bits: En Book3E de 64 bits, el espacio vmalloc comienza en 0x8000000000000000. Debido a la forma en que funciona __pa() tenemos: __pa(0x8000000000000000) == 0, y por lo tanto virt_to_pfn(0x8000000000000000) == 0, y por lo tanto virt_addr_valid(0x8000000000000000) == true Lo cual es incorrecto, virt_addr_valid() debería ser falso para el espacio vmalloc. De hecho, todas las direcciones vmalloc que tengan un alias con un PFN válido devolverán verdadero desde virt_addr_valid(). Esto puede causar errores con usercopy reforzado como lo describe a continuación Kefeng Wang: Al ejecutar ethtool eth0 en Book3E de 64 bits, ocurrió un ERROR: usercopy: ¡Intento de exposición de memoria del kernel detectado desde un objeto SLUB que no está en la página SLUB! (desplazamiento 0, tamaño 1048). ERROR del kernel en mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (no confiable) __check_heap_object+0x168/0x190 __check_object_size+0x1a0/0x200 dev_ethtool+0x2494/0x2b20 dev_ioctl+0x5d0/0x770 sock_do_ioctl+0xf0/0x1d0 sock_ioctl+0x3ec/0x5a0 __se_sys_ioctl+0xf0/0x160 system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 El código se muestra a continuación, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) Los datos se asignan mediante vmalloc(), virt_addr_valid(ptr) devolverá verdadero en Book3E de 64 bits, lo que genera el pánico. Como lo hace el commit 4dd7554a6456 ("powerpc/64: Agregar comprobaciones VIRTUAL_BUG_ON para direcciones __va y __pa"), asegúrese de que la dirección virt sea superior a PAGE_OFFSET en virt_addr_valid() para 64 bits, y agregue también una comprobación de límite superior para asegurarse de que la dirección virt esté por debajo de high_memory. Mientras tanto, para 32 bits PAGE_OFFSET es la dirección virtual del inicio de lowmem, high_memory es la dirección virtual baja superior, la comprobación es adecuada para 32 bits, esto solucionará también el problema mencionado en el commit 602946ec2f90 ("powerpc: Set max_mapnr properly"). En 32 bits hay un problema similar con la memoria alta, que se solucionó en el commit 602946ec2f90 ("powerpc: Set max_mapnr properly"), pero ese commit rompe highmem y necesita ser revertido. No podemos arreglar fácilmente __pa(), tenemos código que depende de su comportamiento actual. Así que por ahora agregue comprobaciones adicionales a virt_addr_valid(). Para Book3S de 64 bits las comprobaciones adicionales no son necesarias, la combinación de virt_to_pfn() y pfn_valid() debería producir el resultado correcto, pero son inofensivas. [mpe: Agregar detalles adicionales del registro de cambios]

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2022-49067. La explotación se considera fácil. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.

Una actualización a la versión 5.4.190, 5.10.111, 5.15.34, 5.16.20 o 5.17.3 elimina esta vulnerabilidad. Aplicando el parche deab81144d5a043f42804207fb76cfbd8a806978/d36febbcd537fcc50284e8b89609632d0146529f/fddb88bd266f4513abab7c36bca98935c9148a98/a3727c25eacd7e437c4f560957fa3a376fe93e6b/cbc065efcba000ad8f615f506ebe61b6d3c5145b/ffa0b64e3be58519ae472ea29a1a1ad681e32f48 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.

Statistical analysis made it clear that VulDB provides the best quality 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: 6.8
VulDB Puntuación meta temporal: 6.6

VulDB Puntuación base: 8.0
VulDB Puntuación temporal: 7.6
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 5.5
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-122 / 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

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.190/5.10.111/5.15.34/5.16.20/5.17.3
Parche: deab81144d5a043f42804207fb76cfbd8a806978/d36febbcd537fcc50284e8b89609632d0146529f/fddb88bd266f4513abab7c36bca98935c9148a98/a3727c25eacd7e437c4f560957fa3a376fe93e6b/cbc065efcba000ad8f615f506ebe61b6d3c5145b/ffa0b64e3be58519ae472ea29a1a1ad681e32f48

Línea de tiempoinformación

2025-02-26 🔍
2025-02-26 +0 días 🔍
2025-02-26 +0 días 🔍
2025-10-15 +231 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2022-49067 (🔍)
GCVE (CVE): GCVE-0-2022-49067
GCVE (VulDB): GCVE-100-297347

Artículoinformación

Fecha de creación: 2025-02-26 11:16
Actualizado: 2025-10-15 04:29
Cambios: 2025-02-26 11:16 (59), 2025-10-15 04:29 (12)
Completo: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discusión

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

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Interested in the pricing of exploits?

See the underground prices here!