Instituto Nacional de ciberseguridad. Sección Incibe

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

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

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



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

  • Vulnerabilidad en un paquete HTTP en PowerLogic EGX100 y PowerLogic EGX300 (CVE-2021-22766)
    Severidad: ALTA
    Fecha de publicación: 11/06/2021
    Fecha de última actualización: 29/05/2026
    ** NO COMPATIBLE CUANDO SE ASIGNÓ ** UN CWE-20: Se presenta una vulnerabilidad de comprobación inapropiada de la entrada en PowerLogic EGX100 (versiones 3.0.0 y posteriores) y PowerLogic EGX300 (todas las versiones) que podría causar una denegación de servicio por medio de un paquete HTTP especialmente diseñado
  • Vulnerabilidad en Linux (CVE-2026-23286)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: atm: lec: corrige desreferencia de puntero nulo en lec_arp_clear_vccs syzkaller reportó una desreferencia de puntero nulo en lec_arp_clear_vccs(). Este problema puede ser fácilmente reproducido usando el reproductor de syzkaller. En el módulo ATM LANE (Emulación de LAN), el mismo atm_vcc puede ser compartido por múltiples entradas de lec_arp_table (por ejemplo, a través de entry->vcc o entry->recv_vcc). Cuando el VCC subyacente se cierra, lec_vcc_close() itera sobre todas las entradas ARP y llama a lec_arp_clear_vccs() para cada entrada coincidente. Por ejemplo, cuando lec_vcc_close() itera a través de las hlists en priv->lec_arp_empty_ones u otras tablas ARP: 1. En la primera iteración, para la primera entrada ARP coincidente que comparte el VCC, lec_arp_clear_vccs() libera el vpriv asociado (que es vcc->user_back) y establece vcc->user_back en NULL. 2. En la segunda iteración, para la siguiente entrada ARP coincidente que comparte el mismo VCC, lec_arp_clear_vccs() es llamada de nuevo. Obtiene un vpriv NULL de vcc->user_back (a través de LEC_VCC_PRIV(vcc)) y luego intenta desreferenciarlo a través de 'vcc->pop = vpriv->old_pop', lo que lleva a un fallo por desreferencia de puntero nulo. Soluciona esto añadiendo una comprobación de nulos para vpriv antes de desreferenciarlo. Si vpriv ya es NULL, significa que el VCC ha sido limpiado por una llamada anterior, por lo que podemos omitir de forma segura la limpieza y simplemente limpiar los punteros vcc/recv_vcc de la entrada. El bloque de limpieza completo (incluyendo vcc_release_async()) se coloca dentro de la guarda de vpriv porque un vpriv NULL indica que el VCC ya ha sido completamente liberado por una iteración anterior — repetir el desmontaje establecería banderas de forma redundante y activaría retrollamadas en un socket que ya se está cerrando. La etiqueta Fixes apunta al commit inicial porque la ruta entry->vcc ha sido vulnerable desde el código original. La ruta entry->recv_vcc fue añadida posteriormente por el commit 8d9f73c0ad2f ('atm: fix a memory leak of vcc->user_back') con el mismo patrón, y ambas rutas se corrigen aquí.
  • Vulnerabilidad en Linux (CVE-2026-23287)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: irqchip/sifive-plic: Solución para la interrupción congelada debido a la configuración de afinidad PLIC ignora el mensaje de finalización de interrupción para interrupciones deshabilitadas, explicado por la especificación: El PLIC señala que ha completado la ejecución de un gestor de interrupciones escribiendo el ID de interrupción que recibió de la solicitud en el registro de solicitud/finalización. El PLIC no verifica si el ID de finalización es el mismo que el último ID de solicitud para ese objetivo. Si el ID de finalización no coincide con una fuente de interrupción que está actualmente habilitada para el objetivo, la finalización es ignorada silenciosamente. Esto causó problemas en el pasado, porque una interrupción puede ser deshabilitada mientras aún está siendo gestionada y plic_irq_eoi() no tenía efecto. Eso se solucionó verificando si la interrupción está deshabilitada, y si es así, habilitarla, antes de enviar el mensaje de finalización. Esa verificación se realiza con irqd_irq_disabled(). Sin embargo, eso no es suficiente porque el bit de habilitación para el hart de gestión puede ser cero a pesar de que irqd_irq_disabled(d) sea falso. Esto puede ocurrir cuando la configuración de afinidad se cambia mientras un hart todavía está gestionando la interrupción. Este problema es fácilmente reproducible volcando un archivo grande a la uart (lo que genera muchas interrupciones) y al mismo tiempo seguir cambiando la configuración de afinidad de la interrupción de la uart. El puerto de la uart se congela casi instantáneamente. Solucione esto verificando el bit de habilitación del PLIC en lugar de irqd_irq_disabled().
  • Vulnerabilidad en Linux (CVE-2026-23288)
    Severidad: ALTA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/amdxdna: Corrección de memset fuera de límites en el manejo de ranuras de comando El espacio restante en una ranura de comando puede ser menor que el tamaño del encabezado de comando. Borrar el encabezado de comando con memset() antes de verificar el espacio de ranura disponible puede resultar en una escritura fuera de límites y corrupción de memoria. Esto se corrige moviendo la llamada a memset() después de la validación del tamaño.
  • Vulnerabilidad en Linux (CVE-2026-23289)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: IB/mthca: Añadir mthca_unmap_user_db() que se había omitido para mthca_create_srq() Corregir una fuga activable por el usuario en la ruta de fallo de la llamada al sistema.
  • Vulnerabilidad en Linux (CVE-2026-23290)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: usb: pegasus: validar puntos finales USB El controlador pegasus debería validar que el dispositivo que está sondeando tiene el número y tipos adecuados de puntos finales USB que espera antes de que se vincule a él. Si un dispositivo malicioso no tuviera los mismos urbs, el controlador fallará más tarde cuando acceda ciegamente a estos puntos finales.
  • Vulnerabilidad en Linux (CVE-2026-23291)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nfc: pn533: soltar correctamente la referencia de la interfaz USB al desconectarse Cuando el dispositivo se desconecta del controlador, hay un contador de referencias 'colgante' en la interfaz USB que fue obtenida en la función de devolución de llamada de sondeo. Solucionar esto soltando correctamente la referencia después de que hayamos terminado con ella.
  • Vulnerabilidad en Linux (CVE-2026-23293)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: vxlan: corrige la desreferencia de puntero NULL de nd_tbl cuando IPv6 está deshabilitado Al arrancar con el parámetro 'ipv6.disable=1', nd_tbl nunca se inicializa porque inet6_init() sale antes de que se llame a ndisc_init(), que es la función que lo inicializa. Si se inyecta un paquete IPv6 en la interfaz, se llama a route_shortcircuit() y ocurre una desreferencia de puntero NULL en neigh_lookup(). BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Traza de Llamadas: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Esto se corrige añadiendo una verificación temprana en route_shortcircuit() cuando el protocolo es ETH_P_IPV6. Tenga en cuenta que ipv6_mod_enabled() no se puede usar aquí porque VXLAN puede estar integrado incluso cuando IPv6 se compila como un módulo.
  • Vulnerabilidad en Linux (CVE-2026-23294)
    Severidad: ALTA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bpf: Corrige condición de carrera en devmap en PREEMPT_RT En kernels PREEMPT_RT, la xdp_dev_bulk_queue (bq) por CPU puede ser accedida concurrentemente por múltiples tareas preemptivas en la misma CPU. El código original asume que bq_enqueue() y __dev_flush() se ejecutan atómicamente con respecto la una a la otra en la misma CPU, confiando en local_bh_disable() para prevenir la expropiación. Sin embargo, en PREEMPT_RT, local_bh_disable() solo llama a migrate_disable() (cuando PREEMPT_RT_NEEDS_BH_LOCK no está configurado) y no deshabilita la expropiación, lo que permite que la planificación CFS expropie una tarea durante bq_xmit_all(), permitiendo que otra tarea en la misma CPU entre en bq_enqueue() y opere en la misma bq por CPU concurrentemente. Esto lleva a varias condiciones de carrera: 1. Doble liberación / uso después de liberación en bq->q[]: bq_xmit_all() toma una instantánea de cnt = bq->count, luego itera bq->q[0..cnt-1] para transmitir tramas. Si es expropiada después de la instantánea, una segunda tarea puede llamar a bq_enqueue() -> bq_xmit_all() en la misma bq, transmitiendo (y liberando) las mismas tramas. Cuando la primera tarea se reanuda, opera con punteros obsoletos en bq->q[], causando uso después de liberación. 2. Corrupción de bq->count y bq->q[]: bq_enqueue() concurrente modificando bq->count y bq->q[] mientras bq_xmit_all() los está leyendo. 3. Condición de carrera de desmontaje de dev_rx/xdp_prog: __dev_flush() borra bq->dev_rx y bq->xdp_prog después de bq_xmit_all(). Si es expropiada entre el retorno de bq_xmit_all() y bq->dev_rx = NULL, una bq_enqueue() expropiadora ve dev_rx aún configurado (no-NULL), omite añadir bq a la flush_list, y encola una trama. Cuando __dev_flush() se reanuda, borra dev_rx y elimina bq de la flush_list, dejando huérfana la trama recién encolada. 4. __list_del_clearprev() en flush_node: similar a la condición de carrera de cpumap, ambas tareas pueden llamar a __list_del_clearprev() en el mismo flush_node, la segunda desreferencia el puntero prev ya establecido en NULL. La condición de carrera entre la tarea A (__dev_flush -> bq_xmit_all) y la tarea B (bq_enqueue -> bq_xmit_all) en la misma CPU: Tarea A (xdp_do_flush) Tarea B (redirección ndo_xdp_xmit) ---------------------- -------------------------------- __dev_flush(flush_list) bq_xmit_all(bq) cnt = bq->count /* ej. 16 */ /* comienza a iterar bq->q[] */ <-- CFS expropia la Tarea A --> bq_enqueue(dev, xdpf) bq->count == DEV_MAP_BULK_SIZE bq_xmit_all(bq, 0) cnt = bq->count /* ¡los mismos 16! */ ndo_xdp_xmit(bq->q[]) /* tramas liberadas por el controlador */ bq->count = 0 <-- La Tarea A se reanuda --> ndo_xdp_xmit(bq->q[]) /* uso después de liberación: ¡tramas ya liberadas! */ Solucione esto añadiendo un local_lock_t a xdp_dev_bulk_queue y adquiriéndolo en bq_enqueue() y __dev_flush(). Estas rutas ya se ejecutan bajo local_bh_disable(), así que use local_lock_nested_bh() que en no-RT es una anotación pura sin sobrecarga, y en PREEMPT_RT proporciona un bloqueo de suspensión por CPU que serializa el acceso a la bq.
  • Vulnerabilidad en Linux (CVE-2026-23295)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: accel/amdxdna: Solución para el interbloqueo en suspensión y reanudación Cuando una aplicación emite una consulta IOCTL mientras la suspensión automática está en ejecución, puede producirse un interbloqueo. La ruta de consulta mantiene dev_lock y luego llama a pm_runtime_resume_and_get(), que espera a que la suspensión en curso finalice. Mientras tanto, la devolución de llamada de suspensión intenta adquirir dev_lock y se bloquea, lo que resulta en un interbloqueo. Esto se soluciona liberando dev_lock antes de llamar a pm_runtime_resume_and_get() y volviéndolo a adquirir después de que la llamada finalice. También se adquiere dev_lock en la devolución de llamada de reanudación para mantener la consistencia del bloqueo.
  • Vulnerabilidad en Linux (CVE-2026-23297)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nfsd: Corrige la fuga de referencia de cred en nfsd_nl_threads_set_doit(). syzbot informó una fuga de memoria de la estructura cred. [0] nfsd_nl_threads_set_doit() pasa get_current_cred() a nfsd_svc(), pero put_cred() no es llamada después de eso. El cred es finalmente pasado a _svc_xprt_create(), que llama a get_cred() con el cred para la estructura svc_xprt. La propiedad del contador de referencias por get_current_cred() no es transferida a ningún lugar y simplemente se fuga. nfsd_svc() también es llamada desde write_threads(), pero no incrementa file->f_cred allí. nfsd_nl_threads_set_doit() es llamada desde sendmsg() y current->cred no desaparece. Usemos current_cred() en nfsd_nl_threads_set_doit(). [0]: ERROR: fuga de memoria objeto sin referencia 0xffff888108b89480 (tamaño 184): comm 'syz-executor', pid 5994, jiffies 4294943386 volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 369454a7): 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+0x412/0x580 mm/slub.c:5270 prepare_creds+0x22/0x600 kernel/cred.c:185 copy_creds+0x44/0x290 kernel/cred.c:286 copy_process+0x7a7/0x2870 kernel/fork.c:2086 kernel_clone+0xac/0x6e0 kernel/fork.c:2651 __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792 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-23298)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: can: ucan: Corrección de bucle infinito por mensajes de longitud cero Si un dispositivo ucan defectuoso recibe un mensaje con el campo de longitud del mensaje establecido en 0, entonces el controlador entrará en un bucle infinito en ucan_read_bulk_callback(), colgando el sistema. Si la longitud es 0, simplemente omita el mensaje y pase al siguiente. Esto ha sido corregido en el controlador kvaser_usb en el pasado en el commit 0c73772cd2b8 ('can: kvaser_usb: leaf: Corrección de posible bucle infinito en los analizadores de comandos'), así que debe haber algunos dispositivos defectuosos por ahí como este en algún lugar.
  • Vulnerabilidad en Linux (CVE-2026-23299)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 29/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: Bluetooth: purgar colas de error en destructores de sockets Cuando la marca de tiempo TX está habilitada a través de SO_TIMESTAMPING, los SKB pueden ser encolados en sk_error_queue y permanecerán allí hasta ser consumidos. Si el espacio de usuario nunca llega a leer las marcas de tiempo, o si el controlador es eliminado inesperadamente, estos SKB se filtrarán. Solución añadiendo llamadas a skb_queue_purge() para sk_error_queue en los destructores de bluetooth afectados. RFCOMM no utiliza actualmente sk_error_queue.