Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en kernel de Linux (CVE-2024-47730)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: hisilicon/qm - inyectar error antes de detener la cola El master ooo no se puede cerrar por completo cuando el núcleo del acelerador informa un error de memoria. Por lo tanto, el controlador debe inyectar el error qm para cerrar el master ooo. Actualmente, el error qm se inyecta después de detener la cola, la memoria puede liberarse inmediatamente después de detener la cola, lo que hace que el dispositivo acceda a la memoria liberada. Por lo tanto, se inyecta un error para cerrar el master ooo antes de detener la cola para garantizar que el dispositivo no acceda a la memoria liberada.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47742)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Block path traversal La mayoría de los nombres de firmware son cadenas codificadas o se construyen a partir de cadenas de formato bastante restringidas donde las partes dinámicas son solo algunos números hexadecimales o algo así. Sin embargo, hay un par de rutas de código en el kernel donde los nombres de archivo de firmware contienen componentes de cadena que se pasan desde un dispositivo o un espacio de usuario semiprivilegiado; los que pude encontrar (sin contar las interfaces que requieren privilegios de root) son: - lpfc_sli4_request_firmware_update() parece construir el nombre de archivo de firmware a partir de "ModelName", una cadena que se analizó previamente a partir de algún descriptor ("Vital Product Data") en lpfc_fill_vpd() - nfp_net_fw_find() parece construir un nombre de archivo de firmware a partir de un nombre de modelo que proviene de nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), que creo que analiza algún descriptor que se leyó desde el dispositivo. (Pero este caso probablemente no sea explotable porque la cadena de formato se parece a "netronome/nic_%s", y no debería haber ninguna *carpeta* que comience con "netronome/nic_". El caso anterior era diferente porque allí, el "%s" está *al comienzo* de la cadena de formato). - module_flash_fw_schedule() es accesible desde el comando netlink ETHTOOL_MSG_MODULE_FW_FLASH_ACT, que está marcado como GENL_UNS_ADMIN_PERM (lo que significa que CAP_NET_ADMIN dentro de un espacio de nombres de usuario es suficiente para pasar la verificación de privilegios), y toma un nombre de firmware provisto por el espacio de usuario. (Pero creo que para llegar a este caso, necesita tener CAP_NET_ADMIN sobre un espacio de nombres de red en el que se asigna un tipo especial de dispositivo Ethernet, por lo que creo que esta no es una ruta de ataque viable en la práctica). Arréglelo rechazando cualquier nombre de firmware que contenga componentes de ruta ".." Por si sirve de algo, he buscado y no he encontrado ningún controlador de dispositivo USB que utilice el cargador de firmware de forma peligrosa.
  • Vulnerabilidad en kernel de Linux (CVE-2024-47745)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: llamar al gancho LSM security_mmap_file() en remap_file_pages() El controlador de llamadas al sistema remap_file_pages llama a do_mmap() directamente, que no contiene la comprobación de seguridad LSM. Y si el proceso ha llamado a personality(READ_IMPLIES_EXEC) antes y se llama a remap_file_pages() para páginas RW, esto realmente dará como resultado la reasignación de las páginas a RWX, omitiendo una política W^X aplicada por SELinux. Por lo tanto, deberíamos comprobar prot mediante el gancho LSM security_mmap_file en el controlador de llamadas al sistema remap_file_pages antes de que se llame a do_mmap(). De lo contrario, potencialmente permite que un atacante omita una política W^X aplicada por SELinux. La omisión es similar a CVE-2016-10044, que omite lo mismo a través de AIO y se puede encontrar en [1]. La PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // muestra que la página RWX existe incluso si se aplica la política W^X int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (eliminado) [MP: ajustes en la línea de asunto]
  • Vulnerabilidad en kernel de Linux (CVE-2024-49882)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corregir el doble brelse() del búfer de la ruta de las extensiones En ext4_ext_try_to_merge_up(), establezca path[1].p_bh en NULL después de que se haya liberado, de lo contrario, puede liberarse dos veces. Un ejemplo de lo que desencadena esto es el siguiente: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. hacer split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // devuelve -ENOMEM |// obtiene el error e intenta poner a cero |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> no establecido en NULL aquí |// puesta a cero exitosa // 2. actualizar ruta ext4_find_extent // 3. hacer split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh sigue siendo el valor anterior ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse un buffer dos veces Finalmente obtuve la siguiente ADVERTENCIA al eliminar el buffer de lru: =============================================== VFS: brelse: Intentando liberar búfer libre ADVERTENCIA: CPU: 2 PID: 72 en fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 No contaminado 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Seguimiento de llamadas: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================
  • Vulnerabilidad en kernel de Linux (CVE-2024-49883)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar use-after-free en ext4_ext_insert_extent() Como mencionó Ojaswin en Link, en ext4_ext_insert_extent(), si la ruta se reasigna en ext4_ext_create_new_leaf(), usaremos la ruta obsoleta y causaremos UAF. A continuación, se muestra un seguimiento de muestra con valores ficticios: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* aquí la ruta sigue siendo 2000, UAF! */ eh = path[depth].p_hdr ===================================================================== ERROR: KASAN: slab-use-after-free en ext4_ext_insert_extent+0x26d4/0x3330 Lectura de tamaño 8 en la dirección ffff8881027bf7d0 por la tarea kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 No contaminado 6.11.0-rc2-dirty #866 Seguimiento de llamadas: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Asignado por la tarea 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Liberado por la tarea 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...]================================================================== Así que use *ppath para actualizar el path para evitar el problema de arriba
  • Vulnerabilidad en kernel de Linux (CVE-2024-49884)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de slab-use-after-free en ext4_split_extent_at() Nos topamos con el siguiente use after free: ====================================================================== ERROR: KASAN: slab-use-after-free en ext4_split_extent_at+0xba8/0xcc0 Lectura de tamaño 2 en la dirección ffff88810548ed08 por la tarea kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 No contaminado 6.9.0-dirty #724 Seguimiento de llamadas: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Asignado por la tarea 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Liberado por la tarea 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================== El flujo de activación del problema es el siguiente: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // devuelve -ENOMEM o -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. Si err es -ENOMEM: ext4_ext_dirty(path + path->p_depth) // ¡¡¡path use after free!!! b. Si err es -EIO y tenemos EXT_DEBUG definido: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // ¡¡¡La ruta también es use after free!!! Por lo tanto, cuando intente poner a cero o corregir la longitud de la extensión, llame a ext4_find_extent() para actualizar la ruta. Además, usamos *ppath directamente como una entrada de ext4_ext_show_leaf() para evitar un posible use after free cuando se define EXT_DEBUG y para evitar actualizaciones de ruta innecesarias.
  • Vulnerabilidad en kernel de Linux (CVE-2024-50302)
    Severidad: MEDIA
    Fecha de publicación: 19/11/2024
    Fecha de última actualización: 12/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: núcleo: inicializar en cero el búfer de informes Dado que el búfer de informes es utilizado por todo tipo de controladores de diversas formas, vamos a inicializarlo en cero durante la asignación para asegurarnos de que nunca pueda usarse para filtrar memoria del kernel a través de un informe especialmente manipulado.
  • Vulnerabilidad en Fortinet (CVE-2026-24858)
    Severidad: CRÍTICA
    Fecha de publicación: 27/01/2026
    Fecha de última actualización: 12/05/2026
    Una vulnerabilidad de omisión de autenticación usando una ruta o canal alternativo [CWE-288] en Fortinet FortiAnalyzer 7.6.0 hasta 7.6.5, FortiAnalyzer 7.4.0 hasta 7.4.9, FortiAnalyzer 7.2.0 hasta 7.2.11, FortiAnalyzer 7.0.0 hasta 7.0.15, FortiManager 7.6.0 hasta 7.6.5, FortiManager 7.4.0 hasta 7.4.9, FortiManager 7.2.0 hasta 7.2.11, FortiManager 7.0.0 hasta 7.0.15, FortiOS 7.6.0 hasta 7.6.5, FortiOS 7.4.0 hasta 7.4.10, FortiOS 7.2.0 hasta 7.2.12, FortiOS 7.0.0 hasta 7.0.18, FortiProxy 7.6.0 hasta 7.6.4, FortiProxy 7.4.0 hasta 7.4.12, FortiProxy 7.2.0 hasta 7.2.15, FortiProxy 7.0.0 hasta 7.0.22, FortiWeb 8.0.0 hasta 8.0.3, FortiWeb 7.6.0 hasta 7.6.6, FortiWeb 7.4.0 hasta 7.4.11 puede permitir a un atacante con una cuenta de FortiCloud y un dispositivo registrado iniciar sesión en otros dispositivos registrados en otras cuentas, si la autenticación SSO de FortiCloud está habilitada en esos dispositivos.