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-2021-47424)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: Se corrigió la liberación de un vector IRQ misceláneo no inicializado. Cuando la configuración de VSI falló en i40e_probe() como parte de la configuración del conmutador PF, el controlador intentaba liberar vectores IRQ misceláneos en i40e_clear_interrupt_scheme y produjo un kernel Oops: Intentando liberar IRQ 266 que ya está libre ADVERTENCIA: CPU: 0 PID: 5 en kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Cola de trabajo: eventos work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Seguimiento de llamadas: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0? acpi_ut_update_ref_count.part.1+0x8e/0x345? acpi_ut_update_object_reference+0x15e/0x1e2? chain+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0? acpi_register_gsi_ioapic+0x93/0x170? pci_conf1_read+0xa4/0x100? pci_bus_read_config_word+0x49/0x70? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 Process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 El problema es que en ese momento aún no se habían asignado varios vectores IRQ y obtenemos un seguimiento de llamada de que el controlador está intentando liberar vectores IRQ que ya están libres. Agregue una verificación en i40e_clear_interrupt_scheme para el estado __I40E_MISC_IRQ_REQUESTED PF antes de llamar a i40e_free_misc_vector. Este estado se establece solo si se inicializaron correctamente varios vectores IRQ.
  • Vulnerabilidad en kernel de Linux (CVE-2021-47425)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: acpi: corrige la fuga de recursos en la reconfiguración del dispositivo añdido acpi_i2c_find_adapter_by_handle() llama a bus_find_device() que toma una referencia en el adaptador que nunca se libera, lo que resultará en una fuga de recuento de referencias y haga que el adaptador no sea extraíble. Asegúrese de colocar el adaptador después de crear el cliente de la misma manera que lo hacemos para OF. [wsa: título fijo]
  • Vulnerabilidad en kernel de Linux (CVE-2021-47431)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la fuga de pin_count de gart.bo gmc_v{9,10}_0_gart_disable() no se llama y coincide con la función gart_enbale correspondiente en el caso SRIOV. Esto provocará una pérdida de pin_count de gart.bo al descargar el controlador.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52748)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: f2fs: evitar aviso de desbordamiento de formato. Con la opción gcc y W=1, aparece un aviso como este: fs/f2fs/compress.c: En la función 'f2fs_init_page_array_cache': fs/f2fs /compress.c:1984:47: error: directiva '%u' escribiendo entre 1 y 7 bytes en una región de tamaño entre 5 y 8 [-Werror=format-overflow=] 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~ La cadena "f2fs_page_array_entry-%u:%u" puede tener hasta 35. El primer "%u" puede tener hasta 4 y el segundo "%u" puede hasta 7, por lo que el tamaño total es "24 + 4 + 7 = 35". El tamaño de slab_name debe ser 35 en lugar de 32.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52754)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: imon: corrige el acceso a un recurso no válido para la segunda interfaz. El controlador imon prueba dos interfaces USB y, en la prueba de la segunda interfaz, el controlador asume ciegamente que la primera interfaz obtuvo atado con el mismo conductor imon. Generalmente es cierto, pero aún es posible que la primera interfaz esté vinculada con otro controlador a través de un descriptor con formato incorrecto. Entonces puede provocar una corrupción de la memoria, como descubrió syzkaller; El controlador imon accede a los datos de drvdata como objeto struct imon_context aunque es uno completamente diferente asignado por otro controlador. Este parche agrega una verificación de cordura (si la primera interfaz está realmente vinculada con el controlador imon o no) para evitar el problema anterior en el momento de la prueba.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52761)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: detección de desbordamiento de VMAP_STACK confirmación segura para subprocesos 31da94c25aea ("riscv: agregar detección de desbordamiento de VMAP_STACK") se agregó soporte para CONFIG_VMAP_STACK. Si se detecta un desbordamiento, la CPU cambia a `shadow_stack` temporalmente antes de cambiar finalmente a `overflow_stack` por CPU. Si dos CPU/harts están corriendo y terminan en una pila de kernel desbordada, uno o ambos terminarán corrompiendo el estado del otro porque `shadow_stack` no es por CPU. Este parche optimiza el cambio de pila de desbordamiento por CPU seleccionando directamente `overflow_stack` por CPU y elimina `shadow_stack`. Los siguientes son los cambios en este parche: Define una macro asm para obtener símbolos por CPU en el registro de destino. - En Entry.S, cuando se detecta un desbordamiento, la pila de desbordamiento por CPU se ubica mediante la macro ASM por CPU. Calcular el símbolo por CPU requiere un registro temporal. x31 se guarda en CSR_SCRATCH (CSR_SCRATCH es de todos modos cero ya que estamos en el kernel). Consulte los enlaces para obtener información adicional relevante y una solución alternativa. Probado por `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT` Registro de fallas del kernel debajo ¡Espacio de pila insuficiente para manejar la excepción!/debug/provoke-crash/DIRECT Pila de tareas: [0xff20000010a98000..0xff20000010a9c000] Pila de desbordamiento: [0xff600001f7d98370..0xff600001f7d99370] CPU: 1 PID: 205 Comm: bash No contaminado 6.1.0-rc2-00001-g328a1f96f7b9 #34 Nombre de hardware: riscv-virtio,qemu (DT) epc: __memset+0x60/0x fc ra: bucle_recursivo+ 0x48/0xc6 [lkdtm] epc: ffffffff808de0e4 ra: ffffffff0163a752 sp: ff20000010a97e80 gp: ffffffff815c0330 tp: ff600000820ea280 t0: ff20000010a97e88 t1: 0000000000002e t2: 3233206874706564 s0: ff20000010a982b0 s1: 0000000000000012 a0: ff20000010a97e88 a1: 0000000000000000 a2: 000000 0000000400 a3: ff20000010a98288 a4: 0000000000000000 a5: 0000000000000000 a6: fffffffffffe43f0 a7: 00007ffffffffff s2: ff20000010a97e88 s3: ffffffff01644680 s4: ff20000010a9be90 5: ff600000842ba6c0 s6: 00aaaaaac29e42b0 s7: 00fffffff0aa3684 s8: 00aaaaaac2978040 s9: 00000000000000065 s10: 00ffffff8a7cad10 s11: ff8a76a4e0 t3: ffffffff815dbaf4 t4: ffffffff815dbaf4 t5: ffffffff815dbab8 t6 : ff20000010a9bb48 estado: 0000000200000120 badaddr: ff20000010a97e88 causa: 000000000000000f Pánico del kernel: no se sincroniza: desbordamiento de la pila del kernel CPU: 1 PID: 205 Comm: bash no contaminado 6.1.0-rc2-0000 1-g328a1f96f7b9 #34 Nombre del hardware: riscv-virtio,qemu (DT) Seguimiento de llamadas: [] dump_backtrace+0x30/0x38 [] show_stack+0x40/0x4c [] dump_stack_lvl+0x44/0x5c [] dump_stack+0x18 /0x20 [ ] panic+0x126/0x2fe [] walk_stackframe+0x0/0xf0 [] recursive_loop+0x48/0xc6 [lkdtm] SMP: deteniendo las CPU secundarias ---[ fin del pánico del kernel - no se sincroniza: desbordamiento de la pila del kernel]- --
  • Vulnerabilidad en kernel de Linux (CVE-2023-52762)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: virtio-blk: corrige el desbordamiento implícito en virtio_max_dma_size. Los siguientes códigos tienen una conversión implícita de size_t a u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); Esto puede provocar un desbordamiento, Ex (size_t)4G -> (u32)0. Una vez que virtio_max_dma_size() tenga un tamaño mayor que U32_MAX, use U32_MAX en su lugar.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52764)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: gspca: cpia1: desplazamiento fuera de los límites en set_flicker. Syzkaller informó el siguiente problema: UBSAN: desplazamiento fuera de los límites en drivers/media/usb/gspca /cpia1.c:1031:27 el exponente de desplazamiento 245 es demasiado grande para el tipo 'int' de 32 bits. Cuando el valor de la variable "sd->params.exposure.gain" excede el número de bits en un número entero, se realiza un desplazamiento. Se informa un error fuera de los límites. Se activa porque la variable "currentexp" no puede desplazarse hacia la izquierda más que el número de bits de un número entero. Para evitar un rango no válido durante el desplazamiento a la izquierda, se agrega la expresión condicional.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52771)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/port: corrige delete_endpoint() frente a la ejecución de cancelación del registro principal. El subsistema CXL, en el momento cxl_mem ->probe(), establece un linaje de puertos (objetos struct cxl_port) entre un punto final y la raíz de una topología CXL. Cada puerto, incluido el puerto del punto final, está conectado al controlador cxl_port. Dada esa configuración, se deduce que cuando cualquier puerto en ese linaje pasa por un evento cxl_port ->remove(), o el memdev pasa por un evento cxl_mem ->remove(). La jerarquía debajo del puerto eliminado, o toda la jerarquía si se elimina el memdev, debe bajar. La devolución de llamada delete_endpoint() tiene cuidado de verificar si se llama para derribar la jerarquía o si solo se llama para derribar memdev porque un puerto ancestro está pasando por ->remove(). Ese cuidado debe tenerse en cuenta con el dispositivo_lock() del padre del punto final. Lo que requiere la corrección de 2 errores: 1/ Se necesita una referencia en el padre para evitar escenarios de use after free como esta firma: ERROR: spinlock bad magic en CPU#0, kworker/u56:0/11 Nombre del hardware: QEMU PC estándar (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 24/05/2023 Cola de trabajo: cxl_port detach_memdev [cxl_core] RIP: 0010:spin_bug+0x65/0xa0 Seguimiento de llamadas: do_raw_spin_lock+0x69/0xa0 5 /0xb80 delete_endpoint+0xad/0x150 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 detach_memdev+0x15/0x20 [cxl_core] proceso_one_work+0x1e3/0x4c0 _thread+0x1dd/0x3d0 2/ En el caso de RCH topologías, el dispositivo principal que debe bloquearse no siempre es @port->dev como lo devuelve cxl_mem_find_port(); utilice endpoint->dev.parent en su lugar.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52774)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: protege la cola de dispositivos contra el acceso concurrente. En dasd_profile_start() se cuenta la cantidad de solicitudes en la cola de dispositivos. El acceso a la cola de dispositivos no está protegido contra el acceso simultáneo. Con muchas E/S paralelas, especialmente con dispositivos alias habilitados, la cola de dispositivos puede cambiar mientras dasd_profile_start() accede a la cola. En el peor de los casos, esto provoca un pánico en el kernel debido a accesos incorrectos al puntero. Solucione este problema bloqueando el dispositivo antes de acceder a la cola y contando las solicitudes. Además, la verificación de un puntero de datos de perfil válido se puede realizar antes para evitar bloqueos innecesarios en una ruta activa.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52775)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: evita la corrupción de datos causada por el rechazo. Encontramos un problema de corrupción de datos durante las pruebas de SMC-R en aplicaciones Redis. El punto de referencia tiene una baja probabilidad de informar un error extraño, como se muestra a continuación. "Error: Error de protocolo, obtuve "\xe2" como byte de tipo de respuesta" Finalmente, encontramos que los datos de error recuperados eran los siguientes: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 1 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 Es bastante obvio que este es un mensaje SMC DECLINE, lo que significa que las aplicaciones recibieron un mensaje de protocolo SMC. Descubrimos que esto se debía a las siguientes situaciones: cliente servidor ¦ propuesta clc -------------> ¦ clc aceptar <------------- ¦ clc confirmar -------------> esperar confirmación de llc enviar confirmación de llc ¦ confirmación de llc fallida ¦ x------ (después de 2 s) tiempo de espera de espera llc confirmar rsp esperar declinar (después de 1 s) tiempo de espera (después de 2s) tiempo de espera ¦ rechazo --------------> ¦ rechazo <-------------- Como resultado, se envió un mensaje de rechazo en la implementación, y este mensaje fue leído desde TCP por la conexión que ya estaba en reserva. Este parche duplica el tiempo de espera del cliente al doble del valor del servidor. Con este simple cambio, los mensajes de rechazo nunca deberían cruzarse ni colisionar (durante el tiempo de espera de confirmación del enlace). Este problema requiere una solución inmediata, ya que las actualizaciones del protocolo implican una solución a más largo plazo.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52790)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: swiotlb: corrige asignaciones de TLB fuera de los límites con CONFIG_SWIOTLB_DYNAMIC Limita la longitud de la lista libre al tamaño del IO TLB. El grupo transitorio puede ser más pequeño que IO_TLB_SEGSIZE, pero la lista libre se inicializa asumiendo que el número total de ranuras es un múltiplo de IO_TLB_SEGSIZE. Como resultado, swiotlb_area_find_slots() puede asignar ranuras más allá del final de un búfer IO TLB transitorio.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52792)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: no intente realizar la limpieza después de que cxl_region_setup_targets() falle. Confirme 5e42bcbc3fef ("cxl/region: decrement ->nr_targets on error in cxl_region_attach()") intentó evitar ' Los mismos errores de inicialización cuando ->nr_targets excedieron 16, simplemente disminuyendo ->nr_targets cuando cxl_region_setup_targets() falló. La confirmación 86987c766276 ("cxl/region: Limpiar lista de objetivos al adjuntar error") extendió esa limpieza para borrar también cxled->pos y p->targets[pos]. El error de inicialización se solucionó por separado mediante: Commit 8d4285425714 ("cxl/region: Reparar advertencias de variables no inicializadas de configuración de puerto") que se fusionó unos días después de 5e42bcbc3fef. Pero ahora la limpieza original cuando falla cxl_region_setup_targets() impide que se reutilicen los recursos del decodificador de conmutador y punto final: 1) la limpieza no establece la región del decodificador en NULL, lo que da como resultado que futuras llamadas a dpa_size_store() devuelvan -EBUSY 2) el decodificador no liberado correctamente, lo que resulta en futuros errores de confirmación asociados con el conmutador ascendente. Ahora que los errores de inicialización se solucionaron por separado, la limpieza adecuada para este caso es simplemente regresar inmediatamente. Luego, los recursos asociados con este objetivo se limpian normalmente cuando se elimina la región fallida. La disminución de ->nr_targets en el caso de error también ayudó a evitar un desbordamiento de la matriz p->targets[], así que agregue una nueva verificación para evitar ese desbordamiento. Probado intentando crear una región no válida para una topología de 2 conmutadores * 2 puntos finales y luego creando una región válida.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52796)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipvlan: agregue el asistente ipvlan_route_v6_outbound(). Inspirado en los informes de syzbot que utilizan una pila de múltiples dispositivos ipvlan. Reduzca el tamaño de pila necesario en ipvlan_process_v6_outbound() moviendo la estructura flowi6 utilizada para la búsqueda de rutas en un asistente no integrado. ipvlan_route_v6_outbound() necesita 120 bytes en la pila, que se recuperan inmediatamente. También asegúrese de que ipvlan_process_v4_outbound() no esté incluido. Es posible que también tengamos que reducir MAX_NEST_DEV, porque solo syzbot usa configuraciones con más de cuatro dispositivos apilados. ERROR: La página de protección de la pila de TAREA fue alcanzada en ffffc9000e803ff8 (la pila es ffffc9000e804000..ffffc9000e808000) página de protección de la pila: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 No contaminado 6.1.52-syzkaller # 0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/10/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Código: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0 f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000000000 RCX: ffffffff817e5bf2 RDX: 000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 00000000000000000 R09: 0000000000000000 R10: 000000000000000 00 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:00000000000000 00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: <#DF> [] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [] instrument_atomic_read include/linux/instrumented.h:72 [en línea] [] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [en línea] [] cpumask_test_cpu include/linux /cpumask.h:506 [en línea] [] cpu_online include/linux/cpumask.h:1092 [en línea] [] trace_lock_acquire include/trace/events/lock.h:24 [en línea] [] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [] rcu_read_lock include/linux/rcupdate.h:747 [en línea] [] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [ ] pol_lookup_func incluir/net /ip6_fib.h:584 [en línea] [] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route .c:2638 [] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [] ip6_route_output include/net/ip6_route.h:100 [en línea] [] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan _core.c: 473 [en línea] [] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [en línea] [] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [en línea] [ ] ipvlan_queue_xmit +0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [] netdev_start_xmit include/linux/netdevice.h: 4966 [en línea] [] xmit_one net/core/dev.c:3644 [en línea] [] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [] __dev_queue_xmit+ 0x16b2/ 0x3370 net/core/dev.c:4324 --truncado--
  • Vulnerabilidad en kernel de Linux (CVE-2023-52803)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: el cliente RPC limpió los pipefs dentries liberados. La limpieza de pipefs dentries del cliente RPC está en la cola de trabajo separada rpc_remove_pipedir(), que se encarga del bloqueo del superbloque de pipefs. En algunos escenarios especiales, cuando el kernel libera el pipefs sb del cliente actual e inmediatamente asigna un nuevo pipefs sb, la función rpc_remove_pipedir juzgaría mal la existencia de pipefs sb que no es el que solía contener. Como resultado, rpc_remove_pipedir limpiaría las dentrías de pipefs liberadas. Para solucionar este problema, rpc_remove_pipedir debe verificar si el pipefs sb actual es consistente con el pipefs sb original. KASAN puede detectar este error: ============================================ =============== [250.497700] BUG: KASAN: slab-use-after-free en dget_parent+0x195/0x200 [250.498315] Lectura de tamaño 4 en la dirección ffff88800a2ab804 por tarea kworker/0 :18/106503 [250.500549] Cola de trabajo: eventos rpc_free_client_work [250.501001] Seguimiento de llamadas: [250.502880] kasan_report+0xb6/0xf0 [250.503209]? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] /0x230 [ 250.505598] Process_one_work+0x8ee/0x13b0 ... [ 22.039056] Asignado por la tarea 244: [ 22.039390 ] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.0408 89] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive +0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057 ] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Liberado por la tarea 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] 25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Última creación de trabajo potencialmente relacionado: [ 22.052952] kasan_save_stack+0x22/ 0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ __dentry_kill+ 0x3be/0x540 [22.054900] Shrink_dentry_list+0x199/0x510 [22.055293] Shrink_dcache_parent+ 0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] 3a/0x60 [22.057234] rpc_kill_sb+0x121/0x200
  • Vulnerabilidad en kernel de Linux (CVE-2023-52804)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/jfs: agregue verificación de validez para db_maxag y db_agpref. Tanto db_maxag como db_agpref se utilizan como índice de la matriz db_agfree, pero actualmente no hay verificación de validez para db_maxag y db_agpref, lo cual puede dar lugar a errores. El siguiente es un error relacionado reportado por Syzbot: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 el índice 7936 está fuera de rango para el tipo 'atomic_t[128]' Agregue verificando que el Los valores de db_maxag y db_agpref son índices válidos para la matriz db_agfree.
  • Vulnerabilidad en kernel de Linux (CVE-2021-47383)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tty: corrige el acceso vmalloc fuera de los límites en imageblit. Este problema ocurre cuando un programa de espacio de usuario realiza un ioctl FBIOPUT_VSCREENINFO pasando la estructura fb_var_screeninfo que contiene solo los campos xres, yres y bits_per_pixel con valores. Si esta estructura es la misma que la ioctl anterior, vc_resize() la detecta y no llama a resize_screen(), dejando fb_var_screeninfo incompleto. Y esto lleva a que updatecrollmode() calcule un valor incorrecto para fbcon_display->vrows, lo que hace que real_y() devuelva un valor incorrecto de y, y ese valor, eventualmente, hace que imageblit acceda a un valor de dirección fuera de los límites. . Para resolver este problema, hice que se llamara a resize_screen() incluso si la pantalla no necesita ningún cambio de tamaño, por lo que "arreglará y completará" fb_var_screeninfo de forma independiente.
  • Vulnerabilidad en kernel de Linux (CVE-2021-47391)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: asegúrese de que rdma_addr_cancel() ocurra antes de emitir más solicitudes. El FSM puede ejecutarse en un círculo permitiendo llamar a rdma_resolve_ip() dos veces en el mismo id_priv. Si bien esto no puede suceder sin realizar el trabajo, viola la invariante de que la misma solicitud en segundo plano de resolución de dirección no puede estar activa dos veces. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): para #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. el controlador sigue ejecutándose...] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler)!! ahora hay dos solicitudes en la lista de solicitudes rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // Process_one_req() lo elimina automáticamente spin_lock_bh(&lock); cancel_delayed_work(&req->trabajo); if (!list_empty(&req->list)) == verdadero! rdma_addr_cancel() regresa después de que se realiza el proceso_on_req #1 kfree(id_priv) Process_one_req(): para #2 addr_handler(): mutex_lock(&id_priv->handler_mutex); !! El use after free en id_priv rdma_addr_cancel() espera que haya una solicitud en la lista y solo cancela la primera. El comportamiento de autoeliminación del trabajo sólo ocurre después de que el manipulador ha regresado. Esto genera situaciones en las que req_list puede tener dos solicitudes para el mismo "identificador" pero rdma_addr_cancel() solo cancela la primera. El segundo requisito permanece activo más allá de rdma_destroy_id() y usará id_priv después de liberarlo una vez que inevitablemente se active. Solucione este problema recordando si id_priv ha llamado a rdma_resolve_ip() y cancele siempre antes de volver a llamarlo. Esto garantiza que req_list nunca obtenga más de un elemento y no cueste nada en el flujo normal que nunca utiliza esta extraña ruta de error.
  • Vulnerabilidad en kernel de Linux (CVE-2021-47392)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: corrige la fuga del oyente en el fallo de rdma_cma_listen_on_all(). Si cma_listen_on_all() falla, deja el ID por dispositivo todavía en la lista de escucha, pero el estado no está configurado en RDMA_CM_ADDR_BOUND. Cuando el cmid finalmente se destruye, no se llama a cma_cancel_listens() debido a un estado incorrecto; sin embargo, los ID por dispositivo aún mantienen el refcount evitando que el ID se destruya, lo que genera un punto muerto: tarea:rping estado:D pila: 0 pid: 19605 ppid: 47036 banderas: 0x00000084 Seguimiento de llamadas: __schedule+0x29a/0x780? free_unref_page_commit+0x9b/0x110 Schedule+0x3c/0xa0 Schedule_timeout+0x215/0x2b0? __flush_work+0x19e/0x1e0 wait_for_completion+0x8d/0xf0 _destroy_id+0x144/0x210 [rdma_cm] ucma_close_id+0x2b/0x40 [rdma_ucm] __destroy_id+0x93/0x2c0 [rdma_ucm] ? __xa_erase+0x4a/0xa0 ucma_destroy_id+0x9a/0x120 [rdma_ucm] ucma_write+0xb8/0x130 [rdma_ucm] vfs_write+0xb4/0x250 ksys_write+0xb5/0xd0 ? syscall_trace_enter.isra.19+0x123/0x190 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Asegúrese de que cma_listen_on_all() desenrolle atómicamente su acción bajo el bloqueo durante el error.
  • Vulnerabilidad en kernel de Linux (CVE-2021-47393)
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (mlxreg-fan) Devuelve un valor distinto de cero cuando el estado actual del ventilador se aplica desde sysfs. La velocidad mínima del ventilador se puede aplicar desde sysfs. Por ejemplo, configurar la velocidad actual del ventilador en 20 se utiliza para hacer que la velocidad del ventilador esté al 100 %, 19, para que no esté por debajo del 90 %, etcétera. Esta característica brinda la capacidad de limitar la velocidad del ventilador de acuerdo con algunas consideraciones del sistema, como la ausencia de algunas unidades reemplazables o la alta temperatura ambiente del sistema. La solicitud para cambiar la velocidad mínima del ventilador es una solicitud de configuración y solo se puede configurar mediante el procedimiento de escritura 'sysfs'. En esta situación, el valor del argumento "estado" está por encima de la velocidad máxima nominal del ventilador. En este caso, devuelva un código distinto de cero para evitar la llamada a Thermal_cooling_device_stats_update(), porque en este caso la actualización de estadísticas viola el rango de la tabla de estadísticas térmicas. Los problemas se observan en caso de que el kernel esté configurado con la opción CONFIG_THERMAL_STATISTICS. Aquí está el rastro de KASAN: [159.506659] ERROR: KASAN: slab fuera de los límites en Thermal_cooling_device_stats_update+0x7d/0xb0 [159.516016] Lectura de tamaño 4 en la dirección ffff888116163840 mediante la tarea hw-management.s/7444 [ 625] Llamada Seguimiento: [159.548366] dump_stack+0x92/0xc1 [159.552084]? Thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] Thermal_zone_device_update+0x345/0x780 [ 159.688711] Thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f /0x590 [mlxsw_core] [159.700972]? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.07423 9] Código: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 00000000000000013 RSI: 0000000001906008 RDI: 000000000000 0001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 000000246 R12: 00000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Asignado por tarea 2924: [ 160.149242] x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] Thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160. 248140] [160.249807] La dirección con errores pertenece al objeto en ffff888116163400 [160.249807] que pertenece al caché kmalloc-1k de tamaño 1024 [ 160.263814] La dirección con errores se encuentra 64 bytes a la derecha de [ 160.263814] Región de 1024 bytes [ffff888116163400, ffff888116163800) [ 160.277536] La dirección con errores pertenece a la página: [ 160.2 82898] página:0000000012275840 refcount :1 mapcount:0 mapeo:0000000000000000 índice:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 orden:3 compuesto_mapcount:0 compuesto_pincount:0 [ 160.303251] banderas: 00000010200(slab|cabeza|nodo=0|zona=2) [ 160.309694 ] sin formato: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] sin formato: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [160.327033] página volcada porque: kasan: mal acceso detectado [160.333270] [160.334937] Estado de la memoria alrededor de la dirección con errores: [160.356469] >ffff888116163800: fc ..
  • Vulnerabilidad en kernel de Linux (CVE-2021-47458)
    Severidad: ALTA
    Fecha de publicación: 22/05/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: el montaje falla con desbordamiento del búfer en strlen. A partir del kernel 5.11 compilado con CONFIG_FORTIFY_SOURCE, la conexión de un sistema de archivos ocfs2 con una pila de clúster o2cb o pcmk falla con el siguiente seguimiento. El problema parece ser que no se garantiza que las cadenas para la pila del clúster y el nombre del clúster tengan terminación nula en la representación del disco, mientras que strlcpy supone que la cadena de origen siempre termina en nulo. Esto provoca una lectura fuera de la cadena de origen que activa la detección de desbordamiento del búfer. se detectó desbordamiento del búfer en strlen ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/string.c:1149! código de operación no válido: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 No contaminado 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11... Seguimiento de llamadas: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 Legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entrada_SYSCALL_64_after_hwframe+0x44/0xae
  • Vulnerabilidad en kernel de Linux (CVE-2024-56552)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc_submit: corrige la ejecución alrededor de suspend_pending Actualmente en algunos casos de prueba podemos activar: xe 0000:03:00.0: [drm] ¡La afirmación `exec_queue_destroyed(q)` falló! .... ADVERTENCIA: CPU: 18 PID: 2640 en drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Estado de motor inesperado 0x00a1, guc_id=57 Si observamos un fragmento de ftrace correspondiente a este id de GuC, podemos ver: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, código de operación=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 Parece que intentamos suspender la cola (opcode=3), configurando suspend_pending y activando un disable_scheduling. Luego, el usuario cierra la cola. Sin embargo, el cierre también señalará con fuerza la valla de suspensión después de matar la cola, más tarde, cuando la respuesta G2H para deshabilitar_programación regrese, ahora hemos borrado suspend_pending al señalar la valla de suspensión, por lo que deshabilitar_programación ahora intenta incorrectamente también anular el registro de la cola. Esto genera advertencias ya que la cola aún no se ha marcado para su destrucción. También parece que desencadenamos errores más tarde al intentar anular el registro dos veces de la misma cola. Para solucionar esto, modifique el orden al gestionar la respuesta para garantizar que no compitamos con un deshabilitar_programación que en realidad no tenía la intención de realizar una anulación del registro. La ruta de destrucción ahora también debería esperar correctamente cualquier pendiente_deshabilitar antes de marcar como destruida. (seleccionado de el commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
  • Vulnerabilidad en kernel de Linux (CVE-2024-56559)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: combina todas las operaciones de vaciado de TLB de la dirección virtual de sombra de KASAN en una sola operación. Al compilar la fuente del kernel 'make -j $(nproc)' con el kernel habilitado para KASAN en funcionamiento en una máquina de 256 núcleos, se muestra el siguiente bloqueo suave: watchdog: BUG: soft lockup - ¡CPU n.º 28 atascada durante 22 s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: cargado No contaminado 6.10.0-rc5 #95 Cola de trabajo: eventos drain_vmap_area_work RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0 Código: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Rastreo de llamadas: ? watchdog_timer_fn+0x2cd/0x390 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x300/0x6d0 ? sched_clock_cpu+0x69/0x4e0 ? __pfx___hrtimer_run_queues+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? ktime_get_update_offsets_now+0x7f/0x2a0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? hrtimer_interrupt+0x2ca/0x760 ? __sysvec_apic_timer_interrupt+0x8c/0x2b0 ? sysvec_apic_timer_interrupt+0x6a/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? smp_call_function_many_cond+0x1d8/0xbb0 ? __pfx_do_kernel_range_flush+0x10/0x10 en_cada_máscara_de_cond_de_cpu+0x20/0x40 flush_tlb_kernel_range+0x19b/0x250 ? srso_return_thunk+0x5/0x5f ? kasan_release_vmalloc+0xa7/0xc0 purga_vmap_node+0x357/0x820 ? __pfx_purge_vmap_node+0x10/0x10 __purge_vmap_area_lazy+0x5b8/0xa10 drenaje_vmap_area_work+0x21/0x30 proceso_uno_work+0x661/0x10b0 subproceso_trabajador+0x844/0x10e0 ? srso_return_thunk+0x5/0x5f ? __kthread_parkme+0x82/0x140 ? __pfx_worker_thread+0x10/0x10 kthread+0x2a5/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Análisis de depuración: 1. El siguiente registro de ftrace muestra que la CPU de bloqueo pasa demasiado tiempo iterando vmap_nodes y vaciando TLB al purgar estructuras vm_area. (Parte de la información está recortada). kworker: funcgraph_entry: | drain_vmap_area_work() { kworker: funcgraph_entry: | mutex_lock() { kworker: funcgraph_entry: 1.092 us | __cond_resched(); kworker: funcgraph_exit: 3.306 us | } ... ... kworker: funcgraph_entry: | flush_tlb_kernel_range() { ... ... kworker: funcgraph_exit: # 7533.649 us | } ... ... kworker: funcgraph_entry: 2.344 us | mutex_unlock(); kworker: funcgraph_exit: $ 23871554 us | } La función drain_vmap_area_work() tarda más de 23 segundos. Hay 2805 llamadas a flush_tlb_kernel_range() en el registro de ftrace. * Una se llama en __purge_vmap_area_lazy(). * Las demás se llaman mediante purge_vmap_node->kasan_release_vmalloc. purge_vmap_node() libera iterativamente las asignaciones de vmalloc de kasan y vacía la TLB para cada vmap_area. - [Cálculo aproximado] Cada flush_tlb_kernel_range() se ejecuta alrededor de 7,5 ms. -- 2804 * 7,5 ms = 21,03 segundos. -- Por eso se activa un bloqueo suave. 2. Extender el tiempo de bloqueo suave puede solucionar el problema (por ejemplo, # echo ---truncated---
  • Vulnerabilidad en kernel de Linux (CVE-2024-56563)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 23/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: se corrige la pérdida de credenciales en ceph_mds_check_access(). get_current_cred() incrementa el contador de referencia, pero faltaba la llamada put_cred().
  • Vulnerabilidad en Meshtastic (CVE-2025-21608)
    Severidad: MEDIA
    Fecha de publicación: 18/02/2025
    Fecha de última actualización: 23/09/2025
    Meshtastic es una solución de red de malla de código abierto. En las versiones de firmware afectadas los paquetes manipulados sobre MQTT pueden aparecer como DM en el cliente a un nodo a pesar de que no estaban decodificados con PKC. Este problema se ha abordado en la versión 2.5.19 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.
  • Vulnerabilidad en Ppress v.0.0.9 (CVE-2025-25973)
    Severidad: MEDIA
    Fecha de publicación: 20/02/2025
    Fecha de última actualización: 23/09/2025
    Una vulnerabilidad de Cross-Site Scripting Almacenado en la función "recomendaciones relacionadas" en Ppress v.0.0.9 permite a un atacante remoto ejecutar código arbitrario a través de un script manipulado específicamente para los parámetros article.title, article.category y article.tags.
  • Vulnerabilidad en Fanwei e-cology 8.0 (CVE-2025-34038)
    Severidad: ALTA
    Fecha de publicación: 24/06/2025
    Fecha de última actualización: 23/09/2025
    Existe una vulnerabilidad de inyección SQL en Fanwei e-cology 8.0 a través del endpoint getdata.jsp. La aplicación pasa directamente la entrada de usuario no saneada del parámetro sql a una consulta de base de datos dentro del método getSelectAllIds(sql, type), accesible mediante el flujo de trabajo cmd=getSelectAllId en AjaxManager. Esto permite a atacantes no autenticados ejecutar consultas SQL arbitrarias, lo que podría exponer datos confidenciales, como hashes de contraseñas de administrador.
  • Vulnerabilidad en WeiPHP 5.0 (CVE-2025-34045)
    Severidad: ALTA
    Fecha de publicación: 26/06/2025
    Fecha de última actualización: 23/09/2025
    Existe una vulnerabilidad de path traversal en WeiPHP 5.0, un framework de desarrollo de código abierto para la plataforma de cuentas públicas de WeChat de Shenzhen Yuanmengyun Technology Co., Ltd. La falla se produce en el parámetro picUrl del endpoint /public/index.php/material/Material/_download_imgage, donde una validación de entrada insuficiente permite a atacantes remotos no autenticados navegar por directorios mediante solicitudes POST manipuladas. Esto permite la lectura arbitraria de archivos en el servidor, lo que podría exponer información confidencial, como archivos de configuración y código fuente.
  • Vulnerabilidad en WebITR (CVE-2025-9254)
    Severidad: CRÍTICA
    Fecha de publicación: 22/08/2025
    Fecha de última actualización: 23/09/2025
    WebITR desarrollado por Uniong tiene una vulnerabilidad de autenticación faltante, que permite a atacantes remotos no autenticados iniciar sesión en el sistema como usuarios arbitrarios explotando una funcionalidad específica.
  • Vulnerabilidad en WebITR (CVE-2025-9255)
    Severidad: ALTA
    Fecha de publicación: 22/08/2025
    Fecha de última actualización: 23/09/2025
    WebITR desarrollado por Uniong tiene una vulnerabilidad de inyección SQL, que permite a atacantes remotos no autenticados inyectar comandos SQL arbitrarios para leer el contenido de la base de datos.
  • Vulnerabilidad en WebITR (CVE-2025-9256)
    Severidad: ALTA
    Fecha de publicación: 22/08/2025
    Fecha de última actualización: 23/09/2025
    WebITR desarrollado por Uniong tiene una vulnerabilidad de lectura arbitraria de archivos, que permite a atacantes remotos con privilegios regulares explotar Absolute Path Traversal para descargar archivos de sistema arbitrarios.
  • Vulnerabilidad en WebITR (CVE-2025-9257)
    Severidad: ALTA
    Fecha de publicación: 22/08/2025
    Fecha de última actualización: 23/09/2025
    WebITR desarrollado por Uniong tiene una vulnerabilidad de lectura arbitraria de archivos, que permite a atacantes remotos con privilegios regulares explotar Absolute Path Traversal para descargar archivos de sistema arbitrarios.
  • Vulnerabilidad en WebITR (CVE-2025-9258)
    Severidad: ALTA
    Fecha de publicación: 22/08/2025
    Fecha de última actualización: 23/09/2025
    WebITR desarrollado por Uniong tiene una vulnerabilidad de lectura arbitraria de archivos, que permite a atacantes remotos con privilegios regulares explotar Absolute Path Traversal para descargar archivos de sistema arbitrarios.
  • Vulnerabilidad en WebITR (CVE-2025-9259)
    Severidad: ALTA
    Fecha de publicación: 22/08/2025
    Fecha de última actualización: 23/09/2025
    WebITR desarrollado por Uniong tiene una vulnerabilidad de lectura arbitraria de archivos, que permite a atacantes remotos con privilegios regulares explotar Absolute Path Traversal para descargar archivos de sistema arbitrarios.