Linux Kernel hasta 6.15.3 SCI kmem_cache_create denegación de servicio

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

Resumeninformación

Se ha identificado una vulnerabilidad clasificada como crítica en Linux Kernel hasta 6.15.3. Se ve afectada una función desconocida del componente SCI Handler. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esta vulnerabilidad está identificada como CVE-2025-38344. No hay ningún exploit disponible. Es recomendable actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 6.15.3 y clasificada como crítica. La función kmem_cache_create del componente SCI Handler es afectada por esta vulnerabilidad. Por la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esto tiene repercusión sobre la la disponibilidad. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: se corrigen las fugas de caché de ACPI parse y parseext. Confirmación de ACPICA 8829e70e1360c81e7a5a901b5d4f48330e021ea5. Soy Seunghun Han y trabajo para el Instituto de Investigación de Seguridad Nacional de Corea del Sur. He estado investigando sobre ACPI y he encontrado una fuga de caché en casos de aborto temprano de ACPI. El registro de arranque de la pérdida de caché ACPI es el siguiente: [0.352414] ACPI: _OSI(Dispositivo de módulo) añadido [0.353182] ACPI: _OSI(Dispositivo de procesador) añadido [0.353182] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.353182] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.356028] ACPI: No se puede iniciar el intérprete ACPI [0.356799] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.360215] kmem_cache_destroy Estado Acpi: La caché Slab todavía tiene objetos [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Rastreo de llamadas: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 Analicé esta fuga de memoria en detalle. Descubrí que las cachés "Acpi-State" y "Acpi-Parse" se fusionaron porque el tamaño de los objetos de la caché era el mismo que el de la caché slab. Finalmente, descubrí que las cachés "Acpi-Parse" y "Acpi-parse_ext" se filtraron mediante el indicador SLAB_NEVER_MERGE de la función kmem_cache_create(). El punto de fuga de caché ACPI real es el siguiente: [0.360101] ACPI: _OSI(Dispositivo de módulo) añadido [0.360101] ACPI: _OSI(Dispositivo de procesador) añadido [0.360101] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.361043] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.364016] ACPI: No se puede iniciar el intérprete ACPI [0.365061] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: La caché Slab aún tiene objetos [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Rastreo de llamadas: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: La caché Slab aún tiene objetos [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Rastreo de llamadas: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncado---

La vulnerabilidad fue publicada el por Seunghun Han (confirmado). El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2025-38344. Es difícil de explotar. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.

Para el scanner Nessus se dispone de un plugin ID 264318 (Oracle Linux 7 / 8 : Unbreakable Enterprise kernel (ELSA-2025-20553)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 o 6.16-rc1 elimina esta vulnerabilidad. Aplicando el parche 1e0e629e88b1f7751ce69bf70cda6d1598d45271/41afebc9a0762aafc35d2df88f4e1b798155a940/960236150cd3f08e13b397dd5ae4ccf7a2986c00/0a119fdaed67566aa3e0b5222dced4d08bbce463/1fee4324b5660de080cefc3fc91c371543bdb8f6/198c2dab022e5e94a99fff267b669d693bc7bb49/3e0c59180ec83bdec43b3d3482cff23d86d380d0/bed18f0bdcd6737a938264a59d67923688696fc4 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 las bases de datos Tenable (264318), EUVD (EUVD-2025-20902) y CERT Bund (WID-SEC-2025-1522). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Afectado

  • Google Container-Optimized OS
  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • IBM QRadar SIEM
  • SUSE openSUSE
  • RESF Rocky Linux
  • Open Source Linux Kernel
  • Dell Avamar
  • Dell NetWorker

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: 5.1
VulDB Puntuación meta temporal: 5.0

VulDB Puntuación base: 4.8
VulDB Puntuación temporal: 4.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: Denegación de servicio
CWE: CWE-401 / CWE-404
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: 264318
Nessus Nombre: Oracle Linux 7 / 8 : Unbreakable Enterprise kernel (ELSA-2025-20553)

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.295/5.10.239/5.15.186/6.1.142/6.6.95/6.12.35/6.15.4/6.16-rc1
Parche: 1e0e629e88b1f7751ce69bf70cda6d1598d45271/41afebc9a0762aafc35d2df88f4e1b798155a940/960236150cd3f08e13b397dd5ae4ccf7a2986c00/0a119fdaed67566aa3e0b5222dced4d08bbce463/1fee4324b5660de080cefc3fc91c371543bdb8f6/198c2dab022e5e94a99fff267b669d693bc7bb49/3e0c59180ec83bdec43b3d3482cff23d86d380d0/bed18f0bdcd6737a938264a59d67923688696fc4

Línea de tiempoinformación

2025-04-16 CVE asignado
2025-07-10 +85 días Aviso publicado
2025-07-10 +0 días Entrada de VulDB creada
2025-12-16 +159 días Última actualización de VulDB

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Investigador: Seunghun Han
Estado: Confirmado

CVE: CVE-2025-38344 (🔒)
GCVE (CVE): GCVE-0-2025-38344
GCVE (VulDB): GCVE-100-315971
EUVD: 🔒
CERT Bund: WID-SEC-2025-1522 - Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service

Artículoinformación

Fecha de creación: 2025-07-10 11:39
Actualizado: 2025-12-16 22:50
Cambios: 2025-07-10 11:39 (60), 2025-07-10 15:39 (1), 2025-09-13 02:34 (2), 2025-10-11 22:57 (7), 2025-11-02 20:59 (1), 2025-12-08 01:19 (1), 2025-12-16 22:50 (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 ▸

Want to know what is going to be exploited?

We predict KEV entries!