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 Bonitasoft, SA (CVE-2024-26542)
    Severidad: MEDIA
    Fecha de publicación: 27/02/2024
    Fecha de última actualización: 17/09/2025
    Vulnerabilidad de Cross Site Scripting en Bonitasoft, SA v.7.14. y corregido en v.9.0.2, 8.0.3, 7.15.7, 7.14.8 permite a los atacantes ejecutar código arbitrario a través de un payload manipulado en el campo Nombre para mostrar de grupos.
  • Vulnerabilidad en yyjson (CVE-2024-25713)
    Severidad: ALTA
    Fecha de publicación: 29/02/2024
    Fecha de última actualización: 17/09/2025
    yyjson hasta 0.8.0 tiene un doble free, lo que lleva a la ejecución remota de código en algunos casos, porque la función pool_free carece de comprobaciones de bucle. (pool_free es parte del asignador de series de grupos, junto con pool_malloc y pool_realloc).
  • Vulnerabilidad en Hono en Node.js (CVE-2024-32652)
    Severidad: ALTA
    Fecha de publicación: 19/04/2024
    Fecha de última actualización: 17/09/2025
    El adaptador @hono/node-server le permite ejecutar su aplicación Hono en Node.js. Antes de 1.10.1, la aplicación se bloquea cuando recibe un encabezado de Host con un valor que `@hono/node-server` no puede manejar bien. Los valores no válidos son aquellos que la "URL" no puede analizar como un nombre de host, como una cadena vacía, barras diagonales "/" y otras cadenas. La versión 1.10.1 incluye la solución para este problema.
  • Vulnerabilidad en Hono (CVE-2024-32869)
    Severidad: MEDIA
    Fecha de publicación: 23/04/2024
    Fecha de última actualización: 17/09/2025
    Hono es un framework de aplicación web que brinda soporte para cualquier tiempo de ejecución de JavaScript. Antes de la versión 4.2.7, cuando se usabaserveStatic con deno, era posible recorrer el directorio donde se encontraba `main.ts`. Esto puede resultar en la recuperación de archivos inesperados. La versión 4.2.7 contiene un parche para el problema.
  • Vulnerabilidad en kernel de Linux (CVE-2024-36906)
    Severidad: ALTA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9381/1: kasan: borrar veneno de pila obsoleta Encontramos el siguiente fallo de OOB: [33.452494] ================== =================================================== [ 33.453513] ERROR: KASAN: pila fuera de los límites en refresco_cpu_vm_stats.constprop.0+0xcc/0x2ec [33.454660] Escritura de tamaño 164 en la dirección c1d03d30 mediante task swapper/0/0 [33.455515] [33.455767] CPU: 0 PID : 0 Comm: swapper/0 Tainted: GO 6.1.25-mainline #1 [ 33.456880] Nombre del hardware: Sistema basado en DT genérico [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.45 9072] dump_stack_lvl de print_report+0x158/0x4a4 [ 33.459863] print_report de kasan_report+0x9c/0x148 [ 33.460616] kasan_report de kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range de memset+0x20/0x 3c [33.462157] conjunto de memorias de refresco_cpu_vm_stats.constprop.0+0xcc/ 0x2ec [33.463064] refresco_cpu_vm_stats.constprop.0 de tick_nohz_idle_stop_tick+0x180/0x53c [33.464181] tick_nohz_idle_stop_tick de do_idle+0x264/0x354 [33.465029] do_idle de cpu_startup _entry+0x20/0x24 [ 33.465769] cpu_startup_entry de rest_init+0xf0/0xf4 [ 33.466528] rest_init de arch_post_acpi_subsys_init+0x0/0x18 [33.467397] [33.467644] La dirección con errores pertenece a la pila de task swapper/0/0 [33.468493] y se encuentra en el desplazamiento 112 en el framework: [33.469172] [ 33.469917 ] [ 33.470165] Este framework tiene 2 objetos: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] La dirección con errores pertenece a la página física: [ 33.47 2862] página:3cd72da8 refcount:1 mapcount:0 mapeo:00000000 índice:0x0 pfn:0x41d03 [ 33.473944] banderas: 0x1000(reservado|zona=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 000000 00000000 ffffffff 00000001 [ 33.475656] sin formato: 00000000 [33.476050] página volcada porque: kasan: mal acceso detectado [33.476816] [33.477061] Estado de la memoria alrededor de la dirección con errores: [33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 [33.478630] c1d03c80 : 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 3.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] === ==================================================== ==== Descubrimos que la causa principal de este OOB es que el brazo no elimina el veneno de la pila obsoleta en el caso de cpuidle. Este parche hace referencia a arch/arm64/kernel/sleep.S para resolver este problema. Del compromiso citado [1] que explica el problema. Las funciones que el compilador ha instrumentado para KASAN colocan veneno en la sombra de la pila al ingresar y eliminan este veneno antes de regresar. En el caso de cpuidle, las CPU salen del kernel a varios niveles de profundidad en el código C. Cualquier función instrumentada en esta ruta crítica dejará partes de la sombra de la pila envenenadas. Si las CPU pierden contexto y regresan al kernel a través de una ruta fría, restauramos un contexto anterior guardado en __cpu_suspend_enter que se olvida y nunca eliminamos el veneno que colocaron en el área de sombra de la pila mediante llamadas a funciones entre este y la salida real del kernel. . Por lo tanto, (dependiendo del diseño del framework de pila) las llamadas posteriores a funciones instrumentadas pueden afectar este veneno obsoleto, lo que resulta en símbolos KASAN (falsos) en la consola. Para evitar esto, elimine cualquier veneno obsoleto del subproceso inactivo de una CPU antes de ponerla en línea. De la confirmación citada [2] Ampliar para verificar CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: borrar veneno de pila obsoleta") [2] commit d56a9ef84bd0 ("kasan, arm64: pila sin veneno solo con CONFIG_KASAN_STACK")
  • Vulnerabilidad en kernel de Linux (CVE-2024-36914)
    Severidad: ALTA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: omitir la reescritura cuando no sea aplicable [POR QUÉ] el detector de errores de seguridad de memoria dinámica (KASAN) detecta y genera mensajes de error "ERROR: KASAN: slab-out- of-bounds" como conector de reescritura no admite ciertas funciones que no están inicializadas. [CÓMO] Omítelos cuando el tipo de conector sea DRM_MODE_CONNECTOR_WRITEBACK.
  • Vulnerabilidad en kernel de Linux (CVE-2024-36915)
    Severidad: ALTA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: llcp: corrige nfc_llcp_setsockopt() copias inseguras syzbot informó llamadas inseguras a copy_from_sockptr() [1] Utilice copy_safe_from_sockptr() en su lugar. [1] ERROR: KASAN: losa fuera de los límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] ERROR: KASAN: losa fuera de los límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de los límites en nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 Lectura de tamaño 4 en la dirección ffff88801caa1ec3 por tarea syz-executor459/5078 CPU: 0 PID: 5078 Comm : syz-executor459 No contaminado 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan /report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] copy_from_sockptr include/linux/sockptr.h:55 [en línea] nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 do_sock_setsockopt+0x3b 1/ 0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] xb5/0xd0 red/zócalo .c:2340 do_syscall_64+0xfd/0x240 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 0 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 000000000 0000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000 000000000 R14: 0000000000000000 R15: 0000000000000000
  • Vulnerabilidad en kernel de Linux (CVE-2024-36917)
    Severidad: MEDIA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrige el desbordamiento en blk_ioctl_discard() No hay verificación de desbordamiento de 'start + len' en blk_ioctl_discard(). La tarea bloqueada ocurre si envía un ioctl de descarte con el siguiente parámetro: start = 0x80000000000ff000, len = 0x8000000000fff000; Agregue la validación de desbordamiento ahora.
  • Vulnerabilidad en kernel de Linux (CVE-2024-36918)
    Severidad: MEDIA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Verificar el tamaño del valor del mapa del filtro de floración. Este parche agrega una verificación faltante para la creación del filtro de floración, rechazando valores superiores a KMALLOC_MAX_SIZE. Esto alinea el mapa de floración con muchos otros tipos de mapas. La falta de esta protección puede provocar fallas del kernel para tamaños de valores que desbordan los de int. Syzkaller captó tal accidente. El siguiente parche agrega más barandillas en un nivel inferior.
  • Vulnerabilidad en kernel de Linux (CVE-2024-36936)
    Severidad: MEDIA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi/unaccepted: toque el bloqueo suave durante la aceptación de la memoria. El commit 50e782a86c98 ("efi/unaccepted: solucione los bloqueos suaves causados por la aceptación de la memoria paralela") ha liberado el bloqueo de giro para que otras CPU puedan usar la memoria. aceptación en paralelo y no activa el bloqueo suave en otras CPU. Sin embargo, el bloqueo suave se mostró de forma intermitente si la memoria del TD invitado es grande y el tiempo de espera del bloqueo suave se establece en 1 segundo: RIP: 0010:_raw_spin_unlock_irqrestore Seguimiento de llamadas:? __hrtimer_run_queues ? hrtimer_interrupt? watchdog_timer_fn? __sysvec_apic_timer_interrupt? __pfx_watchdog_timer_fn? sysvec_apic_timer_interrupt ? __hrtimer_run_queues ? hrtimer_interrupt? asm_sysvec_apic_timer_interrupt? _raw_spin_unlock_irqrestore? __sysvec_apic_timer_interrupt? sysvec_apic_timer_interrupt aceptar_memoria try_to_accept_memory do_huge_pmd_anonymous_page get_page_from_freelist __handle_mm_fault __alloc_pages __folio_alloc? __tdx_hypercall handle_mm_fault vma_alloc_folio do_user_addr_fault do_huge_pmd_anonymous_page exc_page_fault? __do_huge_pmd_anonymous_page asm_exc_page_fault __handle_mm_fault Cuando el irq local está habilitado al final de Accept_memory(), el bloqueo suave detecta que el mecanismo de vigilancia en una sola CPU no ha sido alimentado por un tiempo. Es decir, incluso otras CPU no serán bloqueadas por spinlock, la CPU actual podría apestar con el irq local deshabilitado por un tiempo, lo que perjudica no solo al nmi watchdog sino también al softlockup. Chao Gao señaló que la aceptación de la memoria podría llevar mucho tiempo y hubo un informe similar antes. Por lo tanto, para evitar cualquier detección de softlocup durante esta etapa, proporcione al softlockup una bandera para omitir la verificación del tiempo de espera al final de Accept_memory(), invocando touch_softlockup_watchdog().
  • Vulnerabilidad en kernel de Linux (CVE-2024-36937)
    Severidad: MEDIA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xdp: use el campo flags para eliminar la ambigüedad de la redirección de transmisión Al redireccionar un paquete usando XDP, el asistente bpf_redirect_map() configurará la información del destino de redireccionamiento en la estructura bpf_redirect_info (usando el asistente __bpf_xdp_redirect_map() función), y la función xdp_do_redirect() leerá esta información después de que el programa XDP regrese y pasará el framework al destino de redireccionamiento correcto. Cuando se utiliza el indicador BPF_F_BROADCAST para realizar una redirección de multidifusión a un mapa completo, __bpf_xdp_redirect_map() establece el puntero 'mapa' en la estructura bpf_redirect_info para que apunte al mapa de destino que se va a transmitir. Y xdp_do_redirect() reacciona al valor de este puntero de mapa para decidir si se trata de una transmisión o una redirección de valor único. Sin embargo, si el mapa de destino se destruye antes de llamar a xdp_do_redirect(), el puntero del mapa se borrará (mediante bpf_clear_redirect_map()) sin esperar a que deje de ejecutarse ningún programa XDP. Esto hace que xdp_do_redirect() piense que la redirección fue a un único objetivo, pero el puntero de destino también es NULL (dado que las redirecciones de difusión no tienen un único objetivo), por lo que esto provoca un bloqueo cuando se pasa un puntero NULL a dev_map_enqueue( ). Para solucionar este problema, cambie xdp_do_redirect() para reaccionar directamente a la presencia del indicador BPF_F_BROADCAST en el valor 'flags' en la estructura bpf_redirect_info para eliminar la ambigüedad entre un redireccionamiento de destino único y de transmisión. Y solo lea el puntero del 'mapa' si la bandera de transmisión está activada, abortando si se ha borrado mientras tanto. Esto evita el bloqueo, manteniendo al mismo tiempo la limpieza atómica (basada en cmpxchg) del puntero del mapa y sin agregar más comprobaciones en la ruta rápida sin transmisión.
  • Vulnerabilidad en kernel de Linux (CVE-2024-36945)
    Severidad: MEDIA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige la fuga de vecino y rtable en smc_ib_find_route() En smc_ib_find_route(), el vecino encontrado por neigh_lookup() y rtable resuelto por ip_route_output_flow() no se liberan ni se colocan antes devolver. Puede causar la fuga de recuento, así que corríjalo.
  • Vulnerabilidad en kernel de Linux (CVE-2024-36947)
    Severidad: MEDIA
    Fecha de publicación: 30/05/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: qibfs: arreglar la fuga de dentry simple_recursive_removal() elimina las referencias de fijación a todos los positivos en el subárbol. Para los casos en los que su argumento se ha mantenido vivo solo mediante la fijación, eso es exactamente lo correcto, pero aquí el argumento proviene de la búsqueda de dcache, que debe equilibrarse con dput() explícito. Jodido por: Al Viro
  • Vulnerabilidad en kernel de Linux (CVE-2024-36961)
    Severidad: MEDIA
    Fecha de publicación: 03/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/debugfs: soluciona dos problemas de bloqueo con la depuración de la zona térmica. Con la disposición actual de bloqueo de la zona térmica en el código debugfs, el espacio de usuario puede abrir el archivo de "mitigaciones" para una zona térmica antes. El puntero debugfs de la zona está configurado, lo que dará como resultado una desreferencia del puntero NULL en tze_seq_start(). Además, Thermal_debug_tz_remove() no se llama bajo el bloqueo de la zona térmica, por lo que puede ejecutarse en paralelo con las otras funciones que acceden al objeto struct Thermal_debugfs de la zona térmica. Luego, puede borrar tz->debugfs después de que una de esas funciones lo haya verificado y el objeto struct Thermal_debugfs puede liberarse prematuramente. Para solucionar el primer problema, pase un puntero al objeto struct Thermal_debugfs de la zona térmica para debugfs_create_file() en Thermal_debug_tz_add() y haga que tze_seq_start(), tze_seq_next(), tze_seq_stop() y tze_seq_show() lo recuperen de s->private. de un puntero al objeto de la zona térmica. Esto garantizará que tz_debugfs sea válido en todos los accesos a archivos de "mitigaciones" hasta que Thermal_debugfs_remove_id() llamado por Thermal_debug_tz_remove() elimine ese archivo. Para solucionar el segundo problema, use tz->lock en Thermal_debug_tz_remove() alrededor de la verificación del valor de tz->debugfs (en caso de que la misma zona térmica se elimine al mismo tiempo en dos subprocesos diferentes) y se restablezca a NULL. CC :6.8+ # 6.8+
  • Vulnerabilidad en kernel de Linux (CVE-2024-36963)
    Severidad: ALTA
    Fecha de publicación: 03/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracefs: restablece los permisos al volver a montar si los permisos son opciones. Hay una inconsistencia en la forma en que se manejan los permisos en tracefs. Debido a que los permisos se generan cuando se accede a ellos, de forma predeterminada son los permisos del inodo raíz si el usuario nunca los configuró. Si el usuario establece los permisos, entonces se establece una bandera y los permisos se guardan a través del inodo (para archivos tracefs) o un campo de atributo interno (para eventfs). Pero si ocurre un reinicio que especifica los permisos, todos los archivos que no fueron modificados por el usuario se actualizan, pero los que sí no lo fueron. Si el usuario volviera a montar el sistema de archivos con un permiso determinado, entonces todos los archivos y directorios dentro de ese sistema de archivos deberían actualizarse. Esto puede causar problemas de seguridad si se actualizó el permiso de un archivo pero el administrador lo olvidó. Podrían pensar incorrectamente que volver a montar con los permisos establecidos actualizaría todos los archivos, pero perdería algunos. Por ejemplo: # cd /sys/kernel/tracing # chgrp 1002 current_tracer # ls -l [..] -rw-r----- 1 raíz raíz 0 1 de mayo 21:25 buffer_size_kb -rw-r---- - 1 raíz raíz 0 1 de mayo 21:25 buffer_subbuf_size_kb -r--r----- 1 raíz raíz 0 1 de mayo 21:25 buffer_total_size_kb -rw-r----- 1 raíz lkp 0 1 de mayo 21:25 current_tracer -rw-r----- 1 raíz raíz 0 1 de mayo 21:25 Dynamic_events -r--r----- 1 raíz raíz 0 1 de mayo 21:25 dyn_ftrace_total_info -r--r----- 1 root root 0 1 de mayo 21:25 enable_functions Donde current_tracer ahora tiene el grupo "lkp". # montar -o remontar, gid=1001. # ls -l -rw-r----- 1 rastreo de raíz 0 1 de mayo 21:25 buffer_size_kb -rw-r----- 1 rastreo de raíz 0 1 de mayo 21:25 buffer_subbuf_size_kb -r--r--- -- 1 rastreo de raíz 0 1 de mayo 21:25 buffer_total_size_kb -rw-r----- 1 rastreo de raíz 0 1 de mayo 21:25 current_tracer -rw-r----- 1 rastreo de raíz 0 1 de mayo 21:25 Dynamic_events -r--r----- 1 rastreo de raíz 0 1 de mayo 21:25 dyn_ftrace_total_info -r--r----- 1 rastreo de raíz 0 1 de mayo 21:25 enable_functions Todo cambió excepto el "current_tracer". Agregue una nueva lista de enlaces que realice un seguimiento de todos los tracefs_inodes que tienen indicadores de permiso que indican si el archivo/directorio debe usar el permiso del inodo raíz o no. Luego, al volver a montar, borre todas las banderas para que el comportamiento predeterminado de usar el permiso del inodo raíz se realice para todos los archivos y directorios.
  • Vulnerabilidad en kernel de Linux (CVE-2024-38566)
    Severidad: MEDIA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige las suposiciones del verificador sobre socket->sk. El verificador asume que el campo 'sk' en 'struct socket' es válido y no NULL cuando el puntero 'socket' en sí es confiable y no NULL. Puede que ese no sea el caso cuando el socket se acaba de crear y se pasó al gancho LSM socket_accept. Corrija esta suposición del verificador y ajuste las pruebas.
  • Vulnerabilidad en kernel de Linux (CVE-2024-38572)
    Severidad: ALTA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrige el acceso fuera de los límites de qmi_invoke_handler() Actualmente, no hay ninguna entrada de terminador para ath12k_qmi_msg_handlers, por lo que se enfrenta a la siguiente advertencia de KASAN, ======== ==================================================== ======== ERROR: KASAN: global fuera de los límites en qmi_invoke_handler+0xa4/0x148 Lectura de tamaño 8 en la dirección ffffffd00a6428d8 por tarea kworker/u8:2/1273 CPU: 0 PID: 1273 Comm: kworker /u8:2 No contaminado 5.4.213 #0 Cola de trabajo: qmi_msg_handler qmi_data_ready_work Rastreo de llamadas: dump_backtrace+0x0/0x20c show_stack+0x14/0x1c dump_stack+0xe0/0x138 print_address_description.isra.5+0x30/0x330 __kasan_report+0x16 c/0x1bc kasan_report+0xc /0x14 __asan_load8+0xa8/0xb0 qmi_invoke_handler+0xa4/0x148 qmi_handle_message+0x18c/0x1bc qmi_data_ready_work+0x4ec/0x528 Process_one_work+0x2c0/0x440 trabajador_thread+0x324/0x4b8 0x228 ret_from_fork+0x10/0x18 La dirección pertenece a la variable: ath12k_mac_mon_status_filter_default +0x4bd8/0xfffffffffffe2300 [ath12k] [...] ======================================= ============================ Agregue una entrada de terminador ficticia al final para ayudar a qmi_invoke_handler() a atravesar hasta la entrada del terminador sin acceder a un índice fuera de los límites. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
  • Vulnerabilidad en kernel de Linux (CVE-2024-38578)
    Severidad: ALTA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ecryptfs: corrige el tamaño del búfer para el paquete etiqueta 66. A la descripción 'Formato de paquete TAG 66' le faltan el código de cifrado y los campos de suma de verificación que están empaquetados en el paquete de mensaje. Como resultado, el búfer asignado para el paquete es 3 bytes demasiado pequeño y write_tag_66_packet() escribirá hasta 3 bytes más allá del final del búfer. Solucione este problema aumentando el tamaño de la asignación para que todo el paquete siempre quepa en el búfer. Esto corrige el siguiente error de kasan slab-out-of-bounds: ERROR: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Escritura de tamaño 1 en la dirección ffff88800afbb2a5 mediante tarea táctil/181 CPU: 0 PID: 181 Comm : touch No contaminado 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 01/04/2014 Seguimiento de llamadas: 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX : ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e4 8d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 00000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 Asignado por tarea 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 _write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 ruta_openat+ 0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 Entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  • Vulnerabilidad en kernel de Linux (CVE-2024-38585)
    Severidad: ALTA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tools/nolibc/stdlib: corrige el error de memoria en realloc() Pase user_p_len a memcpy() en lugar de heap->len para evitar que realloc() copie un tamaño extra de(heap) bytes más allá de la región asignada.
  • Vulnerabilidad en kernel de Linux (CVE-2024-38586)
    Severidad: ALTA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: corrige una posible corrupción del búfer en anillo en paquetes Tx fragmentados. Se encontró un problema en el RTL8125b al transmitir pequeños paquetes fragmentados, por el cual se insertaban entradas no válidas en el búfer del anillo de transmisión, lo que posteriormente generaba llamadas a dma_unmap_single() con una dirección nula. Esto se debió a que rtl8169_start_xmit() no notó los cambios en nr_frags que pueden ocurrir cuando se rellenan paquetes pequeños (para evitar peculiaridades del hardware) en rtl8169_tso_csum_v2(). Para solucionar este problema, posponga la inspección de nr_frags hasta que se haya aplicado el relleno.
  • Vulnerabilidad en kernel de Linux (CVE-2024-38592)
    Severidad: MEDIA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Init `ddp_comp` con devm_kcalloc() En el caso de que `conn_routes` sea verdadero, asignamos una ranura adicional en la matriz `ddp_comp` pero mtk_drm_crtc_create() nunca apareció para inicializarlo en el caso de prueba que ejecuté. Para mí, esto provocó un bloqueo posterior cuando recorrimos la matriz en mtk_drm_crtc_mode_valid(). Esto me apareció cuando arranqué con `slub_debug=FZPUA` que envenena la memoria inicialmente. Sin `slub_debug` no pude reproducir, presumiblemente porque el código posterior maneja que el valor sea NULL y en la mayoría de los casos (no garantizado en todos los casos) la memoria que devolvió el asignador comenzó como 0. Realmente no está de más inicializar el array con devm_kcalloc() ya que la matriz es pequeña y la sobrecarga de iniciar un puñado de elementos en 0 es pequeña. En general, iniciar la memoria a cero es una práctica más segura y, por lo general, se sugiere usar solo las funciones de asignación que no son de inicio si realmente es necesario. Cambiemos la función para usar una función de asignación que ponga a cero la memoria. Para mí, esto evita el accidente.
  • Vulnerabilidad en kernel de Linux (CVE-2024-38596)
    Severidad: MEDIA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: corrige ejecucións de datos en unix_release_sock/unix_stream_sendmsg Se identificó una condición de ejecución de datos en af_unix. En una ruta de datos, la función de escritura unix_release_sock() escribe atómicamente en sk->sk_shutdown usando WRITE_ONCE. Sin embargo, en el lado del lector, unix_stream_sendmsg() no lo lee atómicamente. En consecuencia, este problema está provocando que se produzca el siguiente símbolo de KCSAN: ERROR: KCSAN: data-race en unix_release_sock / unix_stream_sendmsg escribe (marcado) en 0xffff88867256ddbb de 1 byte por tarea 7270 en la CPU 28: unix_release_sock (net/unix/af_unix.c: 640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508 ) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/ common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) leído en 0xffff88867256ddbb de 1 bytes por la tarea 989 en la CPU 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket .c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/ socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64 .S:130) valor cambiado: 0x01 -> 0x03 Los números de línea están relacionados con el commit dd5a440a31fa ("Linux 6.9-rc7"). El commit e1d09c2c2f57 ("af_unix: corregir ejecucións de datos alrededor de sk->sk_shutdown.") abordó un problema comparable en el pasado con respecto a sk->sk_shutdown. Sin embargo, pasó por alto resolver esta ruta de datos en particular. Este parche solo ofende la función unix_stream_sendmsg(), ya que las otras lecturas parecen estar protegidas por unix_state_lock() como se explica en
  • Vulnerabilidad en kernel de Linux (CVE-2024-38599)
    Severidad: ALTA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jffs2: evita que el nodo xattr desborde el bloque de borrado. Agregue una verificación para asegurarse de que el tamaño del nodo xattr solicitado no sea mayor que el bloque de borrado menos el marcador de limpieza. A diferencia de los nodos de inodo habituales, los nodos xattr no se dividen en partes ni se distribuyen en múltiples bloques de borrado, lo que significa que un nodo xattr no debe ocupar más de un bloque de borrado. Si el valor xattr solicitado es demasiado grande, el nodo xattr puede extenderse al siguiente bloque de borrado, sobrescribiendo los nodos y provocando errores como: jffs2: argh. nodo agregado en un lugar incorrecto en 0x0000b050(2) jffs2: nextblock 0x0000a000, esperado en 0000b00c jffs2: error: (823) do_verify_xattr_datum: el CRC del nodo falló en 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: aviso: 823) jffs2_get_inode_nodes: Nodo El CRC del encabezado falló en 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: El nodo en 0x0000000c con longitud 0x00001044 se ejecutaría sobre el final del bloque de borrado jffs2: ¿Quizás el sistema de archivos se creó con un tamaño de borrado incorrecto? jffs2: jffs2_scan_eraseblock(): Máscara de bits mágica 0x1985 no encontrada en 0x00000010: 0x1044 en su lugar. Esto rompe el sistema de archivos y puede provocar fallas de KASAN como: ERROR: KASAN: losa fuera de los límites en jffs2_sum_add_kvec+0x125e/0x15d0 Lectura de tamaño 4 en addr ffff88802c31e914 por tarea repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140? Entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.
  • Vulnerabilidad en kernel de Linux (CVE-2024-38601)
    Severidad: MEDIA
    Fecha de publicación: 19/06/2024
    Fecha de última actualización: 17/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: corrige una ejecución entre lectores y cambia el tamaño de las comprobaciones. El código del lector en rb_get_reader_page() intercambia una nueva página del lector en el búfer circular haciendo cmpxchg en old->list.prev ->siguiente para apuntar a la nueva página. Después de eso, si la operación es exitosa, old->list.next->prev también se actualiza. Esto significa que la lista doblemente enlazada subyacente es temporalmente inconsistente, página->anterior->siguiente o página->siguiente->anterior podría no ser igual a la página para alguna página en el búfer circular. La operación de cambio de tamaño en ring_buffer_resize() se puede invocar en paralelo. Llama a rb_check_pages(), que puede detectar la inconsistencia descrita y detener el seguimiento: [190.271762] ------------[ cortar aquí ]------------ [ 190.271771] ADVERTENCIA: CPU: 1 PID: 6186 en kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [190.271789] Módulos vinculados en: [...] [190.271991] Módulos contaminados descargados: intel_uncore_frequency(E) :1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: cargado Contaminado: GE 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 01/04/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Código: [.. .] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 00000000000000007 RCX: ffff8eba01f13d80 [ 19 0.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 00000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:000000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 [ 190 .272077] Seguimiento de llamadas: [190.272098 ] [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] _entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248 ] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] Entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d26 3 [ 190.272381] Código: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000 000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12 : 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 00000000000000002 [ 190.272412] [ 4] ---[ end trace 0000000000000000 ]--- Tenga en cuenta que ring_buffer_resize() llama a rb_check_pages() solo si el trace_buffer principal tiene grabación desactivada. El reciente commit d78ab792705c ("rastreo: detener el rastreador actual al cambiar el tamaño del búfer") hace que ahora sea siempre el caso, lo que hace que sea más probable experimentar este problema. No obstante, la ventana para llegar a esta ejecución es muy pequeña. Para ayudar a reproducirlo, se puede agregar un bucle de retardo en rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) ir a girar; for (unsigned i = 0; i < 1U << 26; i++) /* bucle de retardo insertado ---truncado---
  • Vulnerabilidad en Hono (CVE-2024-43787)
    Severidad: MEDIA
    Fecha de publicación: 22/08/2024
    Fecha de última actualización: 17/09/2025
    Hono es un framework de aplicación web que brinda soporte para cualquier tiempo de ejecución de JavaScript. El middleware Hono CSRF se puede omitir utilizando un encabezado Content-Type manipulado. Los tipos MIME no distinguen entre mayúsculas y minúsculas, pero isRequestedByFormElementRe solo coincide con minúsculas. Como resultado, el atacante puede eludir el middleware csrf utilizando el tipo MIME similar a una forma en mayúsculas. Esta vulnerabilidad se solucionó en 4.5.8.
  • Vulnerabilidad en Hono (CVE-2024-48913)
    Severidad: MEDIA
    Fecha de publicación: 15/10/2024
    Fecha de última actualización: 17/09/2025
    Hono, un framework web, anterior a la versión 4.6.5 es vulnerable a la omisión del middleware de cross-site request forgery (CSRF) mediante una solicitud sin encabezado Content-Type. Aunque el middleware CSRF verifica el encabezado Content-Type, Hono siempre considera que una solicitud sin un encabezado Content-Type es segura. Esto puede permitir que un atacante omita la protección CSRF implementada con el middleware CSRF de Hono. La versión 4.6.5 corrige este problema.