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 WinFlash (CVE-2023-35841)
Severidad: ALTA
Fecha de publicación: 14/05/2024
Fecha de última actualización: 25/09/2025
IOCTL expuesto con control de acceso insuficiente en el controlador Phoenix WinFlash en Windows permite una escalada de privilegios que permite la modificación del firmware del sistema. Este problema afecta al controlador WinFlash: anterior a 4.5.0.0.
Vulnerabilidad en kernel de Linux (CVE-2023-52660)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: rkisp1: Corrige el manejo de IRQ debido a interrupciones compartidas. El controlador solicita las interrupciones como IRQF_SHARED, por lo que se puede llamar a los controladores de interrupciones en cualquier momento. Si se produce una llamada de este tipo mientras el ISP está apagado, el SoC se bloqueará cuando el controlador intente acceder a los registros del ISP. Esto se puede reproducir incluso sin que la plataforma comparta la línea IRQ: habilite CONFIG_DEBUG_SHIRQ y descargue el controlador, y la placa se bloqueará. Solucione este problema agregando un nuevo campo, 'irqs_enabled', que se utiliza para salir del controlador de interrupciones cuando el ISP no está operativo.
Vulnerabilidad en kernel de Linux (CVE-2023-52671)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrigió bloqueo/desbordamiento insuficiente al realizar la transición a ODM4:1 [Por qué] En algunas circunstancias, deshabilitar un OPTC e intentar reclamar sus OPP para otro OPTC podría causar un bloqueo/desbordamiento insuficiente debido a que los OPP no se desconectan correctamente del OPTC deshabilitado. [Cómo] Asegúrese de que todos los OPP estén desasignados de un OPTC cuando se deshabilite.
Vulnerabilidad en kernel de Linux (CVE-2023-52676)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Proteger los límites de la pila contra el desbordamiento de 32 bits. Este parche promueve que la aritmética en torno a la verificación de los límites de la pila se realice en el dominio de 64 bits, en lugar del actual de 32 bits. La aritmética implica sumar un registro de 64 bits con un desplazamiento int. Se comprobó que el registro estaba por debajo de 1<<29 cuando era variable, pero no cuando estaba arreglado. El desplazamiento proviene de una instrucción (en cuyo caso es de 16 bits), de otro registro (en cuyo caso la persona que llama comprobó que estaba por debajo de 1<<29 [1]) o del tamaño de un argumento para kfunc. (en cuyo caso puede ser un u32 [2]). Entre que el registro se verificaba de manera inconsistente para que estuviera por debajo de 1<<29 y el desplazamiento era de hasta u32, parece que estábamos abiertos a desbordar los "int" que se usaban actualmente para la aritmética. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e 50f6cd80eb10235fe3e9/núcleo /bpf/verifier.c#L11904
Vulnerabilidad en kernel de Linux (CVE-2023-52677)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: compruebe si el código a parchear se encuentra en la sección de salida. De lo contrario, caeremos en vmalloc_to_page(), lo que entra en pánico ya que la dirección no se encuentra en la región vmalloc.
Vulnerabilidad en kernel de Linux (CVE-2023-52678)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: confirme que la lista no esté vacía antes de utilizar list_first_entry en kfd_topology.c Antes de usar list_first_entry, asegúrese de verificar que la lista no esté vacía; si la lista está vacía, devuelva -ENODATA . Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() advertencia: can 'gpu_link' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() advertencia: can 'iolink1' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() advertencia: can 'iolink2' even be NULL?
Vulnerabilidad en kernel de Linux (CVE-2023-52680)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: scarlett2: Agregar comprobaciones de errores faltantes a *_ctl_get() Las funciones *_ctl_get() que llaman a scarlett2_update_*() no estaban comprobando el valor de retorno. Corrija para verificar el valor de retorno y pasarlo a la persona que llama.
Vulnerabilidad en kernel de Linux (CVE-2023-52681)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efivarfs: Liberar s_fs_info al desmontar Ahora que asignamos una estructura s_fs_info en la creación del contexto fs, debemos asegurarnos de liberarla nuevamente cuando el superbloque desaparezca.
Vulnerabilidad en kernel de Linux (CVE-2023-52687)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: safexcel - Añadir manejo de errores para llamadas a dma_map_sg() La macro dma_map_sg() puede devolver 0 en caso de error. Este parche permite realizar comprobaciones en caso de fallo de la macro y garantiza la eliminación de la asignación de búferes previamente asignados con dma_unmap_sg(). Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático SVACE.
Vulnerabilidad en kernel de Linux (CVE-2023-52689)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: scarlett2: agrega un bloqueo mutex faltante alrededor de los niveles de obtención de medidores. Como scarlett2_meter_ctl_get() usa meter_level_map[], el data_mutex debe estar bloqueado al acceder a él.
Vulnerabilidad en kernel de Linux (CVE-2023-52692)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ALSA: scarlett2: Añadida verificación de error faltante a scarlett2_usb_set_config() scarlett2_usb_set_config() llama a scarlett2_usb_get() pero no verifica el resultado. Devuelve el error si fallo en lugar de continuar con un valor no válido.
Vulnerabilidad en kernel de Linux (CVE-2023-52697)
Severidad: ALTA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: sof_sdw_rt_sdca_jack_common: ctx->headset_codec_dev = NULL sof_sdw_rt_sdca_jack_exit() son usados por diferentes códecs, y algunos de ellos usan el mismo nombre dai. Por ejemplo, rt712 y rt713 usan "rt712-sdca-aif1" y sof_sdw_rt_sdca_jack_exit(). Como resultado, mc_dailink_exit_loop() llamará dos veces a sof_sdw_rt_sdca_jack_exit(). Establecer ctx->headset_codec_dev = NULL; después de put_device(ctx->headset_codec_dev); para evitar que ctx->headset_codec_dev se coloque dos veces.
Vulnerabilidad en kernel de Linux (CVE-2021-47414)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: vaciar el icache de la CPU actual antes que otras CPU. En SiFive Unmatched, recientemente encontré el siguiente BUGal arrancar: [0.000000] ftrace: asignar 36610 entradas en 144 páginas [0.000000] Ups - instrucción ilegal [#1] [ 0.000000] Módulos vinculados en: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Nombre del hardware: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc: riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0 .000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 00000000000000004 t2 : 00000000000000000 s0: ffffffff81803e60 [0.000000] s1: 0000000000000000 a0: ffffffff81a22238 a1: ffffffff81803e10 [0.000000] a2: 000000000000000 a3: 0000000 000000000 a4: 0000000000000000 [0.000000] a5: 0000000000000000 a6: ffffffff8000989c a7: 0000000052464e43 [0.000000] s2: ffffffff81a220c8 s3: 0000000000000000 s4: 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [0.000000] s11: 0000000000000004 t3: 0000000000000001 t4: 0000000000000008 [0.000000] t5: ffcf04000808 t6: ffffffe3ffddf188 [0.000000] estado : 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000002 [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [] Flush_icache_all+0x12/0x1a [ 0.000000] [] patch_text_nosync+0x26/0x32 [ 0.000000] [] ftrace_init_nop+0x52/0x8c [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/ 0x360 [ 0.000000] [] ftrace_init+ 0x80/0x130 [ 0.000000] [] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Pánico en el kernel - no se sincroniza: ¡Intentó finalizar la tarea inactiva! [0.000000] ---[ fin del pánico del kernel: no se sincroniza: ¡se intentó finalizar la tarea inactiva! ]--- Mientras ftrace recorre una lista de direcciones para parchear, siempre fallaba al parchear la misma función: riscv_cpuid_to_hartid_mask. Al observar el seguimiento, la instrucción ilegal se encuentra en esta misma función. Sin embargo, patch_text_nosync, después de parchear las instrucciones, llama a flush_icache_range. Pero observando lo que sucede en esta función: Flush_icache_range -> Flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask El icache y el dcache de la CPU actual nunca se sincronizan entre el parche de riscv_cpuid_to_hartid_mask y la llamada a esta misma función. Así que solucione este problema limpiando el icache de la CPU actual antes de pedirle a las otras CPU que hagan lo mismo.
Vulnerabilidad en kernel de Linux (CVE-2021-47419)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_taprio: cancelar correctamente el temporizador de taprio_destroy(). Hay un comentario en qdisc_create() acerca de que no llamamos a ops->reset() en algunos casos. err_out4: /* * ¿Alguna qdisc rota que requiera un ops->reset() aquí? * La qdisc nunca estuvo en acción por lo que no debería ser necesaria. */ Como taprio establece un temporizador antes de recibir un paquete, debemos cancelarlo desde ops->destroy, en caso de que no se haya llamado a ops->reset. syzbot informó: ODEBUG: libre activo (estado activo 0) tipo de objeto: hrtimer sugerencia: advanced_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22 ADVERTENCIA: CPU: 0 PID: 8441 en lib/debugobjects.c :505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Módulos vinculados en: CPU: 0 PID: 8441 Comm: syz-executor813 No contaminado 5.14.0-rc6-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 01/01/2011 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Código: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 <0f> 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP 0018:ffff c9000130f330 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 00000000000000003 RCX: 0000000000000000 RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d25ee R11: 00000000000000000 R12: ffffffff898dd020 R13: 3ce20 R14: ffffffff81653630 R15: dffffc0000000000 FS: 0000000000f0d300( 0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffb64b3e000 CR3: 557000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 7: 0000000000000400 Seguimiento de llamadas: __debug_check_no_obj_freed lib/debugobjects.c:987 [en línea] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018 slab_free_hook mm/slub.c:1603 [en línea] slab_free_freelist_hook+0x171/0x240 mm/ slub.c:1653 slab_libre mm/slub.c:3213 [en línea] kfree+0xe4/0x540 mm/slub.c:4267 qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299 tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x413/0xb80 nore/rtnetlink.c: 5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c: 2504 netlink_unicast_kernel net/netlink/af_netlink.c: 1314 [netlin /0x7d0 net/netlink/ af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net /zócalo .c:2403 ___sys_sendmsg+0xf3/0x170 net/socket.c:2457 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] arco/ x86/entrada/common.c:80
Vulnerabilidad en kernel de Linux (CVE-2021-47421)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: maneja el caso de pci_channel_io_frozen solo en amdgpu_pci_resume. En el código actual, cuando se detecta un estado de error de PCI pci_channel_io_normal, informará el estado de PCI_ERS_RESULT_CAN_RECOVER al controlador PCI, y el controlador PCI continúe la ejecución de PCI resume callback report_resume mediante pci_walk_bridge, y la devolución de llamada finalmente irá a amdgpu_pci_resume, donde el bloqueo de escritura se libera incondicionalmente sin adquirir dicho bloqueo primero. En este caso, se producirá un punto muerto cuando otros subprocesos comiencen a adquirir el bloqueo de lectura. Para solucionar este problema, agregue un miembro en la estructura amdgpu_device para almacenar en caché pci_channel_state y solo continúe la ejecución en amdgpu_pci_resume cuando sea pci_channel_io_frozen.
Vulnerabilidad en kernel de Linux (CVE-2023-52701)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: use un búfer de rebote para copiar skb->mark syzbot encontró que las compilaciones arm64 fallarían en sock_recv_mark() cuando CONFIG_HARDENED_USERCOPY=y x86 y powerpc no detectan el problema porque definen user_access_begin . Esto se manejará en un parche diferente, porque falta check_object_size(). Solo los datos de skb->cb[] se pueden copiar directamente hacia/desde el espacio de usuario, como se explica en la confirmación 79a8a642bf05 ("net: Lista blanca del campo skbuff_head_cache "cb") El informe de syzbot fue: copia de usuario: intento de exposición de la memoria del kernel detectado desde SLUB objeto 'skbuff_head_cache' (desplazamiento 168, tamaño 4)! ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/usercopy.c:102! Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 4410 Comm: syz-executor533 No contaminado 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 21/01/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: usercopy_abort+0x90/0x94 mm/usercopy.c:90 lr: usercopy_abort+0x90/0x94 mm/usercopy.c:90 sp: ffff80000fb9b9a0 x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00 x26: 0000000000000014 5: ffff80000cf52000 x24: ffffc0000000000 x23: 05ffc00000000200 x22: ffffc000324bf80 x21: ffff0000c92fe1a8 x20: 0000000000000001 x19: 00000004 x18: 0000000000000000 x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118 x14: ffff0000c6073400 x13: 00000000ffffffff x12: 073400 x11: ff808000081bbb4c x10: 0000000000000000 x9: 7b0572d7cc0ccf00 x8: 7b0572d7cc0ccf00 x7: ffff80000bf650d4 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: 0000000000000000 x2: ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c Rastreo de llamadas: usercopy_abort+0x90/0x94 mm/usercopy.c:90 __check_heap_object+0xa8/0x100 mm/slub.c:4761 check_heap_object mm/usercopy.c:196 __check_object _tamaño+0x208/0x6b8 mm/ usercopy.c:251 check_object_size include/linux/thread_info.h:199 [en línea] __copy_to_user include/linux/uaccess.h:115 [en línea] put_cmsg+0x408/0x464 net/core/scm.c:238 sock_recv_mark net/socket. c:975 [en línea] __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984 sock_recv_cmsgs include/net/sock.h:2728 [en línea] paquete_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482 ____sys_recvmsg+0x1 10/0x3a0 ___sys_recvmsg net/socket.c:2737 [en línea] __sys_recvmsg+0x194/0x210 net/socket.c:2767 __do_sys_recvmsg net/socket.c:2777 [en línea] __se_sys_recvmsg net/socket.c:2774 [en línea] 64_sys_recvmsg+0x2c/0x3c net/socket.c:2774 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52 el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall .c:142 do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry -common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Código: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)
Vulnerabilidad en kernel de Linux (CVE-2023-52704)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL .Tetsuo-San notó que la confirmación f5d39b020809 ("freezer,sched: Rewrite core freezer logic") rompió call_usermodehelper_exec() para el caso KILLABLE. Específicamente, se pasó por alto que el segundo wait_for_completion() incondicional no era opcional y garantiza que la finalización en la pila no se utilice antes de salir del alcance.
Vulnerabilidad en kernel de Linux (CVE-2023-52732)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: lista de bloqueo del kclient cuando se recibe un seguimiento instantáneo corrupto. Cuando recibimos un seguimiento instantáneo corrupto, no sabemos qué ha sucedido exactamente en el lado MDS. Y no debemos continuar con el acceso de IO y metadatos a MDS, lo que puede dañar u obtener contenidos incorrectos. Este parche simplemente bloqueará todas las solicitudes IO/MDS adicionales inmediatamente y luego expulsará al propio kclient. La razón por la que todavía necesitamos desalojar al kclient justo después de bloquear todas las IO adicionales es que el MDS podría revocar los límites más rápido.
Vulnerabilidad en kernel de Linux (CVE-2023-52742)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: USB: corrija la dirección incorrecta ADVERTENCIA en plusb.c. El syzbot fuzzer detectó un error en el controlador de red plusb: una transferencia de control de salida de longitud cero se trató como una lectura en lugar de escribir. En los kernels modernos, este error provoca una ADVERTENCIA: usb 1-1: directorio de control BOGUS, la tubería 80000280 no coincide con bRequestType c0 ADVERTENCIA: CPU: 0 PID: 4645 en drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/ 0x1880 drivers/usb/core/urb.c:411 Módulos vinculados en: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 12/01/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411... Seguimiento de llamadas: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message .c:58 controladores usb_internal_control_msg/usb/core/message.c:102 [en línea] usb_control_msg+0x320/0x4a0 controladores/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 controladores/net/usb/usbnet.c: 2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [en línea] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [en línea] pl_reset+0x2f /0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/ core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl +0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl. c:856 [en línea] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_h marco w +0x63/0xcd La solución es llamar a usbnet_write_cmd() en lugar de usbnet_read_cmd() y eliminar el indicador USB_DIR_IN.
Vulnerabilidad en kernel de Linux (CVE-2023-52743)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: no utilice el indicador WQ_MEM_RECLAIM para la cola de trabajo. Cuando se cargan ice y el controlador irdma, se activa una advertencia en check_flush_dependency. Esto se debe a que la cola de trabajo del controlador de hielo está asignada con el indicador WQ_MEM_RECLAIM y el de irdma no. Según la documentación del kernel, este indicador debe establecerse si la cola de trabajo participará en el flujo de recuperación de memoria del kernel. Como no es así, no es necesario que el WQ del conductor de hielo tenga esta bandera configurada, así que elimínela. Seguimiento de ejemplo: [+0.000004] cola de trabajo: WQ_MEM_RECLAIM ice:ice_service_task [ice] se está vaciando! WQ_MEM_RECLAIM infiniband:0x0 [+0.000139] ADVERTENCIA: CPU: 0 PID: 728 en kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0 [ + 0.000011] Módulos vinculados en: vinculación tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc fkill vfat fat intel_rapl_msr intel _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc ucm ib_srpt ib_isert iscsi_target_mod target_ core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [+0.000161] [última descarga: unión] [+0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Contaminado: GS 6.2.0-rc2_next-queue-13jan-0045 8- gc20aabd57164 #1 [ +0.000006] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 06/01/2020 [ +0.000003] Cola de trabajo: ice ice_service_task [ice] [ +0.00 0127] RIP: 0010:check_flush_dependency+ 0x178/0x1a0 [ +0.000005] Código: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08 9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06 [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282 [ +0.000005] RAX: 000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000 [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80 [ +0.000003] RBP: ffff888194bf3400 R08: fffffed117b306112 R09: 306112 [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000 [ +0.000003] R13: ffff888111f84d00 R14: 15 : ffff888194bf3400 [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:00000000000000000 [ +0.000003] CS: 0010 DS: 0000 0000 CR0: 0000000080050033 [+0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0 [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000003] DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000002] PKRU: 55555554 [ +0.000003] Seguimiento de llamadas: [ +0.000002] [ +0.000003 ] __flush_workqueue+0x203/0x840 [ +0.000006] ? mutex_unlock+0x84/0xd0 [+0.000008]? __pfx_mutex_unlock+0x10/0x10 [+0.000004]? __pfx___flush_workqueue+0x10/0x10 [+0.000006]? mutex_lock+0xa3/0xf0 [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core] [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core] [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core] [ + 0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma] [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma] [ +0.000059] ? up_write+0x5c/0x90 [ +0.000005] irdma_remove+0x36/0x90 [irdma] [ +0.000062] auxiliar_bus_remove+0x32/0x50 [ +0.000007] dispositivo_r ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2023-52750)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: restringe CPU_BIG_ENDIAN a GNU como o LLVM IAS 15.x o posterior. Antes de LLVM 15.0.0, el ensamblador integrado de LLVM intercambiaba bytes incorrectamente con NOP al compilar para big-endian. y la serie de bytes resultante coincidió con la codificación de FNMADD S21, S30, S0, S0. Esto pasó desapercibido hasta la confirmación: 34f66c4c4d5518c1 ("arm64: use un cpucap positivo para FP/SIMD") Antes de esa confirmación, el kernel siempre habilitaba el uso de FPSIMD al principio del arranque cuando __cpu_setup() inicializaba CPACR_EL1, y por lo tanto el uso de FNMADD dentro del kernel no se detectó, pero podría provocar la corrupción del estado FPSIMD del usuario o del kernel. Después de esa confirmación, las instrucciones se bloquean durante el arranque antes de que se detecte y habilite FPSIMD, por ejemplo | Excepción de sincronización el1h de 64 bits no controlada en CPU0, ESR 0x000000001fe00000 - ASIMD | CPU: 0 PID: 0 Comunicaciones: intercambiador No contaminado 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Nombre del hardware: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | ordenador personal: __pi_strcmp+0x1c/0x150 | lr: poblar_properties+0xe4/0x254 | sp: ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: ffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: ffffbfffddfe054 x24: 0000000000000008 | x23: ffffbffffddfe000 x22: ffffbfffddfe000 x21: ffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9: 0000000000000000 | x8: 0101010101010101 x7: ffffffffffffffc0 x6: 0000000000000000 | x5: 0000000000000000 x4: 0101010101010101 x3: 000000000000002a | x2: 0000000000000001 x1: ffffd014171f2988 x0: ffffbfffddffcb8 | Pánico del kernel: no se sincroniza: excepción no controlada | CPU: 0 PID: 0 Comunicaciones: intercambiador No contaminado 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Nombre del hardware: linux,dummy-virt (DT) | Rastreo de llamadas: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | pánico+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4 Restrinja CONFIG_CPU_BIG_ENDIAN a un buen ensamblador conocido, que sea GNU o LLVM's IAS 15.0.0 y posteriores, que contiene la confirmación vinculada.
Vulnerabilidad en kernel de Linux (CVE-2023-52778)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: trata con un tamaño GSO grande. Después del compromiso culpable a continuación, los sockets TCP (y los subflujos MPTCP) pueden generar paquetes de salida de más de 64 KB. Eso excede el tamaño máximo de datos DSS, la longitud se tergiversa en el cable y la transmisión se corrompe, como se observó más tarde en el receptor: ADVERTENCIA: CPU: 0 PID: 9696 en net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/ 0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 No contaminado 6.6.0-rc5-gcd8bdf563d46 #45 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01 /2014 netlink: 8 bytes sobrantes después de analizar los atributos en el proceso `syz-executor.4'. RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45 d870 RCX: ffff888102ad0000 netlink: 8 bytes sobrantes después de analizar los atributos en el proceso `syz-executor. 4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10: 0000000000 R11: fffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47 e700(0000) GS:ffff88811b200000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Llamar Seguimiento: mptcp_data_ready +0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_establecido+0x950/0x1d 90 netos/ipv4/ tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1 ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5 /0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304 __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 Process_backlog+0x353/0x660 net/core/dev. c:5974 __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603 __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/ softirq.c:454 Aborde el problema limitando explícitamente el tamaño máximo de GSO a lo que MPTCP realmente permite.
Vulnerabilidad en kernel de Linux (CVE-2023-52781)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: config: soluciona el problema de iteración en 'usb_get_bos_descriptor()'. El descriptor BOS define un descriptor raíz y es el descriptor base para acceder a una familia de descriptores relacionados. La función 'usb_get_bos_descriptor()' encuentra un problema de iteración al omitir el tipo de descriptor 'USB_DT_DEVICE_CAPABILITY'. Esto da como resultado que el mismo descriptor se lea repetidamente. Para solucionar este problema, se introduce una declaración 'goto' para garantizar que el puntero y la cantidad leída se actualicen correctamente. Esto garantiza que la función pase al siguiente descriptor en lugar de leer el mismo descriptor repetidamente.
Vulnerabilidad en kernel de Linux (CVE-2023-52784)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: detener el dispositivo en bond_setup_by_slave(). El compromiso 9eed321cde22 ("net: lapbether: solo admite dispositivos ethernet") ha podido mantener a syzbot alejado de net/lapb, hasta hoy. En el siguiente símbolo [1], el problema es que se ha creado un dispositivo lapbether sobre un dispositivo de unión sin miembros. Luego, agregar un miembro que no sea ARPHRD_ETHER obligó al maestro de vinculación a cambiar su tipo. La solución es asegurarnos de llamar a dev_close() en bond_setup_by_slave() para que se eliminen los posibles dispositivos lapbether vinculados (o cualquier otro dispositivo que tenga suposiciones sobre el dispositivo físico). Se solucionó un error similar en la confirmación 40baec225765 ("vinculación: corregir el pánico en caso de falla de esclavitud no ARPHRD_ETHER") [1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end: 0x140 dev:bond0 ERROR del kernel en net/core/skbuff.c:192! Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6007 Comm: syz-executor383 No contaminado 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Nombre de hardware: Google Google Compute Engine/ Google Compute Engine, BIOS Google 04/08/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:188 [en línea] pc: skb_under_panic +0x13c/0x140 net/core/skbuff.c:202 lr: skb_panic net/core/skbuff.c:188 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp: ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 0000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008 a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 000000000000000 x9: cb50b496c519aa00 x8: cb50b496c519aa00 x7: 0000000000000001 x6: 00000000000001 x5: ffff800096a063b8 x4: ffff80008e280f80 x3: ffff8000805ad11c x2: 0000000000000001 x1: 0000000100000201 x0: 00000000000000 086 Rastreo de llamadas: skb_panic net/core/skbuff.c:188 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/ netdevice.h:3136 [en línea] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c :149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0 núcleo x1a4/0x510 /notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [en línea] call_netdevice_notifiers_extack net/core/dev.c:2008 [en línea] call_netdevice_notifiers net/core/dev .c:2022 [en línea] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event +0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [ en línea] call_netdevice_notifiers_extack net/core/dev.c:2008 [en línea] call_netdevice_notifiers net/core/dev.c:2022 [en línea] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core /dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c :4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2023-52786)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige la verificación de datos en línea de racy may en dio write syzbot informa que la siguiente advertencia de ext4_iomap_begin() se activa a partir de la confirmación a la que se hace referencia a continuación: if (WARN_ON_ONCE(ext4_has_inline_data(inode)) ) devolver -ERANGE; Esto ocurre durante una escritura dio, que nunca se espera que encuentre un inodo con datos en línea. Para imponer este comportamiento, ext4_dio_write_iter() verifica el estado en línea actual del inodo y borra el indicador de estado MAY_INLINE_DATA para volver a las escrituras almacenadas en el búfer o imponer que otros escritores en progreso en el inodo no puedan crear datos en línea. El problema es que la verificación de datos en línea existentes y la bandera de estado puede abarcar un ciclo de bloqueo. Por ejemplo, si el ilock originalmente estaba bloqueado como compartido y posteriormente actualizado a exclusivo, es posible que otro escritor haya vuelto a adquirir el bloqueo y haya creado datos en línea antes de que la tarea de escritura dio adquiera el bloqueo y continúe. El compromiso al que se hace referencia a continuación afloja los requisitos de bloqueo para permitir que se produzcan algunas formas de escrituras de dio no alineadas bajo un bloqueo compartido, pero AFAICT, la verificación de datos en línea técnicamente ya era picante para cualquier escritura de dio que hubiera involucrado un ciclo de bloqueo. De todos modos, limpie el bit de estado en la misma sección crítica de bloqueo que verifica si hay datos en línea preexistentes en el inodo para cerrar la ejecución.
Vulnerabilidad en kernel de Linux (CVE-2024-40998)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ext4: arreglar ratelimit_state no inicializado->bloquear acceso en __ext4_fill_super() En la siguiente concurrencia accederemos al rs->lock no inicializado: ext4_fill_super ext4_register_sysfs // sysfs registrado msg_ratelimit_interval_ms // Otros procesos modificar rs->interval a // distinto de cero a través de msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errores en el sistema de archivos, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // hacer nada si el intervalo es 0 devuelve 1; ->s_msg_ratelimit_state , 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // inicia rs->lock aquí y obtiene el siguiente dump_stack: ==================== ===================================== INFORMACIÓN: intentando registrar una clave no estática. El código está bien pero necesita una anotación de bloqueo, ¿o tal vez no inicializó este objeto antes de usarlo? apagando el validador de corrección de bloqueo. CPU: 12 PID: 753 Comunicaciones: montaje contaminado: GE 6.7.0-rc6-next-20231222 #504 [...] Seguimiento de llamadas: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 Register_lock_class+0x740/0x7c0 __lock_acquire+0x69/ 0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] 0x2b10 [ext4] text4_fill_super+0x14d/0x360 [ext4] [. ..] ================================================= ========== Normalmente el intervalo es 0 hasta que se inicializa s_msg_ratelimit_state, por lo que ___ratelimit() no hace nada. Pero el registro de sysfs precede a la inicialización de rs->lock, por lo que es posible cambiar rs->interval a un valor distinto de cero a través de la interfaz msg_ratelimit_interval_ms de sysfs mientras rs->lock no está inicializado, y luego una llamada a ext4_msg desencadena el problema al accediendo a un rs->lock no inicializado. Por lo tanto, registre sysfs después de que se completen todas las inicializaciones para evitar este tipo de problemas.
Vulnerabilidad en kernel de Linux (CVE-2024-41003)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: bpf: Fix reg_set_min_max corrupción de fake_reg Juan informó que después de hacer algunos cambios al buzzer [0] e implementar una nueva estrategia de fuzzing guiada por cobertura, notaron lo siguiente en una de las sondas : [...] 13: (79) r6 = *(u64 *)(r0 +0) ; R0=map_value(ks=4,vs=8) R6_w=escalar() 14: (b7) r0 = 0 ; R0_w=0 15: (b4) w0 = -1 ; R0_w=0xffffffff 16: (74) w0 >>= 1 ; R0_w=0x7ffffffff 17: (5c) w6 &= w0 ; R0_w=0x7fffffff R6_w=escalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff)) 18: (44) w6 |= 2 ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd)) 19: (56) if w6 != 0x7ffffffd goto pc+1 VIOLACIÓN DE INVARIANTES REG (true_reg2) : violación de límites de rango u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0) INVARIANTES DEL REG (false_reg1): violación de los límites de rango u64 =[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0) VIOLACIÓN DE INVARIANTES REG (false_reg2): st tnum no está sincronizado con los límites de rango u64 =[0x0, 0xffffffffffffffff] s64=[0x80000000000000000, 0x7ffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7ffffff] var_off=(0x7ffffffff, 0x0) 19: 6_w=0x7fffffff 20: (95) salida del 19 al 21: R0=0x7fffffff R6=escalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx () R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 21: R0=0x7fffffff R6=escalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32 =0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 21: (14) w6 -= 2147483632; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd)) 22: (76) si w6 s>= 0xe goto pc+1; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd)) 23: (95) salida de 22 a 24: R0=0x7fffffff R6_w= 14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 24: R0=0x7ffffffff R6_w=14 R7= map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 24: (14) w6 -= 14 ; R6_w=0 [...] Lo que se puede ver aquí es una violación de invariante de registro en la línea 19. Después del binario o en la línea 18, el verificador sabe que el bit 2 está establecido pero no sabe nada sobre el resto del contenido que fue cargado desde un valor de mapa, es decir, el rango es [2,0x7fffffff] con var_off=(0x2; 0x7ffffffd). Cuando en la línea 19 el verificador analiza la rama, divide los estados de registro en reg_set_min_max() en los registros de la rama verdadera (true_reg1, true_reg2) y los registros de la rama falsa (false_reg1, false_reg2). Dado que la prueba es w6! = 0x7ffffffd, src_reg es una constante conocida. Internamente, el verificador crea un registro "falso" inicializado como escalar al valor de 0x7ffffffd y luego lo pasa a reg_set_min_max(). Ahora, para la línea 19, es matemáticamente imposible tomar la rama falsa de este programa, sin embargo, el verificador la analiza. Es imposible porque el segundo bit de r6 se establecerá debido a la operación anterior o y la constante en la condición tiene ese bit sin configurar (hex(fd) == binario(1111 1101). Cuando el verificador analiza por primera vez el valor falso/caída -a través de la rama, calculará una intersección entre el var_off de r6 y la constante. Esto se debe a que el verificador crea un registro "falso" inicializado con el valor de la constante. El resultado de la intersección luego refina ambos registros en regs_refine_cond_op(): [...] t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));
Vulnerabilidad en kernel de Linux (CVE-2024-41005)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: netpoll: Corrige condición de ejecución en netpoll_owner_active KCSAN detectó una condición de ejecución en netpoll: ERROR: KCSAN: data-race en net_rx_action / netpoll_send_skb escribe (marcado) en 0xffff8881164168b0 de 4 bytes por interrupción en CPU 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) leído en 0xffff8881164168b0 de 4 bytes por tarea 1 en la CPU 2 : netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) valor cambiado: 0x0000000a -> 0xffffffff Esto sucede porque netpoll_owner_active() necesita verificar si la CPU actual es la propietaria del bloqueo, tocando napi->poll_owner de forma no atómica. El campo ->poll_owner contiene la CPU actual que mantiene el bloqueo. Utilice una lectura atómica para comprobar si el propietario de la encuesta es la CPU actual.
Vulnerabilidad en kernel de Linux (CVE-2022-48807)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ice: Solucionar error KASAN en el controlador LAG NETDEV_UNREGISTER Actualmente, se llama al mismo controlador tanto para una notificación de desvinculación de NETDEV_BONDING_INFO LAG como para una llamada NETDEV_UNREGISTER. Sin embargo, esto está causando un problema, ya que el netdev_notifier_info pasado tiene una estructura diferente según el evento que se pasa. El problema se manifiesta como un seguimiento de llamada de un ERROR: error de pila fuera de los límites de KASAN. Solucione este problema creando un controlador específico para NETDEV_UNREGISTER al que solo se le pasan elementos válidos en la estructura netdev_notifier_info para el evento NETDEV_UNREGISTER. También se incluye la eliminación de un dev_put desequilibrado en peer_netdev y llaves relacionadas.
Vulnerabilidad en kernel de Linux (CVE-2022-48811)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: no liberar napi en __ibmvnic_open() Si __ibmvnic_open() encuentra un error como al configurar el estado del enlace, llama a release_resources() que libera las estructuras de napi innecesariamente. En su lugar, haga que __ibmvnic_open() solo limpie el trabajo que hizo hasta ahora (es decir, deshabilite napi e irqs) y deje el resto a las personas que llaman. Si el llamador de __ibmvnic_open() es ibmvnic_open(), debería liberar los recursos inmediatamente. Si la persona que llama es do_reset() o do_hard_reset(), liberará los recursos en el próximo reinicio. Esto corrige el siguiente fallo que se produjo al ejecutar el comando drmgr varias veces para agregar/eliminar una interfaz vnic: [102056] ibmvnic 30000003 env3: deshabilitar rx_scrq[6] irq [102056] ibmvnic 30000003 env3: deshabilitar rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Se reabastecieron 8 grupos. El kernel intentó leer la página del usuario (10): ¿intento de explotación? (uid: 0) ERROR: Desreferencia del puntero NULL del kernel al leer en 0x00000010 Dirección de instrucción errónea: 0xc000000000a3c840 Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries .. CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: cargado No contaminado 5.16.0-rc5-autotest-g6441998e2e37 #1 Cola de trabajo: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b537. 8 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAMPA : 0300 No contaminado (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 00000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b 5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Seguimiento de llamadas: [c0000000548e3a80] [0000000000000006] 0x6 (no confiable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228 ] proceso_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] hilo_trabajador+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Volcado de instrucciones: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 9e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 f9010020 60420000 e9210020 ---[ final de seguimiento 5f8033b08fd27706 ]---
Vulnerabilidad en kernel de Linux (CVE-2022-48821)
Severidad: ALTA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: evitar doble fput() en copia de usuario fallida. Si la copia al área de usuario falla para FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), no debemos asumir que 'buf->dmabuf' aun es válido. De hecho, dma_buf_fd() llamó a fd_install() antes, es decir, "consumió" una referencia, dejándonos sin ninguna. Por lo tanto, llamar a dma_buf_put() colocará una referencia que ya no poseemos, lo que conducirá a una entrada válida en la tabla de descripción de archivos para un objeto 'archivo' ya publicado que es un use-after-free directo. Simplemente evite llamar a dma_buf_put() y confíe en el código de salida del proceso para realizar la limpieza necesaria, si es necesario, es decir, si el descriptor del archivo aún es válido.
Vulnerabilidad en kernel de Linux (CVE-2022-48823)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qedf: se solucionó el problema de recuento cuando se recibe el logotipo durante TMF. Se observó un seguimiento de llamada de tarea colgada durante el procesamiento del logotipo. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: RESET LUN emitido... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222 [0000] :00:00.0]:[qedf_initiate_tmf:2438 ]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: informe 016900: Solicitud de logotipo recibida mientras estaba en estado Listo [ 974.309627] host1: informe 016900: Eliminar puerto [ 974.309642] host1: Informe 016900: evento de trabajo 3 [ 974.309644] host1: informe 016900: devolución de llamada lld ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport se está cargando, no ejecutando descarga. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: comando de gestión de tarea exitoso... [ 984.031088] INFORMACIÓN: tarea jbd2/dm-15-8:7645 bloqueada durante más de 120 segundos. [ 984.031136] No contaminado 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Seguimiento de llamadas: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [984.031233]? bit_wait_timeout+0x90/0x90 [ 984.031235] programación+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] 80 [984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? terminar_esperar+0x80/0x80 [984.031291]? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 Hubo un problema de recuento de referencias cuando se recibe el logotipo durante TMF. Esto lleva a que una de las E/S se cuelgue con el controlador. Arreglar el recuento de árbitros.
Vulnerabilidad en kernel de Linux (CVE-2022-48827)
Severidad: ALTA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: corrige el comportamiento de READ cerca de OFFSET_MAX Dan Aloni informa: > Debido a El commit 8cfb9015280d ("NFS: siempre proporcione buffers alineados a > las capas de lectura RPC") en el cliente, una lectura de 0xfff está alineada con el tamaño del servidor de 0x1000. > > Como resultado, en una prueba donde el servidor tiene un archivo de tamaño > 0x7ffffffffffffffff, y el cliente intenta leer desde el desplazamiento > 0x7ffffffffffffff000, la lectura causa que loff_t se desborde en el servidor > y devuelve un código NFS de EINVAL a el cliente. Como resultado, el cliente reintenta indefinidamente la solicitud. El cliente NFS de Linux no maneja NFS?ERR_INVAL, aunque todas las especificaciones de NFS permiten a los servidores devolver ese código de estado para una READ. En lugar de NFS?ERR_INVAL, haga que las solicitudes READ fuera de rango se realicen correctamente y devuelvan un resultado breve. Establezca el indicador EOF en el resultado para evitar que el cliente vuelva a intentar la solicitud READ. Este comportamiento parece ser coherente con los servidores Solaris NFS. Tenga en cuenta que NFSv3 y NFSv4 utilizan valores de compensación u64 en el cable. Estos deben convertirse a loff_t internamente antes de su uso; una conversión de tipo implícita no es adecuada para este propósito. De lo contrario, las comprobaciones de VFS con sb->s_maxbytes no funcionan correctamente.
Vulnerabilidad en kernel de Linux (CVE-2022-48828)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFSD: corrija el desbordamiento insuficiente de ia_size iattr::ia_size es un loff_t, que es un tipo de 64 bits firmado. NFSv3 y NFSv4 definen el tamaño del archivo como un tipo de 64 bits sin firmar. Por lo tanto, existe un rango de valores de tamaño de archivo válidos que un cliente NFS puede enviar y que ya es mayor de lo que Linux puede manejar. Actualmente, decode_fattr4() vuelca un valor u64 completo en ia_size. Si ese valor resulta ser mayor que S64_MAX, entonces ia_size tiene un desbordamiento insuficiente. También estoy a punto de arreglar el comportamiento de NFSv3, así que detectemos el desbordamiento en la ruta del código común: nfsd_setattr().
Vulnerabilidad en kernel de Linux (CVE-2022-48830)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: corrige una posible ejecución de recepción de tramas CAN en isotp_rcv() Al recibir una trama CAN, la lógica del código actual no considera la recepción simultánea de procesos que no aparecen en el uso en el mundo real. Ziyang Xuan escribe: El siguiente problema syz es uno de los escenarios. so->rx.len es cambiado por isotp_rcv_ff() durante isotp_rcv_cf(), so->rx.len es igual a 0 antes de alloc_skb() y es igual a 4096 después de alloc_skb(). Eso activará skb_over_panic() en skb_put(). ==================================================== ===== CPU: 1 PID: 19 Comm: ksoftirqd/1 No contaminado 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Seguimiento de llamadas: skb_over_panic net/core/skbuff.c:118 [en línea] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [en línea] isotp_rcv+0xa38/0x1e30 net/ can/isotp.c:668 entregar net/can/af_can.c:574 [en línea] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+ 0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Por lo tanto, nos aseguramos de que los cambios de estado y las estructuras de datos mantenga la coherencia en el momento de recepción de la trama CAN agregando un spin_lock en isotp_rcv(). Esto soluciona el problema informado por syzkaller pero no afecta el funcionamiento en el mundo real.
Vulnerabilidad en kernel de Linux (CVE-2024-41051)
Severidad: ALTA
Fecha de publicación: 29/07/2024
Fecha de última actualización: 25/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: espere a que finalice ondemand_object_worker al soltar el objeto Al poner en cola ondemand_object_worker() para volver a abrir el objeto, cachefiles_object no está fijado. El objeto cachefiles_object se puede liberar cuando la solicitud de lectura pendiente se completa intencionalmente y se desmontan los erofs relacionados. Si ondemand_object_worker() se ejecuta después de liberar el objeto, incurrirá en un problema de use after free como se muestra a continuación. proceso A procesos B proceso C proceso D cachefiles_ondemand_send_req() // envía una solicitud de lectura X // espera a que se complete // cierra ondemand fd cachefiles_ondemand_fd_release() // establece el objeto como CERRAR cachefiles_ondemand_daemon_read() // establece el objeto como REAPERTURA queue_work(fscache_wq , &info->ondemand_work) // cerrar /dev/cachefiles cachefiles_daemon_release cachefiles_flush_reqs complete(&req->done) // leer la solicitud X está completa // desmontar el erofs fs cachefiles_put_object() // el objeto será liberado cachefiles_ondemand_deinit_obj_info() kmem_cache_free(object ) // tanto la información como el objeto se liberan ondemand_object_worker() Cuando se suelta un objeto, ya no es necesario volver a abrirlo, así que use cancel_work_sync() para cancelar o espere a que finalice ondemand_object_worker().
Vulnerabilidad en Intel(R) (CVE-2024-23198)
Severidad: MEDIA
Fecha de publicación: 13/11/2024
Fecha de última actualización: 25/09/2025
La validación de entrada incorrecta en el firmware de algunos productos Intel(R) PROSet/Wireless Software e Intel(R) Killer(TM) Wi-Fi anteriores a la versión 23.40 puede permitir que un usuario no autenticado habilite la denegación de servicio a través del acceso adyacente.
Vulnerabilidad en Mattermost (CVE-2025-20036)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 25/09/2025
Las versiones <=2.22.0 de las aplicaciones móviles de Mattermost no logran validar correctamente las propiedades de las publicaciones, lo que permite que un usuario autenticado malintencionado provoque un bloqueo a través de una publicación maliciosa.
Vulnerabilidad en Mattermost (CVE-2025-21083)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 25/09/2025
Las versiones <=2.22.0 de las aplicaciones móviles de Mattermost no logran validar correctamente las propiedades de las publicaciones, lo que permite que un usuario autenticado malintencionado provoque un bloqueo a través de una publicación maliciosa.
Vulnerabilidad en Mattermost Desktop App (CVE-2025-1398)
Severidad: CRÍTICA
Fecha de publicación: 17/03/2025
Fecha de última actualización: 25/09/2025
Las versiones <=5.10.0 de Mattermost Desktop App declararon explícitamente derechos innecesarios de macOS que permiten a un atacante con acceso remoto eludir la Transparencia, el Consentimiento y el Control (TCC) mediante la inyección de código.
Vulnerabilidad en Mattermost Mobile Apps (CVE-2025-1558)
Severidad: MEDIA
Fecha de publicación: 24/03/2025
Fecha de última actualización: 25/09/2025
Las versiones <=2.25.0 de Mattermost Mobile Apps no validan correctamente las imágenes GIF antes de renderizarlas, lo que permite que un usuario malintencionado provoque el bloqueo de la aplicación de Android a través de un mensaje que contiene un GIF manipulado con fines malintencionados.
Vulnerabilidad en Qualcomm, Inc. (CVE-2025-27042)
Severidad: ALTA
Fecha de publicación: 08/07/2025
Fecha de última actualización: 25/09/2025
Corrupción de memoria al procesar paquetes de video recibidos desde el firmware de video.
Vulnerabilidad en Qualcomm, Inc. (CVE-2025-27057)
Severidad: ALTA
Fecha de publicación: 08/07/2025
Fecha de última actualización: 25/09/2025
DOS transitorio al manejar frames de baliza con una longitud de encabezado de IE no válida.
Vulnerabilidad en Mattermost Confluence (CVE-2025-44001)
Severidad: MEDIA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede verificar el acceso del usuario al canal, lo que permite a los atacantes obtener detalles de suscripción del canal sin el acceso adecuado al canal a través de una llamada API al endpoint Obtener detalles de suscripciones al canal.
Vulnerabilidad en Mattermost Confluence (CVE-2025-44004)
Severidad: ALTA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede verificar la autorización del usuario en la instancia de Mattermost, lo que permite a los atacantes crear una suscripción de canal sin la autorización adecuada a través de una llamada API al endpoint de creación de suscripción de canal.
Vulnerabilidad en Mattermost Confluence (CVE-2025-48731)
Severidad: MEDIA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede verificar el acceso del usuario al espacio Confluence, lo que permite a los atacantes editar una suscripción para un espacio Confluence para el que el usuario no tiene acceso a través del endpoint de edición de suscripción.
Vulnerabilidad en Mattermost Confluence (CVE-2025-52931)
Severidad: ALTA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede manejar un cuerpo de solicitud inesperado, lo que permite a los atacantes bloquear el complemento mediante un impacto constante para actualizar el endpoint de suscripción del canal con un cuerpo de solicitud no válido.
Vulnerabilidad en Mattermost Confluence (CVE-2025-53514)
Severidad: MEDIA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede manejar un cuerpo de solicitud inesperado, lo que permite a los atacantes bloquear el complemento mediante un acceso constante al endpoint del webhook del servidor con un cuerpo de solicitud no válido.
Vulnerabilidad en Mattermost Confluence (CVE-2025-53857)
Severidad: BAJA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede verificar el acceso del usuario al canal, lo que permite a los atacantes obtener detalles de suscripción del canal sin el acceso adecuado al canal a través de una llamada API al endpoint GET autocomplete/GetChannelSubscriptions.
Vulnerabilidad en Mattermost Confluence (CVE-2025-53910)
Severidad: MEDIA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede verificar el acceso del usuario al canal, lo que permite a los atacantes crear una suscripción al canal sin el acceso adecuado al canal a través de una llamada API al endpoint de edición de suscripción del canal.
Vulnerabilidad en Mattermost Confluence (CVE-2025-54458)
Severidad: MEDIA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 25/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no puede verificar el acceso del usuario al espacio Confluence, lo que permite a los atacantes crear una suscripción para un espacio Confluence al que el usuario no tiene acceso a través del endpoint de creación de suscripción.