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 Linux (CVE-2026-23076)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ALSA: ctxfi: Corrección de posible acceso OOB en el manejo del mezclador de audio En el código de manejo del mezclador de audio del controlador ctxfi, el campo 'conf' se utiliza como una especie de índice de bucle, y se hace referencia a él en las retrollamadas de índice (amixer_index() y sum_index()). Como fue detectado recientemente por fuzzers, el código actual causa acceso OOB en esas funciones. | UBSAN: índice de array fuera de límites en /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | el índice 8 está fuera de rango para el tipo 'unsigned char [8]' Después del análisis, se encontró que la causa era la falta de la inicialización (o reinicialización) adecuada del campo 'conj'. Este parche aborda esos accesos OOB añadiendo las inicializaciones adecuadas de los índices de bucle.
Vulnerabilidad en Linux (CVE-2026-23077)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/vma: corrige UAF de anon_vma en mremap() con fusión de VMA faulted y unfaulted Serie de parches "mm/vma: corrige UAF de anon_vma en mremap() con fusión de VMA faulted y unfaulted", v2. El commit 879bca0a2c4f ('mm/vma: corrige fusiones de VMA anónimas incorrectamente denegadas') introdujo la capacidad de fusionar escenarios de fusión de VMA previamente no disponibles. Sin embargo, está manejando las fusiones incorrectamente cuando se trata de mremap() de un VMA faulted adyacente a un VMA unfaulted. Los problemas surgen en tres casos: 1. VMA anterior unfaulted:copiado -----| v .............| | unfaulted |(VMA faulted)| .............| anterior 2. Siguiente VMA unfaulted:copiado -----| v |(VMA faulted)| unfaulted | siguiente 3. Ambos VMA adyacentes unfaulted:copiado -----| v ............. | unfaulted |(VMA faulted)| unfaulted | ............. anterior siguiente Esta serie corrige cada uno de estos casos e introduce auto-pruebas para afirmar que los problemas están corregidos. También pruebo un caso adicional que ya estaba manejado, para afirmar que mis cambios continúan manejándolo correctamente: 4. anterior unfaulted, siguiente faulted:copiado -----| v ............. | unfaulted |(VMA faulted)| faulted | ............. anterior siguiente Este error fue descubierto a través de un informe de syzbot, enlazado en el primer parche de la serie, confirmé que esta serie corrige el error. También descubrí que no estamos verificando que el VMA faulted no fue bifurcado al fusionar un VMA copiado en los casos 1-3 anteriores, un problema que esta serie también aborda. También agregué auto-pruebas para afirmar que esto está resuelto (y confirmé que las pruebas fallaron antes de esto). También limpié vma_expand() como parte de este trabajo, renombré vma_had_uncowed_parents() a vma_is_fork_child() ya que el nombre anterior era indebidamente confuso, y simplifiqué los comentarios alrededor de esta función. Este parche (de 4): El commit 879bca0a2c4f ('mm/vma: corrige fusiones de VMA anónimas incorrectamente denegadas') introdujo la capacidad de fusionar escenarios de fusión de VMA previamente no disponibles. La pieza clave de lógica introducida fue la capacidad de fusionar un VMA faulted inmediatamente adyacente a un VMA unfaulted, lo cual se basa en dup_anon_vma() para manejar correctamente el estado de anon_vma. En el caso de la fusión de un VMA existente (es decir, cambiando propiedades de un VMA y luego fusionando si esas propiedades son compartidas por VMA adyacentes), dup_anon_vma() se invoca correctamente. Sin embargo, en el caso de la fusión de un nuevo VMA, se pasó por alto un caso particular peculiar de mremap(). El problema es que vma_expand() solo realiza dup_anon_vma() si el objetivo (el VMA que finalmente se convertirá en el VMA fusionado): no es el siguiente VMA, es decir, el que aparece después del rango en el que se establecerá el nuevo VMA. Una idea clave aquí es que en todos los demás casos, aparte de mremap(), una nueva fusión de VMA o bien expande un VMA existente, lo que significa que el VMA objetivo será ese VMA, o anon_vma sería NULL. Específicamente: * __mmap_region() - no hay anon_vma en su lugar, mapeo inicial. * do_brk_flags() - expandiendo un VMA existente. * vma_merge_extend() - expandiendo un VMA existente. * relocate_vma_down() - no hay anon_vma en su lugar, mapeo inicial. Además, nos encontramos en la situación única de necesitar duplicar el estado de anon_vma de un VMA que no es ni el VMA anterior ni el siguiente con el que se está fusionando. dup_anon_vma() se ocupa exclusivamente del caso objetivo=unfaulted, fuente=faulted. Esto deja cuatro posibilidades, en cada caso donde el VMA copiado es faulted: 1. VMA anterior unfaulted:copiado -----| ---truncado---
Vulnerabilidad en Linux (CVE-2026-23078)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ALSA: scarlett2: Corrección de desbordamiento de búfer en la recuperación de configuración La función scarlett2_usb_get_config() tiene un error lógico en el código de conversión de endianness que puede causar desbordamientos de búfer cuando count > 1. El código comprueba 'if (size == 2)' donde 'size' es el tamaño total del búfer en bytes, luego itera 'count' veces tratando cada elemento como u16 (2 bytes). Esto hace que el bucle acceda a 'count * 2' bytes cuando el búfer solo tiene 'size' bytes asignados. Solución comprobando el tamaño del elemento (config_item->size) en lugar del tamaño total del búfer. Esto asegura que la conversión de endianness coincida con el tipo de elemento real.
Vulnerabilidad en Linux (CVE-2026-23079)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: gpio: cdev: Corregir fugas de recursos ante errores en lineinfo_changed_notify() En las rutas de manejo de errores, lineinfo_changed_notify() no libera los recursos asignados, lo que provoca fugas. Corregirlo.
Vulnerabilidad en Linux (CVE-2026-23080)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: can: mcba_usb: mcba_usb_read_bulk_callback(): corrige la fuga de memoria de URB Corrige una fuga de memoria similar a la del commit 7352e1d5932a ('can: gs_usb: gs_usb_receive_bulk_callback(): corrige la fuga de memoria de URB'). En mcba_usb_probe() -> mcba_usb_start(), los URB para transferencias USB de entrada se asignan, se añaden al ancla priv->rx_submitted y se envían. En la función de callback de completado mcba_usb_read_bulk_callback(), los URB se procesan y se reenvían. En mcba_usb_close() -> mcba_urb_unlink(), los URB se liberan llamando a usb_kill_anchored_urbs(&priv->rx_submitted). Sin embargo, esto no tiene en cuenta que el framework USB desancla el URB antes de que se llame a la función de completado. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no se libera en usb_kill_anchored_urbs(). Corrige la fuga de memoria anclando el URB en mcba_usb_read_bulk_callback() al ancla priv->rx_submitted.
Vulnerabilidad en Linux (CVE-2026-23081)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: phy: intel-xway: solucionar fuga de contador de referencias de nodo OF Una revisión automatizada detectó una fuga en el contador de referencias de un nodo OF al verificar si el nodo hijo 'leds' existe. Llamar a of_put_node() para mantener correctamente el contador de referencias.
Vulnerabilidad en Linux (CVE-2026-23082)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: can: gs_usb: gs_usb_receive_bulk_callback(): desanclar URL en error de usb_submit_urb() En el commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB"), el URB fue re-anclado antes de usb_submit_urb() en gs_usb_receive_bulk_callback() para prevenir una fuga de este URB durante la limpieza. Sin embargo, este parche no tuvo en cuenta que usb_submit_urb() podría fallar. El URB permanece anclado y usb_kill_anchored_urbs(&parent->rx_submitted) en gs_can_close() entra en un bucle infinito ya que la lista de anclajes nunca queda vacía. Para corregir el error, desanclar el URB cuando ocurre un error de usb_submit_urb(), también imprimir un mensaje de información.
Vulnerabilidad en Linux (CVE-2026-23083)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: fou: No permitir 0 para FOU_ATTR_IPPROTO. fou_udp_recv() tiene el mismo problema mencionado en el parche anterior. Si FOU_ATTR_IPPROTO se establece en 0, skb no es liberado por fou_udp_recv() ni 'reenviado' en ip_protocol_deliver_rcu(). Prohibamos 0 para FOU_ATTR_IPPROTO.
Vulnerabilidad en Linux (CVE-2026-23095)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: gue: Corrige la fuga de memoria de skb con el protocolo IP interno 0. syzbot informó de una fuga de memoria de skb a continuación. [0] La reproducción generó un paquete GUE con su protocolo interno 0. gue_udp_recv() devuelve -guehdr->proto_ctype para 'resubmit' en ip_protocol_deliver_rcu(), pero esto solo funciona con números de protocolo distintos de cero. Descartemos tales paquetes. Tenga en cuenta que 0 es un número válido (Opción Salto a Salto de IPv6). Creo que no es práctico encapsular HOPOPT en GUE, así que una vez que alguien empiece a quejarse, podríamos pasar un puntero de bandera de reenvío para distinguir dos ceros de la capa superior: * sin error * reenviar HOPOPT [0] BUG: fuga de memoria objeto sin referencia 0xffff888109695a00 (tamaño 240): comm 'syz.0.17', pid 6088, jiffies 4294943096 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. rastreo (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Vulnerabilidad en Linux (CVE-2026-23096)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: uacce: corrección del manejo de cdev en la ruta de limpieza Cuando cdev_device_add falla, libera internamente la memoria de cdev, y si cdev_device_del se ejecuta entonces, causará un error de bloqueo. Para solucionarlo, verificamos el valor de retorno de cdev_device_add() y borramos uacce->cdev para evitar llamar a cdev_device_del en uacce_remove.
Vulnerabilidad en Linux (CVE-2026-23097)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: migrate: orden correcto de bloqueo para folios de archivo hugetlb Syzbot ha encontrado un interbloqueo (analizado por Lance Yang): 1) Tarea (5749): Mantiene folio_lock, luego intenta adquirir i_mmap_rwsem (bloqueo de lectura). 2) Tarea (5754): Mantiene i_mmap_rwsem (bloqueo de escritura), luego intenta adquirir folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- ¡Toma folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- ¡Espera por i_mmap_rwsem (bloqueo de lectura)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- ¡Toma i_mmap_rwsem (bloqueo de escritura)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- ¡Espera por folio_lock! La ruta de migración es la que toma los bloqueos en el orden incorrecto según la documentación en la parte superior de mm/rmap.c. Así que expandir el alcance del i_mmap_lock existente para cubrir también las llamadas a remove_migration_ptes(). Esto es (en su mayoría) como solía ser después del commit c0d0381ade79. Eso fue eliminado por 336bf30eb765 tanto para páginas hugetlb de archivo como anónimas cuando solo debería haber sido eliminado para páginas hugetlb anónimas.
Vulnerabilidad en Linux (CVE-2026-23109)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: fs/writeback: omitir los mapeos AS_NO_DATA_INTEGRITY en wait_sb_inodes() Por encima del bucle while() en wait_sb_inodes(), documentamos que debemos esperar por todas las páginas en proceso de escritura para la integridad de los datos. En consecuencia, si un mapeo, como fuse, tradicionalmente no tiene semántica de integridad de datos, no hay necesidad de esperar en absoluto; podemos simplemente omitir estos inodos. Esto restaura fuse a su comportamiento anterior donde las sincronizaciones son no-ops. Esto corrige una regresión de usuario donde si un sistema está ejecutando un servidor fuse defectuoso que no responde a las solicitudes de escritura emitidas, esto hace que wait_sb_inodes() espere indefinidamente.
Vulnerabilidad en Linux (CVE-2026-23110)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Despertar al manejador de errores cuando las finalizaciones finales compiten entre sí El ordenamiento frágil entre marcar comandos como completados o fallidos, de modo que el manejador de errores solo se despierte cuando el último comando en ejecución se complete o agote el tiempo de espera, tiene condiciones de carrera. Estas condiciones de carrera pueden hacer que la capa SCSI no despierte al manejador de errores, dejando la E/S a través del host SCSI atascada ya que el estado de error no puede avanzar. Primero, hay un problema de ordenamiento de memoria dentro de scsi_dec_host_busy(). La escritura que borra SCMD_STATE_INFLIGHT puede reordenarse con lecturas que cuentan en scsi_host_busy(). Si bien la CPU local verá su propia escritura, la reordenación puede permitir que otras CPU en scsi_dec_host_busy() o scsi_eh_inc_host_failed() vean un recuento de ocupación elevado, lo que hace que ninguna CPU vea un host ocupado igual al recuento de host_failed. Esta condición de carrera puede evitarse con una barrera de memoria en la ruta de error para forzar que la escritura sea visible antes de contar los comandos de host ocupados. Segundo, hay un problema de ordenamiento general con scsi_eh_inc_host_failed(). Al contar los comandos ocupados antes de incrementar host_failed, puede competir con un comando final en scsi_dec_host_busy(), de modo que scsi_dec_host_busy() no ve host_failed incrementado, pero scsi_eh_inc_host_failed() cuenta los comandos ocupados antes de que SCMD_STATE_INFLIGHT sea borrado por scsi_dec_host_busy(), lo que resulta en que ninguno despierte la tarea del manejador de errores. Esto requiere que la llamada a scsi_host_busy() se mueva después de que host_failed se incremente para cerrar la condición de carrera.
Vulnerabilidad en Apollo Server (CVE-2026-23897)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
Apollo Server es un servidor GraphQL de código abierto, compatible con especificaciones, que es compatible con cualquier cliente GraphQL, incluyendo Apollo Client. En las versiones de 2.0.0 a 3.13.0, de 4.2.0 a antes de 4.13.0, y de 5.0.0 a antes de 5.4.0, la configuración predeterminada de startStandaloneServer de @apollo/server/standalone es vulnerable a ataques de denegación de servicio (DoS) a través de cuerpos de solicitud especialmente diseñados con codificaciones de conjuntos de caracteres exóticas. Este problema no afecta a los usuarios que usan @apollo/server como dependencia para paquetes de integración, como @as-integrations/express5 o @as-integrations/next, solo el uso directo de startStandaloneServer.
Vulnerabilidad en SDK de TypeScript (CVE-2026-25536)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
El SDK de TypeScript de MCP es el SDK oficial de TypeScript para servidores y clientes de Model Context Protocol. Desde la versión 1.10.0 hasta la 1.25.3, se produce una fuga de datos de respuesta entre clientes cuando una única instancia de McpServer/servidor y de transporte es reutilizada a través de múltiples conexiones de cliente, más comúnmente en despliegues de StreamableHTTPServerTransport sin estado. Este problema ha sido parcheado en la versión 1.26.0.
Vulnerabilidad en Godot MCP (CVE-2026-25546)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 18/03/2026
Godot MCP es un servidor de Model Context Protocol (MCP) para interactuar con el motor de juego Godot. Antes de la versión 0.1.1, una vulnerabilidad de inyección de comandos en godot-mcp permite la ejecución remota de código. La función executeOperation pasaba la entrada controlada por el usuario (p. ej., projectPath) directamente a exec(), lo que genera un shell. Un atacante podría inyectar metacaracteres de shell como $(command) o &calc para ejecutar comandos arbitrarios con los privilegios del proceso del servidor MCP. Esto afecta a cualquier herramienta que acepte projectPath, incluyendo create_scene, add_node, load_sprite y otras. Este problema ha sido parcheado en la versión 0.1.1.
Vulnerabilidad en Linux (CVE-2026-23111)
Severidad: ALTA
Fecha de publicación: 13/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: netfilter: nf_tables: corrección de la comprobación genmask invertida en nft_map_catchall_activate() nft_map_catchall_activate() tiene una comprobación de actividad de elemento invertida en comparación con su contraparte no-catchall nft_mapelem_activate() y en comparación con lo que se requiere lógicamente. nft_map_catchall_activate() es llamada desde la ruta de aborto para reactivar elementos de mapa catchall que fueron desactivados durante una transacción fallida. Debería omitir los elementos que ya están activos (no necesitan reactivación) y procesar los elementos que están inactivos (necesitan ser restaurados). En cambio, el código actual hace lo contrario: omite los elementos inactivos y procesa los activos. Compare la devolución de llamada de activación no-catchall, que es correcta: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* omitir activos, procesar inactivos */ Con la versión catchall con errores: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* omitir inactivos, procesar activos */ La consecuencia es que cuando una operación DELSET es abortada, nft_setelem_data_activate() nunca es llamada para el elemento catchall. Para los elementos de veredicto NFT_GOTO, esto significa que nft_data_hold() nunca es llamada para restaurar el contador de referencias chain->use. Cada ciclo de aborto decrementa permanentemente chain->use. Una vez que chain->use llega a cero, DELCHAIN tiene éxito y libera la cadena mientras que los elementos de veredicto catchall aún la referencian, resultando en un uso después de liberación. Esto es explotable para escalada de privilegios local desde un usuario sin privilegios a través de espacios de nombres de usuario + nftables en distribuciones que habilitan CONFIG_USER_NS y CONFIG_NF_TABLES. Corrección eliminando la negación para que la comprobación coincida con nft_mapelem_activate(): omitir elementos activos, procesar inactivos.
Vulnerabilidad en Linux (CVE-2026-23112)
Severidad: MEDIA
Fecha de publicación: 13/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nvmet-tcp: añadir comprobaciones de límites en nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() podría exceder cmd->req.sg cuando una longitud o desplazamiento de PDU excede sg_cnt y luego usar valores sg->length/offset erróneos, lo que lleva a _copy_to_iter() GPF/KASAN. Proteger sg_idx, las entradas restantes y sg->length/offset antes de construir el bvec.
Vulnerabilidad en Linux (CVE-2025-71200)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mmc: sdhci-of-dwcmshc: Evitar la reducción ilegal del reloj en modo HS200/HS400 Al operar en los modos de temporización HS200 o HS400, reducir la frecuencia del reloj por debajo de 52MHz provocará la interrupción del enlace, ya que el controlador Rockchip DWC MSHC requiere mantener un reloj mínimo de 52MHz en estos modos. Añadir una comprobación para evitar la reducción ilegal del reloj a través de debugfs: root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [ 30.090146] mmc0: ejecutando recuperación de CQE mmc0: cqhci: Fallo al detener mmc0: cqhci: TCN espurio para la etiqueta 0 ADVERTENCIA: drivers/mmc/host/cqhci-core.c:797 en cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24 Módulos enlazados: CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H No contaminado 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT Nombre del hardware: Placa Rockchip RK3588 EVB1 V10 (DT) Cola de trabajo: kblockd blk_mq_run_work_fn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhci_irq+0x254/0x818 lr : cqhci_irq+0x254/0x818 ...
Vulnerabilidad en Linux (CVE-2026-23113)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: io_uring/io-wq: verificar IO_WQ_BIT_EXIT dentro del bucle de ejecución de trabajo Actualmente esto se verifica antes de ejecutar el trabajo pendiente. Normalmente esto está bastante bien, ya que los elementos de trabajo o terminan bloqueándose (lo que creará un nuevo trabajador para otros elementos), o se completan bastante rápido. Pero syzbot informa un problema donde io-wq tarda aparentemente una eternidad en salir, y con un poco de depuración, esto resulta ser porque encola un montón de lecturas grandes (2GB - 4096b) con un archivo /dev/msr*. Dado que este tipo de archivo no soporta ->read_iter(), loop_rw_iter() termina manejándolos. Cada lectura devuelve 16MB de datos leídos, lo que toma 20 (!!) segundos. Con un montón de estos pendientes, procesar toda la cadena puede tomar mucho tiempo. Fácilmente más largo que el tiempo de espera de suspensión ininterrumpible de syzbot de 140 segundos. Esto entonces desencadena una queja de la ruta de salida de io-wq: INFO: tarea syz.4.135:6326 bloqueada por más de 143 segundos. No contaminado syzkaller #0 Bloqueado por coredump. 'echo 0 > /proc/sys/kernel/hung_task_timeout_secs' deshabilita este mensaje. task:syz.4.135 estado:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Traza de Llamada: context_switch kernel/sched/core.c:5256 [en línea] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [en línea] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [en línea] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [en línea] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [en línea] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [en línea] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [en línea] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [en línea] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [en línea] syscall_exit_to_user_mode include/linux/entry-common.h:194 [en línea] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 Realmente no hay nada malo aquí, aparte de que procesar estas lecturas tomará MUCHO tiempo. Sin embargo, podemos acelerar la salida verificando el IO_WQ_BIT_EXIT dentro del bucle io_worker_handle_work(), ya que syzbot saldrá del anillo después de encolar todas estas lecturas. Luego, una vez que se procesa el primer elemento, io-wq simplemente cancelará el resto. Eso debería evitar que syzbot se encuentre con esta queja de nuevo.
Vulnerabilidad en Linux (CVE-2026-23114)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/fpsimd: ptrace: Corrige escrituras SVE en sistemas sin SME Cuando SVE es compatible pero SME no lo es, una escritura de ptrace al regset NT_ARM_SVE puede colocar al tracee en un estado inválido donde los datos del registro SVE (no streaming) se almacenan en formato FP_STATE_SVE pero TIF_SVE está en cero. Esto puede resultar en una advertencia posterior de fpsimd_restore_current_state(), por ejemplo: WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748 Cuando esto sucede, fpsimd_restore_current_state() establecerá TIF_SVE, colocando la tarea en el estado correcto. Esto ocurre antes de que cualquier otra verificación de TIF_SVE pueda ocurrir, ya que otras verificaciones de TIF_SVE solo suceden mientras el estado FPSIMD/SVE/SME está activo. Por lo tanto, aparte de la advertencia, no hay ningún problema funcional. Este error fue introducido durante una revisión del manejo de errores en el commit: 9f8bf718f2923 ('arm64/fpsimd: ptrace: Manejar errores con gracia') ... donde la configuración de TIF_SVE se movió a un bloque que solo se ejecuta cuando system_supports_sme() es verdadero. Esto se soluciona eliminando la verificación de system_supports_sme(). Esto asegura que TIF_SVE se establezca para escrituras (con formato SVE) a NT_ARM_SVE, a costa de manipular incondicionalmente el valor svcr guardado del tracee. La manipulación de svcr es inofensiva y de bajo costo, y ya hacemos algo similar en otros lugares (por ejemplo, durante el manejo de señales), por lo que no creo que valga la pena condicionar esto a verificaciones de system_supports_sme(). Aparte de lo anterior, no hay ningún cambio funcional. El argumento 'type' de sve_set_common() solo se establece en ARM64_VEC_SME (en ssve_set()) cuando system_supports_sme(), por lo que el caso ARM64_VEC_SME en la declaración switch sigue siendo inalcanzable cuando system_supports_sme() es falso. Cuando CONFIG_ARM64_SME=n, el único llamador de sve_set_common() es sve_set(), y el compilador puede realizar plegado de constantes para el caso en que 'type' es ARM64_VEC_SVE, eliminando la lógica para otros casos.
Vulnerabilidad en Linux (CVE-2026-23115)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: serial: Corrige la condición de carrera de tty->port no establecido Revertir el commit bfc467db60b7 ('serial: eliminar tty_port_link_device() redundante') porque tty_port_link_device() no es redundante: el tty->port tiene que ser configurado antes de que llamemos a uart_configure_port(), de lo contrario, el espacio de usuario puede abrir la consola sin un TTY vinculado al controlador. Este tty_port_link_device() fue añadido explícitamente para evitar este problema exacto en el commit fb2b90014d78 ('tty: vincular tty y puerto antes de configurarlo como consola'), por lo que el commit ofensivo básicamente revirtió la corrección diciendo que es redundante sin abordar la condición de carrera real presentada allí. Reproducible siempre como advertencia de tty->port en SoC de Qualcomm con la mayoría de los dispositivos deshabilitados, por lo que con un arranque muy rápido, y un dispositivo serie siendo la consola: printk: consola heredada [ttyMSM0] habilitada printk: consola heredada [ttyMSM0] habilitada printk: consola de arranque heredada [qcom_geni0] deshabilitada printk: consola de arranque heredada [qcom_geni0] deshabilitada ------------[ cortar aquí ]------------ tty_init_dev: el controlador ttyMSM no establece tty->port. Esto haría que el kernel se bloquee. ¡Arregle el controlador! ADVERTENCIA: drivers/tty/tty_io.c:1414 en tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1 Módulos vinculados: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6 CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Nombre del hardware: Qualcomm Technologies, Inc. Eliza (DT) ... tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminador 11)) (P) tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminador 3) drivers/tty/tty_io.c:2073 (discriminador 3) drivers/tty/tty_io.c:2120 (discriminador 3)) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:962) vfs_open (fs/open.c:1094) do_open (fs/namei.c:4634) path_openat (fs/namei.c:4793) do_filp_open (fs/namei.c:4820) do_sys_openat2 (fs/open.c:1391 (discriminador 3)) ... Iniciando la resolución de nombres de red... Aparentemente, el flujo con este pequeño espacio de usuario de ramdisk basado en Yocto es: controlador (qcom_geni_serial.c): espacio de usuario: ============================ =========== qcom_geni_serial_probe() uart_add_one_port() serial_core_register_port() serial_core_add_one_port() uart_configure_port() register_console() | | abrir consola | ... | tty_init_dev() | driver->ports[idx] es NULL | tty_port_register_device_attr_serdev() tty_port_link_device() <- establece driver->ports[idx]
Vulnerabilidad en Linux (CVE-2026-23116)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: pmdomain: imx8m-blk-ctrl: Eliminar máscara separada de rst y clk para vpu 8mq Para la plataforma i.MX8MQ, el ADB en el dominio VPUMIX no tiene bits separados de reinicio y habilitación de reloj, sino que se desactiva y reinicia junto con las VPUs. Por lo tanto, no podemos reiniciar G1 o G2 por separado, podría llevar a la congelación del sistema. Eliminar rst_mask y clk_mask de imx8mq_vpu_blk_ctl_domain_data. Dejar que imx8mq_vpu_power_notifier() realice realmente el reinicio de la vpu.
Vulnerabilidad en Linux (CVE-2026-23117)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ice: añadir la llamada faltante a ice_deinit_hw() en la ruta de reinicio de devlink devlink-reload resulta en un error de fallo de ice_init_hw, y luego la eliminación del controlador ice causa una desreferencia de puntero NULL. [ +0.102213] ice 0000:ca:00.0: ice_init_hw falló: -16 ... [ +0.000001] Traza de Llamadas: [ +0.000003] [ +0.000006] ice_unload+0x8f/0x100 [ice] [ +0.000081] ice_remove+0xba/0x300 [ice] El commit 1390b8b3d2be ('ice: eliminar llamada duplicada a ice_deinit_hw() en rutas de error') eliminó ice_deinit_hw() de ice_deinit_dev(). Como resultado, ice_devlink_reinit_down() ya no llama a ice_deinit_hw(), pero ice_devlink_reinit_up() todavía llama a ice_init_hw(). Dado que las colas de control no están desinicializadas, ice_init_hw() falla con -EBUSY. Añadir ice_deinit_hw() a ice_devlink_reinit_down() para corresponder con ice_init_hw() en ice_devlink_reinit_up().
Vulnerabilidad en Linux (CVE-2026-23118)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: rxrpc: Corregir la advertencia de condición de carrera de datos y el potencial desgarro de carga/almacenamiento Corregir lo siguiente: BUG: KCSAN: condición de carrera de datos en rxrpc_peer_keepalive_worker / rxrpc_send_data_packet que está informando un problema con las lecturas y escrituras a ->last_tx_at en: conn->peer->last_tx_at = ktime_get_seconds(); y: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME; Los accesos sin bloqueo a estos dos valores no son realmente un problema, ya que la lectura solo necesita un tiempo aproximado de la última transmisión con el propósito de decidir si la transmisión de un paquete keepalive está justificada o no. Además, como ->last_tx_at es un valor de 64 bits, puede ocurrir desgarro en una arquitectura de 32 bits. Corregir ambos cambiando a un unsigned int para ->last_tx_at y almacenando solo el LSW del time64_t. Luego puede ser reconstruido cuando sea necesario, siempre que no hayan transcurrido más de 68 años desde la última transmisión.
Vulnerabilidad en Linux (CVE-2026-23119)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bonding: proporcionar un puntero de red a __skb_flow_dissect() Después de 3cbf4ffba5ee ('net: integrar el espacio de nombres de red en __skb_flow_dissect') tenemos que proporcionar un puntero de red a __skb_flow_dissect(), ya sea a través de skb->dev, skb->sk, o un puntero proporcionado por el usuario. En el siguiente caso, syzbot pudo 'cocinar' un skb básico. ADVERTENCIA: net/core/flow_dissector.c:1131 en __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Traza de Llamadas: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [en línea] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [en línea] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [en línea] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [en línea] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [en línea] __se_sys_bpf kernel/bpf/syscall.c:6272 [en línea] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
Vulnerabilidad en Linux (CVE-2026-23120)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: l2tp: evitar una carrera de datos en l2tp_tunnel_del_work() Deberíamos leer sk->sk_socket solo cuando se trata de sockets del kernel. syzbot informó la siguiente carrera de datos: BUG: KCSAN: carrera de datos en l2tp_tunnel_del_work / sk_common_release escritura en 0xffff88811c182b20 de 8 bytes por la tarea 5365 en la cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f lectura en 0xffff88811c182b20 de 8 bytes por la tarea 827 en la cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 valor cambiado: 0xffff88811b818000 -> 0x0000000000000000
Vulnerabilidad en Linux (CVE-2026-23121)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mISDN: anotar condición de carrera de datos alrededor de dev->work dev->work puede ser releído sin bloqueo en mISDN_read() y mISDN_poll(). Añadir anotaciones READ_ONCE()/WRITE_ONCE(). ERROR: KCSAN: condición de carrera de datos en mISDN_ioctl / mISDN_read escritura en 0xffff88812d848280 de 4 bytes por la tarea 10864 en la CPU 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f lectura en 0xffff88812d848280 de 4 bytes por la tarea 10857 en la CPU 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f valor cambiado: 0x00000000 -> 0x00000001
Vulnerabilidad en Linux (CVE-2026-23122)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: igc: Reducir el búfer de paquetes TX TSN de 7KB a 5KB por cola Los 7 KB anteriores por cola causaban bloqueos de la unidad TX bajo una carga pesada de marca de tiempo. La reducción a 5 KB evita estos bloqueos y coincide con la recomendación TSN en la Sección 7.5.4 del Manual de Usuario de SW I225/I226. Los 8 KB 'liberados' por este cambio actualmente no se utilizan. Esta reducción no se espera que impacte el rendimiento, ya que el i226 está limitado por PCIe para paquetes TSN pequeños en lugar de estar limitado por el búfer TX.
Vulnerabilidad en Linux (CVE-2026-23123)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad se ha resuelto: interconnect: debugfs: inicializar src_node y dst_node a cadenas vacías La API debugfs_create_str() asume que el puntero de cadena es NULL o apunta a memoria kmalloc() válida. Dejar el puntero sin inicializar puede causar problemas. Inicializar src_node y dst_node a cadenas vacías antes de crear las entradas debugfs para garantizar que las lecturas y escrituras sean seguras.
Vulnerabilidad en Linux (CVE-2026-23124)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ipv6: anotar condición de carrera de datos en ndisc_router_discovery() syzbot encontró que ndisc_router_discovery() podía leer y escribir in6_dev->ra_mtu sin mantener un bloqueo [1] Esto parece estar bien, IFLA_INET6_RA_MTU es de mejor esfuerzo. Añadir READ_ONCE()/WRITE_ONCE() para documentar la condición de carrera. Tenga en cuenta que también podríamos rechazar valores MTU ilegales (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) en un parche futuro. [1] ERROR: KCSAN: condición de carrera de datos en ndisc_router_discovery / ndisc_router_discovery lectura a 0xffff888119809c20 de 4 bytes por la tarea 25817 en la cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... escritura a 0xffff888119809c20 de 4 bytes por la tarea 25816 en la cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... valor cambiado: 0x00000000 -> 0xe5400659
Vulnerabilidad en Linux (CVE-2026-23125)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: sctp: mover SCTP_CMD_ASSOC_SHKEY justo después de SCTP_CMD_PEER_INIT Se informó de una desreferencia de puntero nulo (null-ptr-deref) en la ruta de transmisión SCTP cuando falla la inicialización de la clave SCTP-AUTH: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 El problema se activa cuando sctp_auth_asoc_init_active_key() falla en sctp_sf_do_5_1C_ack() mientras se procesa un INIT_ACK. En este caso, la secuencia de comandos es actualmente: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO Si SCTP_CMD_ASSOC_SHKEY falla, asoc->shkey permanece NULL, mientras que asoc->peer.auth_capable y asoc->peer.peer_chunks ya han sido establecidos por SCTP_CMD_PEER_INIT. Esto permite que un fragmento DATA con auth = 1 y shkey = NULL sea encolado por sctp_datamsg_from_user(). Dado que la interpretación de comandos se detiene en caso de fallo, no debería haberse enviado ningún COOKIE_ECHO a través de SCTP_CMD_GEN_COOKIE_ECHO. Sin embargo, el temporizador T1_COOKIE ya se ha iniciado, y puede encolar un COOKIE_ECHO en la cola de salida (outqueue) más tarde. Como resultado, el fragmento DATA puede transmitirse junto con el COOKIE_ECHO en sctp_outq_flush_data(), lo que lleva al problema observado. De forma similar a otros lugares donde llama a sctp_auth_asoc_init_active_key() justo después de sctp_process_init(), este parche mueve el SCTP_CMD_ASSOC_SHKEY inmediatamente después de SCTP_CMD_PEER_INIT, antes de detener T1_INIT e iniciar T1_COOKIE. Esto asegura que si la generación de clave compartida falla, los datos autenticados (authenticated DATA) no puedan ser enviados. También permite que el temporizador T1_INIT retransmita INIT, dando al cliente otra oportunidad de procesar INIT_ACK y reintentar la configuración de la clave.
Vulnerabilidad en Linux (CVE-2026-23126)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: netdevsim: soluciona un problema de condición de carrera relacionado con la operación en la lista bpf_bound_progs El controlador netdevsim carece de un mecanismo de protección para las operaciones en la lista bpf_bound_progs. Cuando nsim_bpf_create_prog() realiza list_add_tail, es posible que nsim_bpf_destroy_prog() realice simultáneamente list_del. Operaciones concurrentes en la lista pueden llevar a la corrupción de la lista y desencadenar un fallo del kernel de la siguiente manera: [ 417.290971] kernel BUG at lib/list_debug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpf_prog_free_deferred [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim] [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80 [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0 [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0 [ 417.291178] process_one_work+0x18a/0x3a0 [ 417.291188] worker_thread+0x27b/0x3a0 [ 417.291197] ? __pfx_worker_thread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? __pfx_kthread+0x10/0x10 [ 417.291221] ret_from_fork+0x31/0x50 [ 417.291230] ? __pfx_kthread+0x10/0x10 [ 417.291236] ret_from_fork_asm+0x1a/0x30 [ 417.291246] Se añade un bloqueo mutex para evitar operaciones simultáneas de adición y eliminación en la lista.
Vulnerabilidad en Linux (CVE-2026-23127)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: perf: Corrección de la advertencia de refcount en el incremento de event->mmap_count Al llamar a refcount_inc(&event->mmap_count) dentro de perf_mmap_rb(), se activa la siguiente advertencia: refcount_t: adición en 0; uso después de liberación. ADVERTENCIA: lib/refcount.c:25 PoC: struct perf_event_attr attr = {0}; int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); int victim = syscall(__NR_perf_event_open, &attr, 0, -1, fd, PERF_FLAG_FD_OUTPUT); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0); Esto ocurre al crear un evento miembro de grupo con la bandera PERF_FLAG_FD_OUTPUT. El líder del grupo debe ser mapeado con mmap y luego mapear el evento con mmap activa la advertencia. Dado que el evento ha copiado el output_event en perf_event_set_output(), event->rb está establecido. Como resultado, perf_mmap_rb() llama a refcount_inc(&event->mmap_count) cuando event->mmap_count = 0. No permitir el caso cuando event->mmap_count = 0. Esto también evita que dos eventos actualicen la misma user_page.
Vulnerabilidad en Linux (CVE-2026-23128)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: arm64: Establecer __nocfi en swsusp_arch_resume() Se informa de un DABT[1] en un sistema basado en Android al reanudar desde la hibernación. Esto ocurre porque swsusp_arch_suspend_exit() está marcado con SYM_CODE_*() y no tiene un hash CFI, pero swsusp_arch_resume() intentará verificar el hash CFI al llamar a una copia de swsusp_arch_suspend_exit(). Dado que existe un requisito de que el punto de entrada a swsusp_arch_suspend_exit() es el primer byte de la sección .hibernate_exit.text, no podemos solucionar esto marcando swsusp_arch_suspend_exit() con SYM_FUNC_*(). La solución más sencilla por ahora es deshabilitar la verificación CFI en swsusp_arch_resume(). Marcar swsusp_arch_resume() como __nocfi para deshabilitar la verificación CFI. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]
Vulnerabilidad en Linux (CVE-2026-23129)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: dpll: Prevenir registros duplicados Modificar las funciones auxiliares de registro internas dpll_xa_ref_{dpll,pin}_add() para rechazar intentos de registro duplicados. Anteriormente, si un llamador intentaba registrar el mismo pin múltiples veces (con las mismas ops, priv y cookie) en el mismo dispositivo, el núcleo incrementaba silenciosamente el contador de referencias y devolvía éxito. Este comportamiento es incorrecto porque si el llamador realiza estos registros duplicados, entonces para el primero se asigna dpll_pin_registration y para los demás se incrementa el dpll_pin_ref.refcount asociado. Durante la primera anulación de registro se libera el dpll_pin_registration asociado y para los demás se dispara una advertencia. Esto se soluciona actualizando la lógica para devolver -EEXIST si se encuentra un registro coincidente, para aplicar una política estricta de 'registrar una vez'.
Vulnerabilidad en Linux (CVE-2026-23153)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: firewire: core: corrige condición de carrera contra la lista de transacciones La lista de transacciones se enumera sin adquirir el bloqueo de la tarjeta al procesar el evento de respuesta AR. Esto causa un error de condición de carrera al procesar el evento de finalización de solicitud AT concurrentemente. Este commit corrige el error al poner el inicio del temporizador para la expiración de transacciones divididas dentro del alcance del bloqueo. Se consulta el valor de jiffies en la estructura de la tarjeta antes de adquirir el bloqueo.
Vulnerabilidad en Linux (CVE-2026-23154)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: corrige la segmentación de reenvío de fraglist GRO Este parche mejora el manejo de segmentos GSO al verificar correctamente el flag SKB_GSO_DODGY para paquetes GSO con frag_list, abordando problemas de bajo rendimiento observados cuando una estación accede a servidores IPv4 a través de hotspots con una interfaz upstream solo IPv6. Específicamente, corrige un error en la segmentación GSO al reenviar paquetes GRO que contienen un frag_list. La función skb_segment_list no puede procesar correctamente los skbs GRO que han sido convertidos por XLAT, ya que XLAT solo traduce la cabecera del skb principal. Consecuentemente, los skbs en el frag_list pueden permanecer sin traducir, lo que resulta en inconsistencias de protocolo y un rendimiento reducido. Para abordar esto, el parche establece explícitamente el flag SKB_GSO_DODGY para paquetes GSO en los helpers de traducción de protocolo IPv4/IPv6 de XLAT (bpf_skb_proto_4_to_6 y bpf_skb_proto_6_to_4). Esto marca los paquetes GSO como potencialmente modificados después de la traducción de protocolo. Como resultado, la segmentación GSO evitará usar skb_segment_list y en su lugar recurrirá a skb_segment para paquetes con el flag SKB_GSO_DODGY. Esto asegura que solo los paquetes frag_list seguros y completamente traducidos sean procesados por skb_segment_list, resolviendo inconsistencias de protocolo y mejorando el rendimiento al reenviar paquetes GRO convertidos por XLAT.
Vulnerabilidad en Linux (CVE-2026-23155)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: can: gs_usb: gs_usb_receive_bulk_callback(): corregir mensaje de error Desde el commit 79a6d1bfe114 ('can: gs_usb: gs_usb_receive_bulk_callback(): desanclar URL en error de usb_submit_urb()'), un URB de reenvío fallido imprimirá un mensaje de información. En el caso de una lectura corta donde netdev aún no ha sido asignado, inicializar como NULL para evitar desreferenciar un valor indefinido. También informar el valor de error del reenvío fallido.
Vulnerabilidad en Linux (CVE-2026-23156)
Severidad: ALTA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: efivarfs: corrección de la propagación de errores en efivar_entry_get() efivar_entry_get() siempre devuelve éxito incluso si la función subyacente __efivar_entry_get() falla, enmascarando errores. Esto puede resultar en que memoria de pila no inicializada sea copiada al espacio de usuario en la ruta de efivarfs_file_read(). Se soluciona devolviendo el error desde __efivar_entry_get().
Vulnerabilidad en Linux (CVE-2026-23157)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: btrfs: no requerir estrictamente el umbral de metadatos sucios para la escritura de páginas de metadatos [ERROR] Existe un informe interno de que más de 1000 procesos están esperando en el io_schedule_timeout() de balance_dirty_pages(), causando un cuelgue del sistema y desencadenando un volcado de memoria del kernel. El kernel está basado en el kernel v6.4, pero el problema raíz todavía se aplica a cualquier kernel upstream anterior a la v6.18. [CAUSA] De Jan Kara por su sabiduría sobre el comportamiento de balanceo de páginas sucias primero. Este límite de suciedad del cgroup era lo que realmente estaba desempeñando el papel aquí porque el cgroup tenía solo una pequeña cantidad de memoria y por lo tanto el límite de suciedad para él era de aproximadamente 16MB. La limitación de suciedad es responsable de asegurar que nadie pueda ensuciar (significativamente) más memoria sucia de lo que hay de límite de suciedad. Así, cuando una tarea está ensuciando páginas, entra periódicamente en balance_dirty_pages() y la dejamos dormir allí para ralentizar el ensuciamiento. Cuando el sistema ya está por encima del límite de suciedad (ya sea globalmente o dentro de un cgroup de la tarea en ejecución), no permitiremos que la tarea salga de balance_dirty_pages() hasta que el número de páginas sucias caiga por debajo del límite. Así que en este caso particular, como ya mencioné, había un cgroup con una cantidad de memoria relativamente pequeña y como resultado con un límite de suciedad establecido en 16MB. Una tarea de ese cgroup ha ensuciado páginas por un valor de aproximadamente 28MB en el inodo btree de btrfs y estas eran prácticamente las únicas páginas sucias en ese cgroup. Así que eso significa que la única forma de reducir las páginas sucias de ese cgroup es realizar el writeback de las páginas sucias del inodo btree de btrfs, y solo después de eso esos procesos pueden salir de balance_dirty_pages(). Ahora volviendo a la parte de btrfs, btree_writepages() es responsable de realizar el writeback de las páginas sucias del inodo btree. El problema aquí es que hay un umbral interno de btrfs que si los bytes sucios del inodo btree están por debajo del umbral de 32M, no realizará ningún writeback. Este comportamiento es para agrupar la mayor cantidad posible de metadatos para que no escribamos de vuelta esos bloques de árbol y luego los volvamos a copiar en escritura (re-COW) para otra modificación. Estos 32MiB internos son más altos que el tamaño de página sucia existente (28MiB), lo que significa que no se realizará ningún writeback, causando un interbloqueo entre btrfs y cgroup: - Btrfs no quiere realizar el writeback del inodo btree hasta que haya más páginas sucias - Cgroup/MM no quiere más páginas sucias para el inodo btree de btrfs Así, cualquier proceso que toque ese inodo btree es puesto a dormir hasta que el número de páginas sucias se reduzca. Muchas gracias a Jan Kara por el análisis de la causa raíz. [MEJORA] Desde el commit del kernel b55102826d7d ('btrfs: establecer AS_KERNEL_FILE en el btree_inode'), las páginas del inodo btree de btrfs solo se cargarán al cgroup raíz, el cual debería tener un límite mucho mayor que el umbral de 32MiB de btrfs. Así que no debería afectar a kernels más nuevos. Pero para todos los kernels LTS actuales, todos están afectados por este problema, y realizar un backport de todo el AS_KERNEL_FILE puede no ser una buena idea. Incluso para kernels más nuevos, sigo pensando que es una buena idea eliminar el umbral interno en btree_writepages(), ya que en la mayoría de los casos cgroup/MM tiene una mejor visión del uso de la memoria de todo el sistema que el umbral fijo de btrfs. Para los llamadores internos que usan btrfs_btree_balance_dirty(), ya que esa función ya está realizando una comprobación de umbral interna, ---truncado---
Vulnerabilidad en Linux (CVE-2026-23158)
Severidad: ALTA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: gpio: virtuser: corregir uso después de liberación en la ruta de liberación de configfs La ruta de liberación de configfs de gpio-virtuser usa guard(mutex) para proteger la estructura del dispositivo. Sin embargo, el dispositivo es liberado antes de que se ejecute la limpieza del guard, causando que mutex_unlock() opere sobre memoria liberada. Específicamente, gpio_virtuser_device_config_group_release() destruye el mutex y libera el dispositivo mientras aún está dentro del ámbito de guard(mutex). Cuando la función retorna, la limpieza del guard invoca mutex_unlock(&dev->lock), resultando en un uso después de liberación de slab. Limitar la vida útil del mutex usando un scoped_guard() solo alrededor de la verificación de activación, para que el bloqueo sea liberado antes de que se llamen a mutex_destroy() y kfree().
Vulnerabilidad en Linux (CVE-2026-23159)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: sched: Soluciona el fallo de perf con la nueva función auxiliar is_user_task() Para realizar un seguimiento de pila (stacktrace) del espacio de usuario, la tarea actual debe ser una tarea de usuario que se haya ejecutado en el espacio de usuario. Solía ser posible comprobar si una tarea es una tarea de usuario o no simplemente verificando el campo mm de task_struct. Si no era NULL, era una tarea de usuario y si no, era una tarea del kernel. Pero las cosas han cambiado con el tiempo, y algunas tareas del kernel ahora tienen su propio campo mm. Se propuso la idea de probar PF_KTHREAD en su lugar y se utilizaron dos funciones para encapsular esta verificación en caso de que se volviera más complejo probar si una tarea era una tarea de usuario o no[1]. Pero esto fue rechazado y el código C simplemente verificó PF_KTHREAD directamente. Más tarde se descubrió que no todos los hilos del kernel establecen PF_KTHREAD. Los auxiliares de io-uring, en cambio, establecen PF_USER_WORKER y esto también necesitaba ser añadido. Pero verificar las banderas (flags) todavía no es suficiente. Hay una ventana muy pequeña cuando una tarea sale en la que libera su campo mm y este se vuelve a establecer en NULL. Si perf se activara en este momento, la prueba de las banderas diría que es una tarea del espacio de usuario, pero cuando perf leyera el campo mm, fallaría con una desreferencia de puntero NULL. Ahora hay banderas que se pueden usar para probar si una tarea está saliendo, pero se establecen en áreas que perf aún podría querer perfilar en la tarea del espacio de usuario (para ver dónde salió). La única prueba real es verificar tanto las banderas como el campo mm. En lugar de realizar esta modificación en cada ubicación, cree una nueva función auxiliar is_user_task() que realice todas las pruebas necesarias para saber si es seguro leer la memoria del espacio de usuario o no. [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/
Vulnerabilidad en Linux (CVE-2026-23160)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: octeon_ep: Corrección de fuga de memoria en octep_device_setup() En octep_device_setup(), si octep_ctrl_net_init() falla, la función retorna directamente sin desmapear los recursos mapeados y liberar la memoria de configuración asignada. Esto se corrige saltando a la etiqueta unsupported_dev, la cual realiza la limpieza necesaria. Esto se alinea con la lógica de manejo de errores de otras rutas en esta función. Probado únicamente en compilación. Problema encontrado usando una herramienta prototipo de análisis estático y revisión de código.
Vulnerabilidad en Linux (CVE-2026-23164)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: rocker: corregir fuga de memoria en rocker_world_port_post_fini() En rocker_world_port_pre_init(), rocker_port->wpriv se asigna con kzalloc(wops->port_priv_size, GFP_KERNEL). Sin embargo, en rocker_world_port_post_fini(), la memoria solo se libera cuando la devolución de llamada wops->port_post_fini está establecida: si (!wops->port_post_fini) retornar; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Dado que rocker_ofdpa_ops no implementa la devolución de llamada port_post_fini (es NULL), la memoria wpriv asignada para cada puerto nunca se libera cuando se eliminan los puertos. Esto conduce a una fuga de memoria de sizeof(struct ofdpa_port) bytes por puerto en cada eliminación de dispositivo. Solucione esto llamando siempre a kfree(rocker_port->wpriv) independientemente de si existe la devolución de llamada port_post_fini.
Vulnerabilidad en Linux (CVE-2026-23165)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: sfc: soluciona interbloqueo en la lectura de configuración RSS Desde el commit citado, el núcleo bloquea el rss_lock del net_device al manejar el comando ethtool -x, por lo que la implementación del controlador no debería bloquearlo de nuevo. Eliminar esto último.
Vulnerabilidad en Linux (CVE-2026-23166)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ice: Corrige la desreferencia de puntero NULL en ice_vsi_set_napi_queues Añade comprobaciones de puntero NULL en ice_vsi_set_napi_queues() para evitar fallos durante la reanudación desde la suspensión cuando rings[q_idx]->q_vector es NULL. Adaptador probado: 60:00.0 Controlador Ethernet [0200]: Intel Corporation Ethernet Controller E810-XXV para SFP [8086:159b] (rev 02) Subsistema: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003] Estado de SR-IOV: tanto deshabilitado como habilitado pueden reproducir este problema. versión del kernel: v6.18 Pasos para reproducir: Arrancar y ejecutar la suspensión como systemctl suspend o rtcwake. Registro: <1>[ 231.443607] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000040 <1>[ 231.444052] #PF: acceso de lectura de supervisor en modo kernel <1>[ 231.444484] #PF: código_de_error(0x0000) - página no presente <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Traza de llamada: <4>[ 231.452549] <4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice] <4>[ 231.453482] ice_resume+0xfd/0x220 [ice] <4>[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.454425] pci_pm_resume+0x8c/0x140 <4>[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.455347] dpm_run_callback+0x5f/0x160 <4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170 <4>[ 231.456244] device_resume+0x177/0x270 <4>[ 231.456708] dpm_resume+0x209/0x2f0 <4>[ 231.457151] dpm_resume_end+0x15/0x30 <4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0 <4>[ 231.458054] enter_state+0x10e/0x570 Añade comprobaciones defensivas tanto para el puntero del anillo como para su q_vector antes de desreferenciar, permitiendo que el sistema se reanude con éxito incluso cuando los q_vectors no están mapeados.
Vulnerabilidad en Linux (CVE-2026-23167)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nfc: nci: Solucionar condición de carrera entre rfkill y nci_unregister_device(). syzbot informó del 'splat' a continuación [0] sin una reproducción. Indica que la estructura nci_dev.cmd_wq había sido destruida antes de que se llamara a nci_close_device() a través de rfkill. nci_dev.cmd_wq solo se destruye en nci_unregister_device(), que (creo) fue llamada desde virtual_ncidev_close() cuando syzbot cerró un 'fd' de virtual_ncidev. El problema es que nci_unregister_device() destruye nci_dev.cmd_wq primero y luego llama a nfc_unregister_device(), que elimina el dispositivo de rfkill mediante rfkill_unregister(). Así, el dispositivo sigue siendo visible a través de rfkill incluso después de que nci_dev.cmd_wq sea destruida. Desregistremos el dispositivo de rfkill primero en nci_unregister_device(). Tenga en cuenta que no podemos llamar a nfc_unregister_device() antes de nci_close_device() porque 1) nfc_unregister_device() llama a device_del() que libera toda la memoria asignada por devm_kzalloc() y vinculada a ndev->conn_info_list 2) nci_rx_work() podría intentar encolar nci_conn_info a ndev->conn_info_list lo que podría provocar una fuga de memoria Por lo tanto, nfc_unregister_device() se divide en dos funciones para que podamos eliminar las interfaces de rfkill solo antes de nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) ADVERTENCIA: kernel/locking/lockdep.c:238 en hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 ADVERTENCIA: kernel/locking/lockdep.c:238 en check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 ADVERTENCIA: kernel/locking/lockdep.c:238 en __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Módulos enlazados: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 No contaminado syzkaller #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Código: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Ruta de llamada: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ---truncado---
Vulnerabilidad en Linux (CVE-2026-23168)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: flex_proportions: hacer que fprop_new_period() sea seguro para hardirq Bernd ha reportado un lockdep splat del código de proporciones flexibles que esencialmente se queja de la siguiente condición de carrera: run_timer_softirq - estamos en contexto de softirq call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - ve una secuencia impar por lo que entra en un bucle indefinido Tenga en cuenta que un interbloqueo como este solo es posible si el bdi ha configurado una fracción máxima de rendimiento de escritura, lo cual es muy raro en general pero frecuente, por ejemplo, para bdis FUSE. Para solucionar este problema, tenemos que asegurarnos de que la sección de escritura del contador de secuencia sea irqsafe.
Vulnerabilidad en Linux (CVE-2026-23169)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mptcp: corrección de condición de carrera en mptcp_pm_nl_flush_addrs_doit() syzbot y Eulgyu Kim reportaron fallos en mptcp_pm_nl_get_local_id() y/o mptcp_pm_nl_is_backup() La causa raíz es list_splice_init() en mptcp_pm_nl_flush_addrs_doit() que no está preparada para RCU. list_splice_init_rcu() no puede ser llamada aquí mientras se mantiene el spinlock pernet->lock. Muchas gracias a Eulgyu Kim por proporcionar una reproducción y probar nuestros parches.
Vulnerabilidad en Linux (CVE-2026-23170)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: drm/imx/tve: solución a la fuga de dispositivo de sondeo Asegúrese de liberar la referencia tomada al dispositivo DDC durante el sondeo en caso de fallo del sondeo (p. ej., aplazamiento del sondeo) y al desvincular el controlador.
Vulnerabilidad en Linux (CVE-2026-23171)
Severidad: ALTA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bonding: corrige el uso después de liberación debido a un fallo de enslave después de la actualización del array de esclavos Corrige un uso después de liberación que ocurre debido a un fallo de enslave después de que el nuevo esclavo ha sido añadido al array. Dado que el nuevo esclavo puede ser usado para Tx inmediatamente, podemos usarlo después de que ha sido liberado por la ruta de limpieza de errores de enslave que libera la memoria del esclavo asignada. Se supone que la actualización del array de esclavos debe ser llamada al final cuando no se esperan más fallos de enslave. Muévelo después de la configuración de xdp para evitar cualquier problema. Es muy fácil reproducir el problema con un programa xdp_pass simple: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummy Luego ejecuta en paralelo: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp 'dp=1-1023, flags=syn' El fallo ocurre casi inmediatamente: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? __pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]
Vulnerabilidad en Linux (CVE-2026-23172)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: wwan: t7xx: corrige un potencial desbordamiento de skb->frags en la ruta RX Al recibir datos en la ruta RX de DPMAIF, la función t7xx_dpmaif_set_frag_to_skb() añade fragmentos de página a un skb sin comprobar si el número de fragmentos ha excedido MAX_SKB_FRAGS. Esto podría conducir a un desbordamiento de búfer en el array skb_shinfo(skb)->frags[], corrompiendo memoria adyacente y potencialmente causando fallos del kernel u otro comportamiento indefinido. Este problema fue identificado a través de análisis de código estático comparando con una vulnerabilidad similar corregida en el commit b102f0c522cf del controlador mt76 ('mt76: corrige el desbordamiento del array al recibir demasiados fragmentos para un paquete'). La vulnerabilidad podría ser activada si el firmware del módem envía paquetes con fragmentos excesivos. Si bien bajo condiciones normales del protocolo (MTU 3080 bytes, búfer BAT 3584 bytes), un solo paquete no debería requerir fragmentos adicionales, el kernel no debería confiar ciegamente en el comportamiento del firmware. Firmware malicioso, con errores o comprometido podría potencialmente crear paquetes con más fragmentos de los que el kernel espera. Solucione esto añadiendo una comprobación de límites antes de llamar a skb_add_rx_frag() para asegurar que nr_frags no exceda MAX_SKB_FRAGS. La comprobación debe realizarse antes de desmapear para evitar una fuga de página y un doble desmapeo DMA durante el desmontaje del dispositivo.
Vulnerabilidad en Linux (CVE-2026-23173)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net/mlx5e: TC, eliminar flujos solo para pares existentes Al eliminar flujos de direccionamiento TC, iterar solo sobre pares devcom reales en lugar de asumir que todos los puertos posibles existen. Esto evita tocar pares no existentes y asegura que la limpieza se limite a los dispositivos a los que el controlador está conectado actualmente. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 #PF: acceso de escritura de supervisor en modo kernel #PF: error_code(0x0002) - página no presente PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc No contaminado 6.18.0+ #156 NINGUNO Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Código: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Traza de Llamada: mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0
Vulnerabilidad en Linux (CVE-2025-71236)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Validar sp antes de liberar la memoria asociada Fallo del sistema con la siguiente firma [154563.214890] nvme nvme2: NVME-FC{1}: conexión del controlador completada [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Establecer el umbral de intercambio ZIO en 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: ESTABLECER el umbral de intercambio de actividad ZIO en 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: base de datos RSCN cambiada – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: base de datos RSCN cambiada – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=habilitado (tasa de datos). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=habilitado (tasa de datos). [154565.553079] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000f8 [154565.553080] #PF: acceso de lectura de supervisor en modo kernel [154565.553082] #PF: error_code(0x0000) - página no presente [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: cargado Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Nombre del hardware: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 30/09/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Código: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Traza de llamadas: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Verificar que sp no sea NULL antes de liberar cualquier memoria asociada
Vulnerabilidad en Linux (CVE-2025-71237)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nilfs2: Corrige un posible desbordamiento de bloque que causa un cuelgue del sistema Cuando un usuario ejecuta el comando FITRIM, puede ocurrir un subdesbordamiento al calcular nblocks si end_block es demasiado pequeño. Dado que nblocks es de tipo sector_t, que es u64, un valor negativo de nblocks se convertirá en un entero positivo muy grande. Esto finalmente lleva a que la función de la capa de bloques __blkdev_issue_discard() tarde un tiempo excesivamente largo en procesar la cadena bio, y el bloqueo ns_segctor_sem permanezca retenido durante un largo período. Esto impide que otras tareas adquieran el bloqueo ns_segctor_sem, lo que resulta en el cuelgue reportado por syzbot en [1]. Si el bloque final es demasiado pequeño, típicamente si es menor que el rango de 4KiB, dependiendo del uso del segmento 0, puede ser posible intentar una solicitud de descarte más allá del tamaño del dispositivo, causando el cuelgue. Saliendo con éxito y asignando el tamaño descartado (0 en este caso) a range->len. Aunque los valores de inicio y longitud en el rango de entrada del usuario son demasiado pequeños, se adopta aquí una estrategia conservadora para ignorarlos de forma segura, lo cual es equivalente a una no-op; no realizará ningún recorte y no lanzará un error. [1] tarea:segctord estado:D pila:28968 pid:6093 tgid:6093 ppid:2 flags_de_tarea:0x200040 flags:0x00080000 Traza de Llamada: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corregida parte del mensaje de commit sobre las consecuencias]
Vulnerabilidad en el kernel de Linux (CVE-2026-23220)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: ksmbd: corrige un bucle infinito causado por el reinicio de next_smb2_rcv_hdr_off en las rutas de error El problema ocurre cuando una solicitud firmada falla la verificación de firma smb2. En __process_request(), si check_sign_req() devuelve un error, se llama a set_smb2_rsp_status(work, STATUS_ACCESS_DENIED). set_smb2_rsp_status() establece work->next_smb2_rcv_hdr_off a cero. Al reiniciar next_smb2_rcv_hdr_off a cero, el puntero al siguiente comando en la cadena se pierde. En consecuencia, is_chained_smb2_message() continúa apuntando a la misma cabecera de solicitud en lugar de avanzar. Si el campo NextCommand de la cabecera no es cero, la función devuelve verdadero, lo que hace que __handle_ksmbd_work() procese repetidamente la misma solicitud fallida en un bucle infinito. Esto resulta en el registro del kernel siendo inundado con mensajes de 'firma smb2 incorrecta' y un alto uso de CPU. Este parche corrige el problema cambiando el valor de retorno de SERVER_HANDLER_CONTINUE a SERVER_HANDLER_ABORT. Esto asegura que el bucle de procesamiento termine inmediatamente en lugar de intentar continuar desde un desplazamiento invalidado.
Vulnerabilidad en kernel de Linux (CVE-2026-23221)
Severidad: ALTA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: bus: fsl-mc: corrección de uso después de liberación en driver_override_show() La función driver_override_show() lee la cadena driver_override sin mantener el device_lock. Sin embargo, driver_override_store() utiliza driver_set_override(), que modifica y libera la cadena mientras mantiene el device_lock. Esto puede resultar en un uso después de liberación concurrente si la cadena es liberada por la función store mientras es leída por la función show. Solucionar esto manteniendo el device_lock alrededor de la operación de lectura.
Vulnerabilidad en Linux (CVE-2026-23222)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: crypto: omap - Asignar correctamente las scatterlists OMAP_CRYPTO_FORCE_COPY La asignación existente de scatterlists en omap_crypto_copy_sg_lists() estaba asignando un array de punteros a scatterlist, no objetos scatterlist, lo que resultaba en una asignación 4 veces demasiado pequeña. Usar sizeof(*new_sg) para obtener el tamaño de objeto correcto.
Vulnerabilidad en el kernel de Linux (CVE-2026-23223)
Severidad: ALTA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: xfs: se corrige UAF en xchk_btree_check_block_owner No podemos desreferenciar bs->cur al intentar determinar si bs->cur es un alias de bs->sc->sa.{bno,rmap}_cur después de que este último haya sido liberado. Esto se soluciona muestreando el tipo antes de que pudiera ocurrir cualquier liberación. El orden temporal correcto se rompió cuando eliminamos xfs_btnum_t.
Vulnerabilidad en el kernel de Linux (CVE-2026-23224)
Severidad: ALTA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: erofs: soluciona un problema de UAF para montajes respaldados por archivos con la opción 'directio' [ 9.269940][ T3222] Rastreo de llamadas: [ 9.269948][ T3222] ext4_file_read_iter+0xac/0x108 [ 9.269979][ T3222] vfs_iocb_iter_read+0xac/0x198 [ 9.269993][ T3222] erofs_fileio_rq_submit+0x12c/0x180 [ 9.270008][ T3222] erofs_fileio_submit_bio+0x14/0x24 [ 9.270030][ T3222] z_erofs_runqueue+0x834/0x8ac [ 9.270054][ T3222] z_erofs_read_folio+0x120/0x220 [ 9.270083][ T3222] filemap_read_folio+0x60/0x120 [ 9.270102][ T3222] filemap_fault+0xcac/0x1060 [ 9.270119][ T3222] do_pte_missing+0x2d8/0x1554 [ 9.270131][ T3222] handle_mm_fault+0x5ec/0x70c [ 9.270142][ T3222] do_page_fault+0x178/0x88c [ 9.270167][ T3222] do_translation_fault+0x38/0x54 [ 9.270183][ T3222] do_mem_abort+0x54/0xac [ 9.270208][ T3222] el0_da+0x44/0x7c [ 9.270227][ T3222] el0t_64_sync_handler+0x5c/0xf4 [ 9.270253][ T3222] el0t_64_sync+0x1bc/0x1c0 EROFS puede encontrar el pánico anterior al habilitar el montaje respaldado por archivos con la opción de montaje directio; la causa raíz es que puede sufrir UAF en la siguiente condición de carrera: - z_erofs_read_folio wq s_dio_done_wq - z_erofs_runqueue - erofs_fileio_submit_bio - erofs_fileio_rq_submit - vfs_iocb_iter_read - ext4_file_read_iter - ext4_dio_read_iter - iomap_dio_rw : bio fue enviado y devuelve -EIOCBQUEUED - dio_aio_complete_work - dio_complete - dio->iocb->ki_complete (erofs_fileio_ki_complete()) - kfree(rq) : libera iocb, iocb.ki_filp puede ser UAF en file_accessed(). - file_accessed : accede a un puntero de archivo NULL Introducir un contador de referencias en la estructura erofs_fileio_rq, y lo inicializa a dos; tanto erofs_fileio_ki_complete() como erofs_fileio_rq_submit() disminuirán el contador de referencias, el último en disminuir el contador de referencias a cero liberará rq.
Vulnerabilidad en el kernel de Linux (CVE-2026-23227)
Severidad: ALTA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: drm/exynos: vidi: usar ctx->lock para proteger las variables miembro de la estructura vidi_context relacionadas con la asignación/liberación de memoria El controlador de pantalla virtual de Exynos realiza operaciones de asignación/liberación de memoria sin protección de bloqueo, lo que fácilmente causa un problema de concurrencia. Por ejemplo, el uso después de liberación puede ocurrir en un escenario de carrera como este: ``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ... ``` Para prevenir estas vulnerabilidades, al menos en vidi_context, las variables miembro relacionadas con la asignación/liberación de memoria deberían ser protegidas con ctx->lock.
Vulnerabilidad en el kernel de Linux: (CVE-2026-23228)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: smb: servidor: corregir fuga de active_num_conn en ksmbd_tcp_new_connection() En caso de fallo de kthread_run() en ksmbd_tcp_new_connection(), se libera el transporte a través de free_transport(), lo que no decrementa active_num_conn, fugando este contador. Reemplazar free_transport() con ksmbd_tcp_disconnect().
Vulnerabilidad en el kernel de Linux (CVE-2026-23229)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 18/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: crypto: virtio - Añadir protección con spinlock con notificación de virtqueue Cuando una VM arranca con un dispositivo PCI virtio-crypto y un backend integrado, ejecutar el comando de benchmark de OpenSSL con múltiples procesos, como openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 los procesos de OpenSSL se colgarán y se reporta un error como este: virtio_crypto virtio0: dataq.0:id 3 is not a head! Parece que el virtqueue de datos necesita protección cuando se maneja para la notificación de finalización de virtio. Si se añade la protección con spinlock en virtcrypto_done_task(), el benchmark de OpenSSL con múltiples procesos funciona correctamente.
Vulnerabilidad en OpenSift (CVE-2026-28675)
Severidad: MEDIA
Fecha de publicación: 06/03/2026
Fecha de última actualización: 18/03/2026
OpenSift es una herramienta de estudio de IA que tamiza grandes conjuntos de datos utilizando búsqueda semántica e IA generativa. Antes de la versión 1.6.3-alpha, algunos puntos finales devolvían cadenas de excepción en bruto a los clientes. Además, el material del token de inicio de sesión quedó expuesto en las respuestas de la interfaz de usuario/renderizadas y en la salida de rotación de tokens. Este problema ha sido parcheado en la versión 1.6.3-alpha.
Vulnerabilidad en OpenSift (CVE-2026-28676)
Severidad: ALTA
Fecha de publicación: 06/03/2026
Fecha de última actualización: 18/03/2026
OpenSift es una herramienta de estudio de IA que tamiza grandes conjuntos de datos utilizando búsqueda semántica e IA generativa. Antes de la versión 1.6.3-alpha, múltiples asistentes de almacenamiento utilizaban patrones de construcción de rutas que no aplicaban uniformemente la contención del directorio base. Esto creaba riesgo de inyección de rutas en los flujos de lectura/escritura/eliminación de archivos si se introducían valores maliciosos similares a rutas. Este problema ha sido parcheado en la versión 1.6.3-alpha.
Vulnerabilidad en OpenSift (CVE-2026-28677)
Severidad: ALTA
Fecha de publicación: 06/03/2026
Fecha de última actualización: 18/03/2026
OpenSift es una herramienta de estudio de IA que filtra grandes conjuntos de datos utilizando búsqueda semántica e IA generativa. Antes de la versión 1.6.3-alpha, el pipeline de ingesta de URL aceptaba URL remotas controladas por el usuario con restricciones de destino incompletas. Aunque existían comprobaciones de host privado/local, la falta de restricciones para URL con credenciales, puertos no estándar y redirecciones entre hosts dejaban rutas de abuso de clase SSRF en despliegues que no eran localhost. Este problema ha sido parcheado en la versión 1.6.3-alpha.
Vulnerabilidad en Crypt::NaCl::Sodium de TIMLEGGE (CVE-2026-30909)
Severidad: CRÍTICA
Fecha de publicación: 08/03/2026
Fecha de última actualización: 18/03/2026
Las versiones de Crypt::NaCl::Sodium hasta la 2.002 para Perl tienen posibles desbordamientos de enteros. Las funciones bin2hex, encrypt, aes256gcm_encrypt_afternm y seal no verifican que el tamaño de salida sea menor que SIZE_MAX, lo que podría llevar a un desbordamiento circular de enteros causando un búfer de salida de tamaño insuficiente. Es poco probable encontrar este problema, ya que la longitud del mensaje tendría que ser muy grande. Para bin2hex() la longitud bin_len tendría que ser > SIZE_MAX / 2 Para encrypt() la longitud msg_len tendría que ser > SIZE_MAX - 16U Para aes256gcm_encrypt_afternm() la longitud msg_len tendría que ser > SIZE_MAX - 16U Para seal() la longitud enc_len tendría que ser > SIZE_MAX - 64U
Vulnerabilidad en FortiSandbox Cloud de Fortinet (CVE-2026-25836)
Severidad: ALTA
Fecha de publicación: 10/03/2026
Fecha de última actualización: 18/03/2026
Una neutralización incorrecta de elementos especiales utilizados en un comando del sistema operativo (vulnerabilidad de 'inyección de comandos' del SO) en Fortinet FortiSandbox Cloud 5.0.4 puede permitir a un atacante privilegiado con perfil de superadministrador y acceso a la CLI ejecutar código o comandos no autorizados a través de solicitudes HTTP manipuladas.
Vulnerabilidad en GitLab (CVE-2025-12576)
Severidad: MEDIA
Fecha de publicación: 11/03/2026
Fecha de última actualización: 18/03/2026
GitLab ha remediado un problema en GitLab CE/EE que afecta a todas las versiones desde la 9.3 anterior a la 18.7.6, la 18.8 anterior a la 18.8.6, y la 18.9 anterior a la 18.9.2 que bajo ciertas condiciones podría haber permitido a un usuario autenticado causar una denegación de servicio debido a un manejo inadecuado de los datos de respuesta de los webhooks.
Vulnerabilidad en graphiti de getzep (CVE-2026-32247)
Severidad: ALTA
Fecha de publicación: 12/03/2026
Fecha de última actualización: 18/03/2026
Graphiti es un framework para construir y consultar grafos de contexto temporal para agentes de IA. Las versiones de Graphiti anteriores a la 0.28.2 contenían una vulnerabilidad de inyección Cypher en la construcción compartida de filtros de búsqueda para backends que no eran Kuzu. Los valores de etiquetas controlados por el atacante, suministrados a través de SearchFilters.node_labels, se concatenaban directamente en expresiones de etiquetas Cypher sin validación. En las implementaciones de MCP, esto era explotable no solo a través del acceso directo no confiable al servidor MCP de Graphiti, sino también a través de la inyección de prompts contra un cliente LLM que podía ser inducido a llamar a search_nodes con valores de entity_types controlados por el atacante. El servidor MCP mapeaba los entity_types a SearchFilters.node_labels, que luego alcanzaban la ruta de construcción Cypher vulnerable. Los backends afectados incluían Neo4j, FalkorDB y Neptune. Kuzu no se vio afectado por el problema de inyección de etiquetas porque utilizaba un manejo de etiquetas parametrizado en lugar de etiquetas Cypher interpoladas por cadena. Este problema se mitigó en la 0.28.2.
Vulnerabilidad en vim (CVE-2026-32249)
Severidad: MEDIA
Fecha de publicación: 12/03/2026
Fecha de última actualización: 18/03/2026
Vim es un editor de texto de código abierto de línea de comandos. Desde la versión 9.1.0011 hasta antes de la 9.2.0137, el compilador de expresiones regulares NFA de Vim, al encontrar una colección que contiene un carácter combinatorio como punto final de un rango de caracteres (por ejemplo, [0-0\u05bb]), emite incorrectamente los bytes de composición de ese carácter como estados NFA separados. Esto corrompe la pila postfija NFA, lo que resulta en que NFA_START_COLL tenga un puntero out1 NULL. Cuando nfa_max_width() posteriormente recorre el NFA compilado para estimar el ancho de coincidencia para la aserción de look-behind, desreferencia state->out1->out sin una verificación de NULL, causando un fallo de segmentación. Esta vulnerabilidad se corrige en la versión 9.2.0137.
Vulnerabilidad en ImageMagick (CVE-2026-32259)
Severidad: MEDIA
Fecha de publicación: 12/03/2026
Fecha de última actualización: 18/03/2026
ImageMagick es software libre y de código abierto utilizado para editar y manipular imágenes digitales. Antes de 7.1.2-16 y 6.9.13-41, cuando una asignación de memoria falla en el codificador sixel, sería posible escribir más allá del final de un búfer en la pila. Esta vulnerabilidad está corregida en 7.1.2-16 y 6.9.13-41.
Vulnerabilidad en deno de denoland (CVE-2026-32260)
Severidad: ALTA
Fecha de publicación: 12/03/2026
Fecha de última actualización: 18/03/2026
Deno es un entorno de ejecución de JavaScript, TypeScript y WebAssembly. Desde 2.7.0 hasta 2.7.1, existe una vulnerabilidad de inyección de comandos en el polyfill node:child_process de Deno (modo shell: true) que elude la corrección para CVE-2026-27190. La sanitización de argumentos en dos etapas en transformDenoShellCommand (ext/node/polyfills/internal/child_process.ts) tiene un error de prioridad: cuando un argumento contiene un patrón $VAR, se envuelve en comillas dobles (L1290) en lugar de comillas simples. Las comillas dobles en POSIX sh no suprimen la sustitución de comandos con comillas invertidas, permitiendo que se ejecuten comandos inyectados. Un atacante que controla los argumentos pasados a spawnSync o spawn con shell: true puede ejecutar comandos arbitrarios del sistema operativo, eludiendo el sistema de permisos de Deno. Esta vulnerabilidad está corregida en 2.7.2.
Vulnerabilidad en black de psf (CVE-2026-32274)
Severidad: ALTA
Fecha de publicación: 12/03/2026
Fecha de última actualización: 18/03/2026
Black es el formateador de código Python intransigente. Antes de la versión 26.3.1, Black escribe un archivo de caché, cuyo nombre se calcula a partir de varias opciones de formato. El valor de la opción --python-cell-magics se colocaba en el nombre del archivo sin sanitización, lo que permitía a un atacante que controla el valor de este argumento escribir archivos de caché en ubicaciones arbitrarias del sistema de archivos. Corregido en Black 26.3.1.
Vulnerabilidad en undici (CVE-2026-2581)
Severidad: MEDIA
Fecha de publicación: 12/03/2026
Fecha de última actualización: 18/03/2026
Esta es una vulnerabilidad de consumo de recursos no controlado (CWE-400) que puede conducir a una denegación de servicio (DoS). En versiones vulnerables de Undici, cuando interceptors.deduplicate() está habilitado, los datos de respuesta para solicitudes deduplicadas podrían acumularse en la memoria para los manejadores posteriores. Un endpoint ascendente controlado por un atacante o no confiable puede explotar esto con respuestas grandes/en fragmentos y solicitudes idénticas concurrentes, causando un alto uso de memoria y una posible terminación del proceso por OOM. Los usuarios afectados son aplicaciones que utilizan el interceptor de deduplicación de Undici contra endpoints que pueden producir cuerpos de respuesta grandes o de larga duración. Parches. El problema ha sido parcheado cambiando el comportamiento de deduplicación para transmitir fragmentos de respuesta a los manejadores posteriores a medida que llegan (en lugar de la acumulación del cuerpo completo), y evitando la deduplicación tardía cuando la transmisión del cuerpo ya ha comenzado. Los usuarios deberían actualizar a las primeras versiones oficiales de Undici (y Node.js, cuando corresponda) que incluyan este parche.