Linux Kernel hasta 6.2.6 ext4 fsmap_head desbordamiento de búfer

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

Resumeninformación

Se ha identificado una vulnerabilidad clasificada como problemática en Linux Kernel hasta 6.2.6. Está afectada una función desconocida en el componente ext4. El manejo da lugar a desbordamiento de búfer. Esta vulnerabilidad se conoce como CVE-2023-53143. No se encuentra disponible ningún exploit. Se recomienda actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como problemática fue encontrada en Linux Kernel hasta 6.2.6. La función fsmap_head del componente ext4 es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Los efectos exactos de un ataque exitoso no son conocidos. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige otro error de fsmap de un bloque en sistemas de archivos de 1k Aparentemente, syzbot descubrió que emitir esta llamada FSMAP: Produce este fallo si el sistema de archivos subyacente es un sistema de archivos ext4 de 1k bloques: ¡ERROR del kernel en fs/ext4/ext4.h:3331! Código de operación no válido: 0000 [#1] PREEMPT SMP CPU: 3 PID: 3227965 Comm: xfs_io Contaminado: GWO 6.2.0-rc8-achx Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 01/04/2014 RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] RSP: 0018:ffffc90007c03998 EFLAGS: 00010246 RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000 RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11 RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 R10: ffffc90007c03950 R11: 0000000000000000 R12: 000000000000001 R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398 FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0 Rastreo de llamadas: ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __x64_sys_ioctl+0x82/0xa0 hacer_llamada_al_sistema_64+0x2b/0x80 entrada_LLAMADA_AL_SISTEMA_64_después_de_hwframe+0x46/0xb0 RIP: 0033:0x7fdf20558aff RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 R13: 00005625be70d994 R14: 000000000000800 R15: 000000000000000 Para las llamadas GETFSMAP, el llamador selecciona un dispositivo de bloque físico escribiendo su número de bloque en fsmap_head.fmh_keys[01].fmr_device. Para consultar las asignaciones de un subrango del dispositivo, el byte inicial del rango se escribe en fsmap_head.fmh_keys[0].fmr_physical y el último byte en fsmap_head.fmh_keys[1].fmr_physical. IOWs, para consultar qué asignaciones se superponen con los bytes 3-14 de /dev/sda, debe configurar las entradas de la siguiente manera: fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3}, fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14}, lo que le devolvería lo que esté asignado en los 12 bytes a partir del desplazamiento físico 3. El fallo se debe a una validación de rango insuficiente de keys[1] en ext4_getfsmap_datadev. En sistemas de archivos de 1k bloques, el bloque 0 no forma parte del sistema de archivos, lo que significa que s_first_data_block es distinto de cero. ext4_get_group_no_and_offset resta esta cantidad del argumento blocknr antes de descomponerlo en un número de grupo y un número de bloque dentro de un grupo. En las IOW, el grupo de bloques 0 abarca los bloques 1-8192 (basado en 1) en lugar de 0-8191 (basado en 0), como ocurre con tamaños de bloque mayores. El resultado final de esta codificación es que blocknr < s_first_data_block no es una entrada válida para esta función. La variable end_fsb se establece a partir de las claves copiadas del espacio de usuario, lo que significa que, en el ejemplo anterior, su valor es cero. Esto genera un desbordamiento por debajo de la capacidad: blocknr = blocknr - le32_to_cpu(es->s_first_data_block); La división opera entonces sobre -1: offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> EXT4_SB(sb)->s_cluster_bits; De esta manera, se deja un número de grupo imposiblemente grande (2^32-1) en blocknr. ext4_getfsmap_check_keys verificó que keys[0 ---truncado---

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2023-53143. Se considera 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 249320 (EulerOS 2.0 SP13 : kernel (EulerOS-SA-2025-1979)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 4.14.310, 4.19.278, 5.4.237, 5.10.175, 5.15.103, 6.1.20 o 6.2.7 elimina esta vulnerabilidad. Aplicando el parche a70b49dc7eee5dbe3775a650ce598e3557ff5475/f16054ac1774915160ca4e1c73ff7a269465a1b9/c24f838493792b5e78a3596b4ca96375aa0af4c2/1d2366624b4c19a2ba6baf67fe57f4a1b0f67c05/c5d7c31e17224d847a330180ec1b03bf390632b2/eb3a695aa71a514f2e7f5778e05faba3733b70a0/15ebade3266b300da9cd1edce4004fe8fd6a2b88/c993799baf9c5861f8df91beb80e1611b12efcbd 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 (249320) y CERT Bund (WID-SEC-2025-0932). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Afectado

  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • SUSE openSUSE
  • RESF Rocky Linux
  • Dell Avamar
  • Open Source Linux Kernel
  • Dell NetWorker
  • Dell Secure Connect Gateway
  • IBM QRadar SIEM

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.0
VulDB Puntuación meta temporal: 4.9

VulDB Puntuación base: 4.6
VulDB Puntuación temporal: 4.4
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-193 / CWE-189
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: 249320
Nessus Nombre: EulerOS 2.0 SP13 : kernel (EulerOS-SA-2025-1979)

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 4.14.310/4.19.278/5.4.237/5.10.175/5.15.103/6.1.20/6.2.7
Parche: a70b49dc7eee5dbe3775a650ce598e3557ff5475/f16054ac1774915160ca4e1c73ff7a269465a1b9/c24f838493792b5e78a3596b4ca96375aa0af4c2/1d2366624b4c19a2ba6baf67fe57f4a1b0f67c05/c5d7c31e17224d847a330180ec1b03bf390632b2/eb3a695aa71a514f2e7f5778e05faba3733b70a0/15ebade3266b300da9cd1edce4004fe8fd6a2b88/c993799baf9c5861f8df91beb80e1611b12efcbd

Línea de tiempoinformación

2025-05-02 🔍
2025-05-02 +0 días 🔍
2025-05-02 +0 días 🔍
2026-01-31 +274 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2023-53143 (🔍)
GCVE (CVE): GCVE-0-2023-53143
GCVE (VulDB): GCVE-100-307305
CERT Bund: WID-SEC-2025-0932 - Linux Kernel: Mehrere Schwachstellen

Artículoinformación

Fecha de creación: 2025-05-02 20:06
Actualizado: 2026-01-31 19:03
Cambios: 2025-05-02 20:06 (58), 2025-08-02 10:05 (7), 2025-08-15 07:43 (2), 2025-11-10 21:59 (13), 2026-01-31 19:03 (1)
Completo: 🔍
Cache ID: 216::103

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discusión

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

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Might our Artificial Intelligence support you?

Check our Alexa App!