Instituto Nacional de ciberseguridad. Sección Incibe

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

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

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



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

  • Vulnerabilidad en kernel de Linux (CVE-2024-49894)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrige el índice fuera de los límites en la traducción del formato de hardware degamma Corrige el problema del índice fuera de los límites en la función `cm_helper_translate_curve_to_degamma_hw_format`. El problema podría ocurrir cuando el índice 'i' excede el número de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max
  • Vulnerabilidad en kernel de Linux (CVE-2024-49924)
    Severidad: ALTA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: pxafb: Arregla posible use after free en pxafb_task() En la función pxafb_probe, llama a la función pxafb_init_fbinfo, después de lo cual &fbi->task se asocia con pxafb_task. Además, dentro de esta función pxafb_init_fbinfo, la función pxafb_blank dentro de la estructura &pxafb_ops es capaz de programar trabajo. Si eliminamos el módulo que llamará a pxafb_remove para hacer la limpieza, llamará a la función unregister_framebuffer que puede llamar a do_unregister_framebuffer para liberar fbi->fb a través de put_fb_info(fb_info), mientras que se utilizará el trabajo mencionado anteriormente. La secuencia de operaciones que pueden llevar a un error de UAF es la siguiente: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Solucione el problema asegurándose de cancelar el trabajo antes de continuar con la limpieza en pxafb_remove. Tenga en cuenta que solo el usuario root puede eliminar el controlador en tiempo de ejecución.
  • Vulnerabilidad en Linux (CVE-2026-23300)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: ipv6: corrige el pánico cuando una ruta IPv4 referencia un nexthop IPv6 de loopback Cuando se crea un objeto nexthop IPv6 independiente con un dispositivo de loopback (p. ej., 'ip -6 nexthop add id 100 dev lo'), fib6_nh_init() lo clasifica erróneamente como una ruta de rechazo. Esto se debe a que los objetos nexthop no tienen prefijo de destino (fc_dst=::), lo que hace que fib6_is_reject() coincida con cualquier nexthop de loopback. La ruta de rechazo omite fib_nh_common_init(), dejando nhc_pcpu_rth_output sin asignar. Si una ruta IPv4 referencia posteriormente este nexthop, __mkroute_output() desreferencia nhc_pcpu_rth_output NULL y entra en pánico. Simplificar la verificación en fib6_nh_init() para que solo coincida con rutas de rechazo explícitas (RTF_REJECT) en lugar de usar fib6_is_reject(). La heurística de promoción de loopback en fib6_is_reject() se maneja por separado por ip6_route_info_create_nh(). Después de este cambio, los tres casos se comportan de la siguiente manera: 1. Ruta de rechazo explícita ('ip -6 route add unreachable 2001:db8::/64'): RTF_REJECT está configurado, entra en la ruta de rechazo, omite fib_nh_common_init(). Sin cambio de comportamiento. 2. Ruta de rechazo de loopback implícita ('ip -6 route add 2001:db8::/32 dev lo'): RTF_REJECT no está configurado, toma la ruta normal, se llama a fib_nh_common_init(). ip6_route_info_create_nh() aún lo promueve a rechazo posteriormente. nhc_pcpu_rth_output se asigna pero no se usa, lo cual es inofensivo. 3. Objeto nexthop independiente ('ip -6 nexthop add id 100 dev lo'): RTF_REJECT no está configurado, toma la ruta normal, se llama a fib_nh_common_init(). nhc_pcpu_rth_output se asigna correctamente, corrigiendo el fallo cuando las rutas IPv4 referencian este nexthop.
  • Vulnerabilidad en Linux (CVE-2026-23301)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ASoC: SDCA: Añadir comprobación de fallo de asignación para el nombre de la Entidad Actualmente, find_sdca_entity_iot() puede asignar una cadena para el nombre de la Entidad, pero no comprueba si esa asignación tuvo éxito. Añadir la comprobación NULL faltante después de la asignación.
  • Vulnerabilidad en Linux (CVE-2026-23302)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: anotar condiciones de carrera de datos alrededor de sk->sk_{data_ready,write_space} skmsg (y probablemente otras capas) están cambiando estos punteros mientras otras CPUs podrían leerlos concurrentemente. Añadir las correspondientes anotaciones READ_ONCE()/WRITE_ONCE() para UDP, TCP y AF_UNIX.
  • Vulnerabilidad en Linux (CVE-2026-23303)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: smb: cliente: No registrar credenciales en texto plano en cifs_set_cifscreds Cuando el registro de depuración está habilitado, cifs_set_cifscreds() registra la carga útil de la clave y expone el nombre de usuario y la contraseña en texto plano. Eliminar el registro de depuración para evitar exponer credenciales.
  • Vulnerabilidad en Linux (CVE-2026-23304)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ipv6: corrección de desreferencia de puntero NULL en ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() puede devolver NULL cuando el dispositivo esclavo está siendo desasociado de un VRF. Todos los demás llamadores manejan esto, pero perdimos la alternativa a loopback en ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() con el commit 4832c30d5458 ('net: ipv6: put host and anycast routes on device with address'). KASAN: desreferencia de puntero nulo en el rango [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Traza de Llamadas: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) Me sentí tentado a reelaborar el código de desasociación para borrar la bandera primero e insertar synchronize_rcu() antes de que eliminemos el superior. Pero parece que la alternativa explícita a loopback_dev es un patrón establecido. Y supongo que evitar el synchronize_rcu() también es bueno.
  • Vulnerabilidad en Linux (CVE-2026-23305)
    Severidad: ALTA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: accel/rocket: corregir el desenrollado en la ruta de error en rocket_probe Cuando rocket_core_init() falla (como podría ser el caso con EPROBE_DEFER), necesitamos desenrollar correctamente decrementando el contador que acabamos de incrementar y, si este es el primer núcleo que no pudimos sondear, eliminar también el dispositivo DRM de rocket con rocket_device_fini(). Esto coincide con la lógica en rocket_remove(). No desenrollar correctamente resulta en accesos fuera de límites.
  • Vulnerabilidad en Linux (CVE-2026-23306)
    Severidad: ALTA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: scsi: pm8001: Corrección de uso después de liberación en pm8001_queue_command() El commit e29c47fe8946 ('scsi: pm8001: Simplificar pm8001_task_exec()') refactoriza pm8001_queue_command(), sin embargo, introduce una causa potencial de un escenario de doble liberación cuando cambia la función para que devuelva -ENODEV en caso de estado de phy inactivo/dispositivo desaparecido. En esta ruta, pm8001_queue_command() actualiza el estado de la tarea y llama a task_done para indicar a la capa superior que la tarea ha sido gestionada. Sin embargo, esto también libera la tarea SAS subyacente. Entonces se devuelve un -ENODEV al llamador. Cuando libsas sas_ata_qc_issue() recibe este valor de error, asume que la tarea no fue gestionada/enviada a la cola por LLDD y procede a limpiar y liberar la tarea de nuevo, resultando en una doble liberación. Dado que pm8001_queue_command() gestiona la tarea SAS en este caso, debería devolver 0 al llamador indicando que la tarea ha sido gestionada.
  • Vulnerabilidad en Linux (CVE-2026-23307)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: can: ems_usb: ems_usb_read_bulk_callback(): comprobar la longitud adecuada de un mensaje Al examinar los datos en un urb USB, la actual_length es el tamaño del búfer pasado al controlador, no la transfer_buffer_length que es establecida por el controlador como el tamaño máximo del búfer. Al analizar los mensajes en ems_usb_read_bulk_callback(), comprobar correctamente el tamaño tanto al principio del análisis del mensaje para asegurarse de que sea lo suficientemente grande para la estructura esperada, como al final del mensaje para asegurarse de que no desbordemos más allá del final del búfer para el siguiente mensaje.
  • Vulnerabilidad en Linux (CVE-2026-23308)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: pinctrl: equilibrium: corregir el rastro de advertencia al cargar Las funciones de callback 'eqbr_irq_mask()' y 'eqbr_irq_ack()' también se llaman en la función de callback 'eqbr_irq_mask_ack()'. Esto se hace para evitar la duplicación de código fuente. El problema, es que en la función 'eqbr_irq_mask()' también llama a la función gpiolib 'gpiochip_disable_irq()'. Esto genera el siguiente rastro de advertencia en el log para cada gpio al cargar. [ 6.088111] ------------[ cut here ]------------ [ 6.092440] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:3810 gpiochip_disable_irq+0x39/0x50 [ 6.097847] Modules linked in: [ 6.097847] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.59+ #0 [ 6.097847] Tainted: [W]=WARN [ 6.097847] RIP: 0010:gpiochip_disable_irq+0x39/0x50 [ 6.097847] Code: 39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 80 66 09 fb c3 <0f> 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 [ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046 [ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008 [ 6.097847] RDX: ffff888001be9000 RSI: ffff888001b2dd00 RDI: ffff888001be02a0 [ 6.097847] RBP: ffffc9000000b860 R08: 0000000000000000 R09: 0000000000000000 [ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514 [ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000 [ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS:0000000000000000 [ 6.097847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0 [ 6.097847] Call Trace: [ 6.097847] [ 6.097847] ? eqbr_irq_mask+0x63/0x70 [ 6.097847] ? no_action+0x10/0x10 [ 6.097847] eqbr_irq_mask_ack+0x11/0x60 En otro controlador (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) la interrupción no se deshabilita aquí. Para solucionar esto, no llame a la función 'eqbr_irq_mask()' y 'eqbr_irq_ack()'. En su lugar, implemente esto directamente sin deshabilitar las interrupciones.
  • Vulnerabilidad en Linux (CVE-2026-23309)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: tracing: Añadir comprobación de puntero NULL a trigger_data_free() Si trigger_data_alloc() falla y devuelve NULL, event_hist_trigger_parse() salta a la ruta de error out_free. Aunque kfree() maneja de forma segura un puntero NULL, trigger_data_free() no lo hace. Esto causa una desreferencia de puntero NULL en trigger_data_free() al evaluar data->cmd_ops->set_filter. Corregir el problema añadiendo una comprobación de puntero NULL a trigger_data_free(). El problema fue encontrado por un agente experimental de revisión de código basado en gemini-3.1-pro mientras revisaba backports en v6.18.y.
  • Vulnerabilidad en Linux (CVE-2026-23310)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 28/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bpf/bonding: rechazar el cambio de política de hash de transmisión (xmit_hash_policy) a vlan+srcmac cuando XDP está cargado bond_option_mode_set() ya rechaza los cambios de modo que harían incompatible un programa XDP cargado a través de bond_xdp_check(). Sin embargo, bond_option_xmit_hash_policy_set() no tiene tal protección. Para los modos 802.3ad y balance-xor, bond_xdp_check() devuelve falso cuando la política de hash de transmisión (xmit_hash_policy) es vlan+srcmac, porque la carga útil 802.1q suele estar ausente debido a la descarga de hardware. Esto significa que un usuario puede: 1. Adjuntar un programa XDP nativo a un bond en modo 802.3ad/balance-xor con una política de hash de transmisión (xmit_hash_policy) compatible (por ejemplo, capa2+3). 2. Cambiar la política de hash de transmisión (xmit_hash_policy) a vlan+srcmac mientras XDP permanece cargado. Esto deja bond->xdp_prog establecido, pero bond_xdp_check() ahora devuelve falso para el mismo dispositivo. Cuando el bond es destruido posteriormente, dev_xdp_uninstall() llama a bond_xdp_set(dev, NULL, NULL) para eliminar el programa, lo que activa la protección de bond_xdp_check() y devuelve -EOPNOTSUPP, desencadenando: WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL)) Solucione esto rechazando los cambios de política de hash de transmisión (xmit_hash_policy) a vlan+srcmac cuando un programa XDP está cargado en un bond en modo 802.3ad o balance-xor. El commit 39a0876d595b ('net, bonding: No permitir vlan+srcmac con XDP') introdujo bond_xdp_check() que devuelve falso para los modos 802.3ad/balance-xor cuando la política de hash de transmisión (xmit_hash_policy) es vlan+srcmac. La verificación se integró en bond_xdp_set() para rechazar la asociación de XDP con una política incompatible, pero la ruta simétrica -- impidiendo que la política de hash de transmisión (xmit_hash_policy) se cambie a un valor incompatible después de que XDP ya esté cargado -- se dejó sin protección en bond_option_xmit_hash_policy_set(). Nota: El commit 094ee6017ea0 ('bonding: verificar programa xdp al establecer modo de bond') añadió posteriormente una protección similar a bond_option_mode_set(), pero bond_option_xmit_hash_policy_set() permaneció sin protección.