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 NVIDIA ChatRTX (CVE-2024-0096)
Severidad: ALTA
Fecha de publicación: 14/05/2024
Fecha de última actualización: 17/09/2025
NVIDIA ChatRTX para Windows contiene una vulnerabilidad en la interfaz de usuario de Chat RTX, donde un usuario puede causar un problema de administración de privilegios inadecuado al enviar entradas del usuario para cambiar el flujo de ejecución. Una explotación exitosa de esta vulnerabilidad podría dar lugar a la divulgación de información, la escalada de privilegios y la manipulación de datos.
Vulnerabilidad en NVIDIA ChatRTX (CVE-2024-0097)
Severidad: ALTA
Fecha de publicación: 14/05/2024
Fecha de última actualización: 17/09/2025
NVIDIA ChatRTX para Windows contiene una vulnerabilidad en la interfaz de usuario de ChatRTX, donde un usuario puede causar un problema de administración de privilegios inadecuado al explotar la comunicación entre procesos entre diferentes procesos. Una explotación exitosa de esta vulnerabilidad podría dar lugar a la divulgación de información, la escalada de privilegios y la manipulación de datos.
Vulnerabilidad en NVIDIA ChatRTX (CVE-2024-0098)
Severidad: MEDIA
Fecha de publicación: 14/05/2024
Fecha de última actualización: 17/09/2025
NVIDIA ChatRTX para Windows contiene una vulnerabilidad en la interfaz de usuario y el backend de ChatRTX, donde un usuario puede provocar un problema de transmisión de texto plano de información confidencial mediante el rastreo de datos. Una explotación exitosa de esta vulnerabilidad podría conducir a la divulgación de información.
Vulnerabilidad en kernel de Linux (CVE-2024-37354)
Severidad: MEDIA
Fecha de publicación: 25/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el fallo en fsync de ejecucións y escritura de extensión de tamaño en prealloc. Hemos estado viendo fallos en claves duplicadas en btrfs_set_item_key_safe(): BTRFS crítico (dispositivo vdb): clave de ranura 4 ( 450 108 8192) nueva clave (450 108 8192) ------------[ cortar aquí ]------------ ERROR del kernel en fs/btrfs/ctree.c: 2620! código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: cargado No contaminado 6.9.0 #6 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2 .fc40 01/04/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] Con el siguiente seguimiento de pila: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file .c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs /tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c :212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 Entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S :121) Así que estamos registrando una extensión modificada desde fsync, que es dividir una extensión en el árbol de registro. Pero esta parte dividida ya existe en el árbol, lo que activa el ERROR(). Este es el estado del árbol de registro en el momento del bloqueo, descargado con drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) para obtener más detalles de los que proporciona btrfs_print_leaf() nosotros: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) hoja 33439744 elementos de nivel 0 72 generación 9 propietario 18446744073709551610 hoja 33439744 banderas 0x100000000000000 fs uuid 00c-4223-8923-190ef1f18677 fragmento uuid d58cb17e-6d02-494a-829a-18b7d8a399da clave del elemento 0 (450 INODE_ITEM 0) itemoff 16123 tamaño del elemento 160 generación 7 transid 9 tamaño 8192 nbytes 8473563889606862198 grupo de bloques 0 modo 100600 enlaces 1 uid 0 gid 0 rdev 0 secuencia 204 banderas 0x10(PREALLOC ) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-2) 2 15:41:44) otime 17592186044416.000000000 (559444-03- 08 01:40:16) clave del elemento 1 (450 INODE_REF 256) itemoff 16110 tamaño del elemento 13 índice 195 namelen 3 nombre: 193 clave del elemento 2 (450 XATTR_ITEM 1640047104) itemoff 16073 tamaño del elemento 37 clave de ubicación (0 UNKNOWN.0 0) tipo XATTR transid 7 data_len 1 name_len 6 nombre: usuario.a datos a elemento 3 clave (450 EXTENT_DATA 0) itemoff 16020 tamaño de elemento 53 generación 9 tipo 1 (normal) byte de disco de datos de extensión 303144960 nr 12288 desplazamiento de datos de extensión 0 nr 4096 ram 12288 compresión de extensión 0 ( ninguno) clave del elemento 4 (450 EXTENT_DATA 4096) itemoff 15967 tamaño del elemento 53 generación 9 tipo 2 (preasignación) byte de disco de datos de preasignación 303144960 nr 12288 compensación de datos de preasignación 4096 nr 8192 clave del elemento 5 (450 EXTENT_DATA 8192) itemoff 15914 tamaño del elemento 53 generación 9 tipo 2 (preasignación) byte de disco de datos de preasignación 303144960 nr 12288 desplazamiento de datos de preasignación 8192 nr 4096 ... Entonces, el verdadero problema ocurrió antes: observe que los elementos 4 (4k-12k) y 5 (8k-12k) se superponen. Ambas son extensiones de preasignación. El elemento 4 abarca i_size y el elemento 5 comienza en i_size. Aquí está el estado de ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-38306)
Severidad: MEDIA
Fecha de publicación: 25/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: proteger folio::privado al adjuntar folios de búfer de extensión [ERROR] Desde la versión 6.8, varias personas reportan fallas raras del kernel, el factor común son mensajes de error de estado incorrecto de la página así: ERROR: Estado incorrecto de la página en el proceso kswapd0 pfn:d6e840 página: refcount:0 mapcount:0 mapeo:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone= 2 |lastcpupid=0x3fffff) tipo de página: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 0000 0000ffffffff 0000000000000000 página volcada porque: mapeo no NULL [CAUSA] Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() para asignar el método luego adjuntar ") cambia la secuencia al asignar un nuevo búfer de extensión. Anteriormente siempre llamábamos a grab_extent_buffer() en mapeo->i_private_lock, para garantizar la seguridad en la modificación en folio::private (que es un puntero al búfer de extensión para el tamaño de sector normal). Esto puede llevar a la siguiente ejecución: el subproceso A está intentando asignar un búfer de extensión en el bytenr X, con 4 páginas de 4K, mientras que el subproceso B está intentando liberar la página en X + 4K (la segunda página del búfer de extensión en X) . Hilo A | Hilo B -----------------------------------+------------ ------------------------- | btree_release_folio() | | Esto es para la página en X + 4K, | | No la página X. | | alloc_extent_buffer() | |- release_extent_buffer() |- filemap_add_folio() para el | | |- atomic_dec_and_test(eb->refs) | página en bytenr X (la primera | | | | página). | | | | Que devolvió -EEXIST. | | | | | | | |- filemap_lock_folio() | | | | Devolvió la primera página bloqueada. | | | | | | | |- grab_extent_buffer() | | | | |- atomic_inc_not_zero() | | | | | Devuelto falso | | | | |- folio_detach_private() | | |- folio_detach_private() para X | |- folio_test_private() | | |- folio_test_private() | Devuelto verdadero | | | Devuelto verdadero |- folio_put() | |- folio_put() Ahora hay dos opciones de venta en el mismo folio en el folio X, lo que provoca un recuento insuficiente del folio X y, finalmente, provoca el error BUG_ON() en la página->mapeo. La condición no es tan fácil de cumplir: - La publicación debe activarse para la página intermedia de un eb. Si la publicación está en la misma primera página de un eb, el bloqueo de página se activaría e impediría la ejecución. - folio_detach_private() tiene una ventana de ejecución muy pequeña. Es solo entre folio_test_private() y folio_clear_private(). Eso es exactamente cuando se usa mapeo->i_private_lock para evitar dicha ejecución, y la confirmación 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() para asignar-luego-adjuntar método") arruinó eso. En ese momento, pensé que el bloqueo de página se activaría ya que filemap_release_folio() también requiere que la página esté bloqueada, pero olvidé que filemap_release_folio() solo bloquea una página, no todas las páginas de un búfer de extensión. [FIX] Mueva todo el código que requiere i_private_lock a adjunto_eb_folio_to_filemap(), para que todo se haga con la protección de bloqueo adecuada. Además, para evitar problemas futuros, agregue un lockdep_assert_locked() adicional para garantizar que mantenemos el bloqueo adecuado. Para el reproductor que puede iniciar la ejecución (tarda unos minutos con el código instrumentado insertando retrasos en alloc_extent_buffer()): #!/bin/sh drop_caches () { while(true); hacer echo 3 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/compact_memory hecho } run_tar () { while(true); hacer para x en `seq 1 80`; hacer tar cf /dev/zero /mnt > /dev/null & hecho esperar hecho } mkfs.btrfs -f -d single -m single ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-39293)
Severidad: MEDIA
Fecha de publicación: 25/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "xsk: admite redirección a cualquier socket vinculado al mismo umem". Esto revierte el commit 2863d665ea41282379f108e4da6c8a2366ba66db. Este parche introdujo un posible fallo del kernel cuando varias instancias de napi se redirigen al mismo socket AF_XDP. Al eliminar la verificación queue_index, es posible que varias instancias de napi accedan al anillo Rx al mismo tiempo, lo que resultará en un estado de anillo corrupto que puede provocar un bloqueo al vaciar los anillos en __xsk_flush(). Esto puede suceder cuando la lista vinculada de sockets para vaciar se corrompe por accesos simultáneos. No es posible una solución rápida y pequeña, así que revirtamos esto por ahora.
Vulnerabilidad en kernel de Linux (CVE-2024-39296)
Severidad: MEDIA
Fecha de publicación: 25/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vinculación: corrige errores durante rmmod "rmmod bonding" provoca un error desde el commit cc317ea3d927 ("unión: elimina la comprobación NULL redundante en la función debugfs"). Aquí están las funciones relevantes que se llaman: bonding_exit() bond_destroy_debugfs() debugfs_remove_recursive(bonding_debug_root); bonding_debug_root = NULL; <--------- ESTABLECER EN NULL AQUÍ bond_netlink_fini() rtnl_link_unregister() __rtnl_link_unregister() unregister_netdevice_many_notify() bond_uninit() bond_debug_unregister() (confirmar verificación eliminada para bonding_debug_root == NULL) debugfs_remove() simple_recursive_removal() down_write( ) -> OOPS Sin embargo, revertir el compromiso incorrecto no resuelve el problema por completo porque el código original contiene una ejecución que podría causar el mismo error, aunque era mucho menos probable que se activara involuntariamente: CPU1 rmmod bonding bonding_exit() bond_destroy_debugfs() debugfs_remove_recursive(bonding_debug_root); CPU2 echo -bond0 > /sys/class/net/bonding_masters bond_uninit() bond_debug_unregister() if (!bonding_debug_root) CPU1 bonding_debug_root = NULL; Por lo tanto, NO revierta la confirmación incorrecta (ya que las comprobaciones eliminadas eran picantes de todos modos) y, en su lugar, cambie el orden de las acciones tomadas durante la eliminación del módulo. Lo mismo también puede suceder si hay un error durante el inicio del módulo, así que aplique la misma solución allí.
Vulnerabilidad en kernel de Linux (CVE-2024-39467)
Severidad: ALTA
Fecha de publicación: 25/06/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: corrección para realizar una verificación de estado en i_xattr_nid en sanity_check_inode() syzbot informa un error en el kernel como se muestra a continuación: F2FS-fs (loop0): Montado con la versión de punto de control = 48b305e4 ==== ==================================================== ============ ERROR: KASAN: losa fuera de los límites en f2fs_test_bit fs/f2fs/f2fs.h:2933 [en línea] ERROR: KASAN: losa fuera de los límites en current_nat_addr fs/f2fs/node.h:213 [en línea] ERROR: KASAN: losa fuera de los límites en f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Lectura de tamaño 1 en la dirección ffff88807a58c76c mediante la tarea syz-executor280 /5076 CPU: 1 PID: 5076 Comm: syz-executor280 No contaminado 6.9.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report +0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [en línea] current_nat_addr fs/f2fs/node.h:213 [en línea] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node. c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [en línea] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [en línea] do_vfs_ioctl+0x1c07/0x2e50 ioctl. c:838 __do_sys_ioctl fs/ioctl.c:902 [en línea] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/ Entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f La causa principal es que no hicimos una verificación de cordura en i_xattr_nid durante f2fs_iget(), de modo que en la ruta fiemap(), current_nat_addr() accederá a nat_bitmap con desplazamiento desde i_xattr_nid no válido, resulta en la activación del informe de error de Kasan, corríjalo.
Vulnerabilidad en kernel de Linux (CVE-2024-39488)
Severidad: MEDIA
Fecha de publicación: 10/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: asm-bug: agregue .align 2 al final de __BUG_ENTRY Cuando CONFIG_DEBUG_BUGVERBOSE=n, no agregamos los bytes de relleno necesarios a las entradas de bug_table y, como resultado, la última entrada en una tabla de errores se ignorará, lo que podría provocar un pánico inesperado(). Todas las entradas anteriores en la tabla se manejarán correctamente. La ABI arm64 requiere que los campos de estructura de hasta 8 bytes estén alineados de forma natural, con relleno agregado dentro de una estructura de modo que la estructura esté adecuadamente alineada dentro de las matrices. Cuando CONFIG_DEBUG_BUGVERPOSE=y, el diseño de una entrada de error es: struct bug_entry { firmado int bug_addr_disp; // 4 bytes firmados int file_disp; // Línea corta sin firmar de 4 bytes; // 2 bytes de banderas cortas sin firmar; // 2 bytes } ... con 12 bytes en total, que requieren una alineación de 4 bytes. Cuando CONFIG_DEBUG_BUGVERBOSE=n, el diseño de una entrada de error es: struct bug_entry { firmado int bug_addr_disp; // 4 bytes de banderas cortas sin firmar; // 2 bytes < relleno implícito > // 2 bytes } ... con 8 bytes en total, con 6 bytes de datos y 2 bytes de relleno final, que requieren un alineamiento de 4 bytes. Cuando creamos un bug_entry en el ensamblado, alineamos el inicio de la entrada a 4 bytes, lo que implícitamente maneja el relleno de cualquier entrada anterior. Sin embargo, no alineamos el final de la entrada, por lo que cuando CONFIG_DEBUG_BUGVERBOSE=n, la entrada final carece de los bytes de relleno finales. Para la imagen principal del kernel, esto no es un problema ya que find_bug() no depende de los bytes de relleno finales cuando se buscan entradas: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug )) error de devolución; Sin embargo, para los módulos, module_bug_finalize() depende de los bytes finales al calcular el número de entradas: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... y como la última entrada_error carece de los bytes de relleno necesarios, esta entrada no se contará, p.e. en el caso de una sola entrada: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; En consecuencia, module_find_bug() perderá la última entrada de error cuando lo haga: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... lo que puede provocar pánico en el kenrel debido a un error no controlado. Esto se puede demostrar con el siguiente módulo: static int __init buginit(void) { WARN(1, "hello\n"); devolver 0; } vacío estático __exit bugexit(void) { } module_init(buginit); module_exit(salida de error); MODULE_LICENSE("GPL"); ... lo que provocará un pánico en el kernel cuando se cargue: ------------[ cortar aquí ]------------ hola Excepción inesperada de BRK en el kernel en EL1 Error interno: Controlador BRK: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Nombre de hardware: linux,dummy-virt (DT) pstate: 60400005 ( nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-39491)
Severidad: MEDIA
Fecha de publicación: 10/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: cs35l56: Corrección de duración de la instancia cs_dsp La instancia cs_dsp se inicializa en el controlador probe() por lo que debe liberarse en el controlador remove(). También corrija una llamada faltante a cs_dsp_remove() en la ruta de error de cs35l56_hda_common_probe(). La llamada a cs_dsp_remove() se realizaba en la devolución de llamada de desvinculación del componente cs35l56_hda_unbind(). Esto significaba que si el controlador no estaba vinculado y luego se volvía a vincular, estaría utilizando una instancia cs_dsp no inicializada. Es mejor inicializar la instancia cs_dsp en probe() para que pueda devolver un error si falla. La API de enlace de componentes no tiene ningún control de errores, por lo que no hay forma de controlar un error si cs_dsp se inicializó en el enlace.
Vulnerabilidad en kernel de Linux (CVE-2024-39497)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/shmem-helper: corrige BUG_ON() en mmap(PROT_WRITE, MAP_PRIVATE) La falta de verificación para el mapeo de copia en escritura (COW) en drm_gem_shmem_mmap permite a los usuarios llamar a mmap con Los indicadores PROT_WRITE y MAP_PRIVATE causan un pánico en el kernel debido a BUG_ON en vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Devuelva -EINVAL temprano si se detecta el mapeo COW. Este error afecta a todos los controladores drm que utilizan ayudantes shmem predeterminados. Se puede reproducir con este sencillo ejemplo: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;
Vulnerabilidad en kernel de Linux (CVE-2024-39499)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vmci: evita fugas especulativas sanitizando el evento en event_deliver(). Coverity detectó que event_msg está controlado por el espacio de usuario, event_msg->event_data.event se pasa a event_deliver() y se usa como un índice sin sanitización. Este cambio garantiza que el índice de eventos esté sanitizado para mitigar cualquier posibilidad de fuga de información especulativa. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc. Solo se prueba la compilación, no hay acceso al hardware.
Vulnerabilidad en kernel de Linux (CVE-2024-39502)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: corrige el use after de netif_napi_del() Cuando se inician las colas, se llama a netif_napi_add() y napi_enable(). Si hay 4 colas y solo se utilizan 3 colas para la configuración actual, solo se deben registrar y habilitar napi de 3 colas. ionic_qcq_enable() comprueba si el puntero .poll no es NULL para habilitar solo el napi de la cola de uso. netif_napi_add() no registrará el napi de las colas no utilizadas, por lo que el puntero .poll indica NULL. Pero no pudo distinguir si el napi no estaba registrado o no porque netif_napi_del() no restablece el puntero .poll a NULL. Entonces, ionic_qcq_enable() llama a napi_enable() para la cola, que netif_napi_del() canceló el registro. Reproductor: ethtool -L rx 1 tx 1 combinado 0 ethtool -L rx 0 tx 0 combinado 1 ethtool -L rx 0 tx 0 combinado 4 Splat se parece a: kernel ERROR en net/ núcleo/dev.c:6666! Vaya: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 No contaminado 6.10.0-rc2+ #16 Cola de trabajo: eventos ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/ 0x40 Código: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 10246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 00000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: 13ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 5555554 Seguimiento de llamadas: ? morir+0x33/0x90? do_trap+0xd9/0x100? napi_enable+0x3b/0x40? do_error_trap+0x83/0xb0? napi_enable+0x3b/0x40? napi_enable+0x3b/0x40? exc_invalid_op+0x4e/0x70? napi_enable+0x3b/0x40? asm_exc_invalid_op+0x16/0x20? napi_enable+0x3b/0x40 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224 ff7d10789e3f14643f8] ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a03543 6e1c4224ff7d10789e3f14643f8] proceso_one_work+0x145/0x360 trabajador_thread+0x2bb/ 0x3d0? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Vulnerabilidad en kernel de Linux (CVE-2024-39503)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: ipset: corrige la ejecución entre la limpieza del espacio de nombres y gc en el tipo list:set Lion Ackermann informó que existe una condición de ejecución entre la limpieza del espacio de nombres en ipset y la recolección de basura de la lista : establecer tipo. La limpieza del espacio de nombres puede destruir el tipo list:set de conjuntos mientras el gc del tipo set espera ejecutarse en la limpieza de rcu. Este último utiliza datos del conjunto destruido, lo que lleva a un uso posterior al gratuito. El parche contiene las siguientes partes: - Al destruir todos los conjuntos, primero retire los recolectores de basura, luego espere si es necesario y luego destruya los conjuntos. - Se corrigió el error "esperar y luego eliminar gc" mal ordenado para destruir un solo caso de conjunto. - Corrija el bloqueo de rcu que falta en la lista: establezca el tipo en el caso de prueba del espacio de usuario. - Utilice el manejo adecuado de la lista de RCU en el tipo list:set. El parche depende de c1193d9bbbd3 (netfilter: ipset: Agregar lista vaciada a cancel_gc).
Vulnerabilidad en kernel de Linux (CVE-2024-39505)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/komeda: verifique el puntero con valor de error komeda_pipeline_get_state() puede devolver un puntero con valor de error, por lo tanto, verifique el puntero en busca de valores negativos o nulos antes de eliminar la referencia.
Vulnerabilidad en kernel de Linux (CVE-2024-39509)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: núcleo: eliminar WARN_ON() innecesario en implementar() Syzkaller recibió una advertencia [1] en una llamada a implementar() al intentar escribir un valor en un campo de tamaño más pequeño. tamaño en un informe de salida. Dado que implement() ya tiene un mensaje de advertencia impreso con la ayuda de hid_warn() y el valor en cuestión se recorta con: ... value &= m; ... WARN_ON puede considerarse superfluo. Elimínelo para suprimir futuros desencadenantes de syzkaller. [1] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid/hid-core.c:1451 implementar drivers/hid/hid-core.c:1451 [en línea] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid /hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Módulos vinculados en: CPU: 0 PID: 5084 Comm: syz-executor424 No contaminado 6.9.0-rc7-syzkaller-00183 -gcf87f46fd34d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [en línea] RIP: 0010:hid_output_report+0x548/ 0x760 drivers/hid/hid-core.c:1863... Seguimiento de llamadas: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [en línea] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid -core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs /ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f...
Vulnerabilidad en kernel de Linux (CVE-2024-40900)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: elimina solicitudes de xarray durante las solicitudes de vaciado Incluso con CACHEFILES_DEAD configurado, aún podemos leer las solicitudes, por lo que en la siguiente concurrencia la solicitud se puede usar después de que se haya liberado: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------- --------- Cachefiles_ondemand_init_object Cachefiles_ondemand_send_req req_a = kzalloc (sizeof (*req) + data_len) Wait_for_completion (& req_a-> ded) gratis (req_a ) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // ¡¡¡requiere use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Por lo tanto, elimine las solicitudes de cache->reqs cuando las vacíe para evitar acceder a las solicitudes liberadas.
Vulnerabilidad en kernel de Linux (CVE-2024-40913)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: difiere la exposición de anon_fd hasta que copy_to_user() tenga éxito. Después de instalar el fd anónimo, ahora podemos verlo en el área de usuario y cerrarlo. Sin embargo, en este punto es posible que no hayamos obtenido el recuento de referencias del caché, pero lo colocaremos durante colse fd, por lo que esto puede causar un UAF de caché. Así que tome el recuento de referencias de caché antes de fd_install(). Además, según la convención del kernel, el usuario se hace cargo de fd después de fd_install(), y el kernel no debe llamar a close_fd() después de eso, es decir, debe llamar a fd_install() después de que todo esté listo, por lo que fd_install() es llamado después de que copy_to_user() tenga éxito.
Vulnerabilidad en kernel de Linux (CVE-2024-40915)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: reescribe __kernel_map_pages() para arreglar el modo de dormir en un contexto no válido. __kernel_map_pages() es una función de depuración que borra el bit válido en la entrada de la tabla de páginas para páginas designadas para detectar accesos ilegales a la memoria de las páginas liberadas. Esta función establece/borra el bit válido usando __set_memory(). __set_memory() adquiere el semáforo de init_mm y esta operación puede suspenderse. Esto es problemático, porque __kernel_map_pages() se puede llamar en un contexto atómico y, por lo tanto, es ilegal dormir. Un ejemplo de advertencia de que esto causa: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/rwsem.c:1578 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, nombre: kthreadd preempt_count: 2, esperado: 0 CPU: 0 PID: 2 Comm: kthreadd No contaminado 6.9.0-g1d4c6d784ef6 #37 Nombre de hardware: riscv-virtio,qemu (DT) Seguimiento de llamadas: [] dump_backtrace+0x1c/0x24 [] show_stack+0x2c/0x38 [] dump_stack_lvl+0x5a/0x72 [] dump_stack+0x14/0x1c [] __might_resched+0x104/0x10e [] __might_sleep+0x3e/0x62 [] down_write+0x20/0x72 [] __set_memory+0x82/0x2fa [] __kernel_map_pages+0x5a/0xd4 [] __alloc_pages_bulk+0x3b2/0x43a [] __vmalloc_node_range+0x196/0x6ba [] copy_process+0x72c/0x17ec [] kernel_clone+0x60/0x2fe [] kernel_thread+0x82/0xa0 [] kthreadd+0x14a/0x1be [] _from_fork+0xe/0x1c Reescribe esta función con apply_to_existing_page_range(). Está bien no tener ningún bloqueo, porque __kernel_map_pages() funciona con páginas que se asignan/desasignan y, mientras tanto, nadie más cambia esas páginas.
Vulnerabilidad en kernel de Linux (CVE-2024-40918)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: intenta corregir fallas de segmentación aleatoria en compilaciones de paquetes. Los sistemas PA-RISC con procesadores PA8800 y PA8900 han tenido problemas con fallas de segmentación aleatoria durante muchos años. Los sistemas con procesadores anteriores son mucho más estables. Los sistemas con procesadores PA8800 y PA8900 tienen una gran caché L2 que necesita un vaciado por página para un rendimiento decente cuando se vacía un rango grande. La caché combinada en estos sistemas también es más sensible a alias no equivalentes que las cachés de sistemas anteriores. La mayoría de los fallos de segmentación aleatoria que he observado parecen ser daños en la memoria asignada mediante mmap y malloc. Mi primer intento de solucionar los fallos aleatorios no funcionó. Al revisar el código de caché, me di cuenta de que había dos problemas que el código existente no manejaba correctamente. Ambos se relacionan con la entrada de caché. Otro problema es que la actualidad en las PTE es picante. 1) Los cachés PA-RISC tienen mente propia y pueden cargar especulativamente datos e instrucciones para una página siempre que haya una entrada en el TLB para la página que permita la entrada. Los TLB son locales para cada CPU. Por lo tanto, la entrada TLB de una página debe eliminarse antes de eliminarla. Esto es particularmente importante en los sistemas SMP. En algunas de las rutinas de vaciado, se llamaría a la rutina de vaciado y luego se purgaría la entrada TLB. Esto se debía a que la rutina de lavado necesitaba la entrada TLB para realizar el lavado. 2) Mi enfoque inicial para intentar solucionar las fallas aleatorias fue intentar usar Flush_cache_page_if_present para todas las operaciones de descarga. En realidad, esto empeoró las cosas y provocó un par de bloqueos de hardware. Finalmente me di cuenta de que algunas líneas no se estaban borrando porque el código de verificación del pte era picante. Esto resultó en asignaciones aleatorias no equivalentes a páginas físicas. La descarga tmpalias __flush_cache_page configura su propia entrada TLB y no necesita la entrada TLB existente. Siempre que podamos encontrar el puntero pte de la página vm, podemos obtener el pfn y la dirección física de la página. También podemos purgar la entrada TLB de la página antes de realizar el vaciado. Además, __flush_cache_page utiliza una entrada TLB especial que inhibe la entrada de caché. Al cambiar las asignaciones de páginas, debemos asegurarnos de que las líneas se eliminen del caché. No es suficiente simplemente borrar las líneas de la memoria, ya que pueden volver. Esto dejó en claro que necesitábamos implementar todas las operaciones de vaciado necesarias utilizando rutinas tmpalias. Esto incluye vaciados para páginas de usuario y de kernel. Después de modificar el código para usar tmpalias vaciados, quedó claro que los errores de segmentación aleatoria no se resolvieron por completo. La frecuencia de fallas fue peor en sistemas con 64 MB L2 (PA8900) y sistemas con más CPU (rp4440). La advertencia que agregué a Flush_cache_page_if_present para detectar páginas que no se podían vaciar se activaba con frecuencia en algunos sistemas. Helge y yo miramos las páginas que no se podían vaciar y descubrimos que la PTE estaba vacía o era una página de intercambio. Ignorar las páginas que se intercambiaron parecía estar bien, pero las páginas con PTE borradas parecían problemáticas. Miré rutinas relacionadas con pte_clear y noté ptep_clear_flush. La implementación predeterminada simplemente vacía la entrada TLB. Sin embargo, era obvio que en París también necesitamos vaciar la página de caché. Si no limpiamos la página de caché, quedarán líneas obsoletas en la caché y provocarán daños aleatorios. Una vez que se borra una PTE, no hay forma de encontrar la dirección física asociada con la PTE y borrar la página asociada más adelante. ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-40920)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mst: corrige el uso sospechoso de rcu en br_mst_set_state Convertí br_mst_set_state a RCU para evitar un use-after-free de VLAN, pero olvidé cambiar el asistente de desreferencia del grupo VLAN. Cambie al asistente deref de RCU del grupo vlan para corregir la advertencia de uso sospechoso de rcu.
Vulnerabilidad en kernel de Linux (CVE-2024-40921)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: mst: pasar grupo vlan directamente a br_mst_vlan_set_state Pase el puntero del grupo vlan ya obtenido a br_mst_vlan_set_state() en lugar de desreferenciarlo nuevamente. Cada persona que llama ya lo ha desreferenciado correctamente para su contexto. Este cambio es necesario para la siguiente corrección sospechosa de desreferencia de RCU. No se pretenden cambios funcionales.
Vulnerabilidad en kernel de Linux (CVE-2024-40925)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el uso de request.queuelist en Flush Friedrich Weber informó un problema de falla del kernel y lo bisecó para el commit 81ada09cc25e ("blk-flush: reutilizar rq queuelist en la máquina de estado de descarga"). La causa principal es que usamos "list_move_tail(&rq->queuelist, pendiente)" en las secuencias PREFLUSH/POSTFLUSH. Pero rq->queuelist.next == xxx ya que salió del plug->cached_rq en __blk_mq_alloc_requests_batch(). No inicializamos su lista de colas solo para esta primera solicitud, aunque se inicializará la lista de colas de todas las solicitudes emergentes posteriores. Solucionelo cambiando para usar "list_add_tail(&rq->queuelist, pendiente)" para que no sea necesario inicializar rq->queuelist. Debería estar bien ya que rq no puede estar en ninguna lista cuando PREFLUSH o POSTFLUSH, en realidad no tiene movimiento. Tenga en cuenta que el commit 81ada09cc25e ("blk-flush: reutilizar rq queuelist en la máquina de estado de descarga") también tiene otro requisito de que ningún controlador toque rq->queuelist después de blk_mq_end_request() ya que lo reutilizaremos para agregar rq al post-flush lista pendiente en POSTFLUSH. Si esto no es cierto, tendremos que revertir ese commit en mi humilde opinión. Esta versión actualizada agrega "list_del_init(&rq->queuelist)" en la devolución de llamada de Flush rq ya que la capa dm puede enviar una solicitud de un formato extraño no válido (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), lo que provoca el doble list_add si no se tiene este "list_del_init(&rq->queuelist) ". El extraño problema del formato no válido debería solucionarse en la capa dm.
Vulnerabilidad en kernel de Linux (CVE-2024-40927)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Manejar el borrado de TD para el caso de múltiples flujos Cuando se utilizan múltiples flujos, es posible que haya múltiples TD en vuelo cuando se detiene un endpoint. Necesitamos emitir un puntero de salida de cola TR para cada uno, para garantizar que todo se restablezca correctamente y se borren los cachés. Cambie la lógica para que cualquier N>1 TD que se encuentre activo para diferentes flujos se difiera hasta después de que se procese el primero, llamando a xhci_invalidate_cancelled_tds() nuevamente desde xhci_handle_cmd_set_deq() para poner en cola otro comando hasta que hayamos terminado con todos ellos. También cambie las rutas de error/"nunca debería suceder" para asegurarnos de que al menos borramos los TD afectados, incluso si no podemos emitir un comando para borrar el caché del hardware, y quejarnos en voz alta con un xhci_warn() si esto alguna vez sucede. Este caso de problema se remonta al commit e9df17eb1408 ("USB: xhci: Suposiciones correctas sobre el número de anillos por endpoint.") al principio de la vida del controlador XHCI, cuando se agregó por primera vez el soporte de transmisión. Luego se identificó, pero no se solucionó ni se convirtió en una advertencia en el commit 674f8438c121 ("xhci: dividir el manejo de endpoints detenidos en dos pasos"), que agregó un comentario FIXME para el caso del problema (sin cambiar materialmente el comportamiento, hasta donde yo sé). , aunque la nueva lógica hizo que el problema fuera más obvio). Luego, más tarde, en el commit 94f339147fc3 ("xhci: Se corrigió el error al devolver algunas URB canceladas en caché"), se reconoció nuevamente. [Mathias: commit 94f339147fc3 ("xhci: Se corrigió el error al devolver algunas URB canceladas en caché") fue una solución de regresión específica para el parche mencionado anteriormente. Los usuarios informaron problemas con el USB atascado después de desmontar/desconectar dispositivos UAS. Esto revirtió la limpieza de TD de múltiples transmisiones a su estado original.] Aparentemente, el autor de el commit estaba al tanto del problema (pero aún así decidió enviarlo): todavía se mencionaba como FIXME, se agregó un xhci_dbg() para registrar el condición del problema y el problema restante se mencionó en la descripción de El commit. La elección de crear el tipo de registro xhci_dbg() para lo que, en este momento, es una condición rota completamente no controlada y conocida es desconcertante y desafortunada, ya que garantiza que ningún usuario real verá el registro en producción, lo que lo hace casi no depurable ( de hecho, incluso si activa DEBUG, el mensaje realmente no indica que haya ningún problema). Me tomó *meses* de fallas aleatorias de xHC para finalmente encontrar una reproducción confiable y poder realizar una sesión de depuración profunda, que podría haberse evitado si esta condición rota y no controlada se hubiera informado con una advertencia, como debería haber sido. ha sido un error que se dejó intencionalmente sin corregir (sin importar que no debería haberse dejado en absoluto). > Se necesita otra solución para solucionar el borrado de los cachés de todos los anillos de transmisión con > TD cancelados, pero no es tan urgente. 3 años después de esa declaración y 14 años después de que se introdujo el error original, creo que finalmente es hora de solucionarlo. Y tal vez la próxima vez no dejemos errores sin corregir (que en realidad son peores que el error original), y hagamos que la gente revise las confirmaciones del kernel, por favor. Soluciona fallas de xHC y fallas de IOMMU con dispositivos UAS al manejar errores/fallas. La reproducción más sencilla es usar `hdparm` para marcar un sector inicial (por ejemplo, 1024) en un disco como defectuoso, luego `cat /dev/sdX > /dev/null` en un bucle. ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-40929)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: verifique n_ssids antes de acceder a los ssids en algunas versiones de cfg80211, el punto ssids puede ser válido aunque n_ssids sea 0. Accediendo al puntero en este caso provocará un acceso fuera de los límites. Solucione este problema comprobando primero n_ssids.
Vulnerabilidad en kernel de Linux (CVE-2024-40935)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: vacía todas las solicitudes después de configurar CACHEFILES_DEAD En modo bajo demanda, cuando el daemon está procesando una solicitud abierta, si el kernel marca el caché como CACHEFILES_DEAD, cachefiles_daemon_write() siempre devolverá: EIO, por lo que el daemon no puede pasar el copen al kernel. Luego, el proceso del núcleo que está esperando el copen activa una tarea colgada. Dado que el estado DEAD es irreversible, solo se puede salir cerrando /dev/cachefiles. Por lo tanto, después de llamar a cachefiles_io_error() para marcar el caché como CACHEFILES_DEAD, si está en modo bajo demanda, vacíe todas las solicitudes para evitar la tarea suspendida anterior. Es posible que aún podamos leer algunos de los datos almacenados en caché antes de cerrar el fd de /dev/cachefiles. Tenga en cuenta que esto depende del parche que agrega el recuento de referencias al requisito; de lo contrario, puede ser UAF.
Vulnerabilidad en kernel de Linux (CVE-2024-40939)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: corregir la eliminación del puntero contaminado es un caso de error en la creación de la región. En caso de que falle la creación de la región en ipc_devlink_create_region(), el proceso de eliminación de regiones creadas previamente comienza desde el puntero contaminado que en realidad contiene el valor del código de error. Corrija este error disminuyendo el índice de región antes de eliminarlo. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Vulnerabilidad en kernel de Linux (CVE-2024-40940)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la eliminación del puntero contaminado en caso de error en la creación de reglas de flujo. En caso de que falle la creación de reglas de flujo en mlx5_lag_create_port_sel_table(), en lugar de las reglas creadas previamente, se elimina el puntero contaminado varias veces. Corrija este error utilizando punteros de reglas de flujo correctos. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Vulnerabilidad en kernel de Linux (CVE-2024-40942)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: mesh: corrige la fuga de objetos mesh_preq_queue El código hwmp usa objetos de tipo mesh_preq_queue, agregados a una lista en ieee80211_if_mesh, para realizar un seguimiento del mpath que necesitamos resolver. Si se elimina mpath, se elimina la interfaz ex mesh, las entradas en esa lista nunca se limpiarán. Solucione este problema eliminando todos los elementos correspondientes de preq_queue en mesh_path_flush_pending(). Esto debería encargarse de informes KASAN como este: objeto sin referencia 0xffff00000668d800 (tamaño 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (edad 1836.444s) volcado hexadecimal (primeros 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>.. ......... retroceso: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] 8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/ 0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] 11_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/ 0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] xa1c [<00000000b36425d1>] hilo_trabajador+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/ 0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 objeto sin referencia 0xffff000009051f00 (tamaño 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (edad 1836.440s) volcado hexadecimal (primero 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.... ...Xy..... retroceso: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] 0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/ 0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] 11_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/ 0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] xa1c [<00000000b36425d1>] hilo_trabajador+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/ 0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20
Vulnerabilidad en kernel de Linux (CVE-2024-40943)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige ejecuciones entre perforación y AIO+DIO Después de confirmar "ocfs2: devuelve código de error real en ocfs2_dio_wr_get_block", fstests/generic/300 pasa de siempre falló a a veces falló: = ==================================================== ===================== [ 473.293420 ] ejecute fstests generic/300 [ 475.296983 ] JBD2: ignorando la información de recuperación en el diario [ 475.302473 ] ocfs2: Dispositivo de montaje (253,1 ) en (nodo local, ranura 0) con modo de datos ordenados. [ 494.290998 ] OCFS2: ERROR (dispositivo dm-1): ocfs2_change_extent_flag: El propietario 5668 tiene una extensión en cpos 78723 que ya no se puede encontrar [ 494.291609 ] Se descubrió corrupción en el disco. Ejecute fsck.ocfs2 una vez que el sistema de archivos esté desmontado. [ 494.292018 ] OCFS2: el sistema de archivos ahora es de solo lectura. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_write:5272 ERROR: estado = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: estado = -3 fio: Error io_u en el archivo /mnt/scratch/racer: sistema de archivos de solo lectura: escritura offset=460849152, buflen=131072 ========================== ================================================= En __blockdev_direct_IO , se llama a ocfs2_dio_wr_get_block para agregar extensiones no escritas a una lista. Las extensiones también se insertan en el árbol de extensiones en ocfs2_write_begin_nolock. Luego, otro hilo llama a fallocate para hacer un agujero en una de las extensiones no escritas. La extensión en cpos fue eliminada por ocfs2_remove_extent(). Al final del hilo de trabajo de io, ocfs2_search_extent_list descubrió que no existe tal extensión en los cpos. T1 T2 T3 bloqueo de inodo... insertar extensiones... desbloqueo de inodo ocfs2_fallocate __ocfs2_change_file_space bloqueo de inodo bloqueo ip_alloc_sem ocfs2_remove_inode_range inodo ocfs2_remove_btree_range ocfs2_remove_extent ^---eliminar la extensión en cpos 78723... desbloquear inodo ip_alloc_sem desbloquear ocfs2_dio_end_io ocfs2_dio_end_io_write bloquear ip_alloc_sem ocfs2_mark_extent_writing ocfs2_change_extent_flag ocfs2_search_extent_list ^ ---no se pudo encontrar la extensión... desbloquear ip_alloc_sem En la mayoría de los sistemas de archivos, fallocate no es compatible con ejecuciones con AIO+DIO, así que solucionelo agregando esperar a que todos los dio antes de fallocate/punch_hole como ext4.
Vulnerabilidad en kernel de Linux (CVE-2024-40953)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: solucione una ejecución de datos en last_boosted_vcpu en kvm_vcpu_on_spin() Utilice {READ,WRITE}_ONCE() para acceder a kvm->last_boosted_vcpu para garantizar que las cargas y los almacenes sean atómicos. En el escenario extremadamente improbable de que el compilador rompa los almacenes, es teóricamente posible que KVM intente obtener una vCPU utilizando un índice fuera de los límites, por ejemplo, si la escritura se divide en varios almacenes de 8 bits y se combina con un 32 -carga de bits en una VM con 257 vCPU: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; Según lo detectado por KCSAN: ERROR: KCSAN: ejecución de datos en kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] escribe en 0xffffc90025a92344 de 4 bytes por tarea 4340 en la CPU 16: kvm_vcpu_on_spin (arch/x86/kvm/../../. ./virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm /vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c :890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64 .S:130) leído en 0xffffc90025a92344 de 4 bytes por la tarea 4342 en la CPU 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/ x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86 .c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/ x86/entry/entry_64.S:130) valor cambiado: 0x00000012 -> 0x00000000
Vulnerabilidad en kernel de Linux (CVE-2024-40963)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mips: bmips: BCM6358: asegúrese de que CBR esté configurado correctamente. Se descubrió que algunos dispositivos tienen la dirección CBR configurada en 0, lo que provoca pánico en el kernel cuando se llama a arch_sync_dma_for_cpu_all. Esto se notó en una situación en la que el sistema se inicia desde TP1 y BMIPS_GET_CBR() devuelve 0 en lugar de una dirección válida y !!(read_c0_brcm_cmt_local() & (1 << 31)); no fallar. La verificación actual de si la descarga de RAC debe desactivarse o no no es suficiente, por lo tanto, verifiquemos si CBR es una dirección válida o no.
Vulnerabilidad en kernel de Linux (CVE-2024-40968)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: Octeon: agregar verificación de estado del enlace PCIe La interfaz de lectura y escritura de configuración PCIe estándar se utiliza para acceder al espacio de configuración de los dispositivos PCIe periféricos del procesador mips después de la sorpresa del enlace PCIe. inactivo, puede generar pánico en el kernel causado por un "Error del bus de datos". Por lo tanto, es necesario agregar una verificación del estado del enlace PCIe para proteger el sistema. Cuando el enlace PCIe está inactivo o en entrenamiento, asignar un valor de 0 a la dirección de configuración puede evitar el comportamiento de lectura y escritura en el espacio de configuración de los dispositivos PCIe periféricos, evitando así el pánico del kernel.
Vulnerabilidad en kernel de Linux (CVE-2024-40974)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: aplica la validez y el tamaño del búfer de resultados de hcall plpar_hcall(), plpar_hcall9() y las funciones relacionadas esperan que los llamadores proporcionen búferes de resultados válidos de cierto tamaño mínimo. Actualmente esto se comunica sólo a través de comentarios en el código y el compilador no tiene idea. Por ejemplo, si escribo un error como este: long retbuf[PLPAR_HCALL_BUFSIZE]; // debería ser PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); Esto se compila sin emitir diagnósticos, pero probablemente da como resultado daños en la pila en tiempo de ejecución cuando plpar_hcall9() almacena los resultados más allá del final de la matriz. (Para ser claros, este es un ejemplo artificial y todavía no he encontrado una instancia real). Para hacer que esta clase de error sea menos probable, podemos usar parámetros de matriz de tamaño explícito en lugar de punteros en las declaraciones de las API hcall. Cuando se compila con -Warray-bounds[1], el código anterior ahora provoca un diagnóstico como este: error: el argumento de la matriz es demasiado pequeño; es de tamaño 32, el destinatario requiere al menos 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Habilitado para compilaciones LLVM pero no para GCC por ahora. Consulte El commit 0da6e5fd6c37 ("gcc: deshabilite '-Warray-bounds' para gcc-13 también") y relacionados cambios.
Vulnerabilidad en kernel de Linux (CVE-2024-40978)
Severidad: ALTA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qedi: soluciona el fallo al leer el atributo debugfs La función qedi_dbg_do_not_recover_cmd_read() invoca sprintf() directamente en un puntero __user, lo que provoca el fallo. Para solucionar este problema, use un pequeño búfer de pila local para sprintf() y luego llame a simple_read_from_buffer(), que a su vez realiza la llamada copy_to_user(). ERROR: no se puede manejar el error de página para la dirección: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Ups: 0002 [#1] PREEMPT SMP PTI Nombre de hardware: HPE ProLi hormiga DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 15/06/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: 18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007ffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 000000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 PKRU: 5554 Seguimiento de llamadas: ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x22/0x30? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] 0x80 vfs_read+0xa5/0x2e0? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90? count_memcg_event_mm+0x3d/0x60? handle_mm_fault+0x196/0x2f0? do_user_addr_fault+0x267/0x890? exc_page_fault+0x69/0x150 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d
Vulnerabilidad en kernel de Linux (CVE-2024-40979)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: soluciona el fallo del kernel durante la reanudación Actualmente, durante la reanudación, la memoria de destino de QMI no se maneja adecuadamente, lo que provoca un fallo del kernel en caso de que no se admita la reasignación de DMA: ERROR: Estado incorrecto de la página en proceso kworker/u16:54 pfn:36e80 página: refcount:1 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x36e80 página descargada porque: distinto de cero _refcount Rastreo de llamadas: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs a th12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb El motivo es: Una vez ath12k El módulo está cargado, el firmware envía la solicitud de memoria al host. En caso de que no se admita la reasignación de DMA, ath12k rechaza la primera solicitud debido a un error en la asignación con un tamaño de segmento grande: ath12k_pci 0000:04:00.0: solicitud de firmware qmi solicitud de memoria ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 7077888 ath12k_pci 0000 :04:00.0: qmi mem seg tipo 4 tamaño 8454144 ath12k_pci 0000:04:00.0: falla en la asignación de qmi dma (7077888 B tipo 1), lo intentaré más tarde con un tamaño pequeño ath12k_pci 0000:04:00.0: qmi retrasa mem_request 2 ath12k_pci 0000: 04:00.0: solicitud de memoria de solicitud de firmware qmi El firmware posterior regresa con más segmentos, pero pequeños, y la asignación se realiza correctamente: ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 pci 0000:04:00.0:qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 262144 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000 :04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00 .0: segmento de memoria qmi tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 24288 ath12k_pci 0000:04 :00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 5242 88 ath12k_pci 0000:04:00.0 : qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem se g tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 65536 ci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 Ahora ath12k está funcionando. Si se activa la suspensión, el firmware se recargará durante la reanudación. Al igual que antes, el firmware solicita dos segmentos grandes al principio. En ath12k_qmi_msg_mem_request_cb() se asigna el recuento y el tamaño del segmento: ab->qmi.mem_seg_count == 2 ab->qmi.target_mem[0].size == 7077888 ab->qmi.target_mem[1].size == 8454144 Luego, la asignación falló como antes y se llama a ath12k_qmi_free_target_mem_chunk() para liberar todos los segmentos asignados. ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-40993)
Severidad: MEDIA
Fecha de publicación: 12/07/2024
Fecha de última actualización: 17/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: ipset: corrige rcu_dereference_protected() sospechoso Al destruir todos los conjuntos, estamos en la fase de salida de pernet o estamos ejecutando un "comando de destruir todos los conjuntos" desde el espacio de usuario. Este último se tuvo en cuenta en ip_set_dereference() (se mantiene el mutex de nfnetlink), pero el primero no. El parche agrega la verificación requerida a rcu_dereference_protected() en ip_set_dereference().
Vulnerabilidad en Contec Co.,Ltd. CONPROSYS HMI System (CVE-2025-34080)
Severidad: MEDIA
Fecha de publicación: 01/07/2025
Fecha de última actualización: 17/09/2025
Contec Co.,Ltd. CONPROSYS HMI System (CHS) es vulnerable a Cross-Site Scripting (XSS) en la funcionalidad getqsetting.php que podría permitir la ejecución reflejada de secuencias de comandos en el navegador durante la interacción. Este problema afecta al sistema HMI CONPROSYS (CHS): anterior a la versión 3.7.7.
Vulnerabilidad en Contec Co.,Ltd. CONPROSYS HMI System (CVE-2025-34081)
Severidad: MEDIA
Fecha de publicación: 01/07/2025
Fecha de última actualización: 17/09/2025
Contec Co.,Ltd. CONPROSYS HMI System (CHS) expone una página de depuración PHP phpinfo() a usuarios no autenticados que puede contener datos confidenciales útiles para un atacante. Este problema afecta al sistema HMI CONPROSYS (CHS): antes de la versión 3.7.7.
Vulnerabilidad en GFI Kerio Control 9.4.5 (CVE-2025-34069)
Severidad: CRÍTICA
Fecha de publicación: 02/07/2025
Fecha de última actualización: 17/09/2025
Existe una vulnerabilidad de omisión de autenticación en GFI Kerio Control 9.4.5 debido a una configuración de proxy predeterminada insegura y un control de acceso deficiente en el servicio GFIAgent. El proxy no transparente del puerto TCP 3128 puede utilizarse para reenviar solicitudes no autenticadas a servicios internos como GFIAgent, evadiendo las restricciones del firewall y exponiendo los endpoints de administración internos. Esto permite a atacantes no autenticados acceder al servicio GFIAgent en los puertos 7995 y 7996, recuperar el UUID del dispositivo y emitir solicitudes administrativas a través del proxy. Su explotación da como resultado acceso administrativo completo al dispositivo Kerio Control.
Vulnerabilidad en GFI Kerio Control 9.4.5 (CVE-2025-34070)
Severidad: CRÍTICA
Fecha de publicación: 02/07/2025
Fecha de última actualización: 17/09/2025
Una vulnerabilidad de falta de autenticación en el componente GFIAgent de GFI Kerio Control 9.4.5 permite a atacantes remotos no autenticados realizar operaciones privilegiadas. El servicio GFIAgent, responsable de la integración con GFI AppManager, expone servicios HTTP en los puertos 7995 y 7996 sin la autenticación adecuada. El controlador /proxy del puerto 7996 permite el reenvío arbitrario a endpoints administrativos cuando se le proporciona un UUID de dispositivo, que a su vez puede obtenerse del puerto 7995. Esto resulta en una omisión completa de la autenticación, lo que permite el acceso a API administrativas confidenciales.
Vulnerabilidad en GFI Kerio Control 9.4.5 (CVE-2025-34071)
Severidad: CRÍTICA
Fecha de publicación: 02/07/2025
Fecha de última actualización: 17/09/2025
Una vulnerabilidad de ejecución remota de código en GFI Kerio Control 9.4.5 permite a atacantes con acceso administrativo cargar y ejecutar código arbitrario mediante la función de actualización de firmware. El mecanismo de actualización del sistema acepta archivos .img sin firmar, que pueden modificarse para incluir scripts maliciosos en los componentes upgrade.sh o de imagen de disco. Estas imágenes de actualización modificadas no se validan en cuanto a autenticidad ni integridad, y el sistema las ejecuta después de la carga, lo que permite el acceso root.
Vulnerabilidad en NSClient++ (CVE-2025-34078)
Severidad: ALTA
Fecha de publicación: 02/07/2025
Fecha de última actualización: 17/09/2025
Existe una vulnerabilidad de escalada de privilegios local en NSClient++ 0.5.2.35 cuando tanto la interfaz web como las funciones de ExternalScripts están habilitadas. El archivo de configuración (nsclient.ini) almacena la contraseña administrativa en texto plano y es legible para los usuarios locales. Al extraer esta contraseña, un atacante puede autenticarse en la interfaz web de NSClient++ (normalmente accesible en el puerto 8443) y abusar del complemento ExternalScripts para inyectar y ejecutar comandos arbitrarios como SYSTEM. Para ello, registra un script personalizado, guarda la configuración y lo activa mediante la API. Este comportamiento está documentado, pero es inseguro, ya que la exposición de las credenciales en texto plano vulnera el aislamiento de acceso entre los usuarios locales y las funciones administrativas.
Vulnerabilidad en Dunamu StockPlus App (CVE-2025-7890)
Severidad: MEDIA
Fecha de publicación: 20/07/2025
Fecha de última actualización: 17/09/2025
Se encontró una vulnerabilidad en Dunamu StockPlus App (hasta la versión 7.62.10) para Android. Se ha declarado problemática. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo AndroidManifest.xml del componente com.dunamu.stockplus. Esta manipulación provoca la exportación incorrecta de componentes de la aplicación Android. El ataque debe abordarse localmente. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en InstantBits Web Video Cast App (CVE-2025-7891)
Severidad: MEDIA
Fecha de publicación: 20/07/2025
Fecha de última actualización: 17/09/2025
Se encontró una vulnerabilidad en InstantBits Web Video Cast App (hasta la versión 5.12.4) para Android. Se ha clasificado como problemática. Este problema afecta a una funcionalidad desconocida del archivo AndroidManifest.xml del componente com.instantbits.cast.webvideo. Esta manipulación provoca la exportación incorrecta de componentes de la aplicación Android. Es necesario abordar un ataque localmente. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en IDnow App (CVE-2025-7892)
Severidad: MEDIA
Fecha de publicación: 20/07/2025
Fecha de última actualización: 17/09/2025
Se ha detectado una vulnerabilidad clasificada como problemática en IDnow App (hasta la versión 9.6.0) de Android. Esta vulnerabilidad afecta a una parte desconocida del archivo AndroidManifest.xml del componente de.idnow. Esta manipulación provoca la exportación incorrecta de componentes de la aplicación Android. Se requiere acceso local para abordar este ataque. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en Foresight News App (CVE-2025-7893)
Severidad: MEDIA
Fecha de publicación: 20/07/2025
Fecha de última actualización: 17/09/2025
Se detectó una vulnerabilidad clasificada como problemática en Foresight News App (hasta la versión 2.6.4) para Android. Esta vulnerabilidad afecta al código desconocido del archivo AndroidManifest.xml del componente pro.foresightnews.appa. La manipulación provoca la exportación incorrecta de componentes de la aplicación Android. Es obligatorio realizar ataques locales. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta vulnerabilidad, pero no respondió.
Vulnerabilidad en Onyx (CVE-2025-7894)
Severidad: MEDIA
Fecha de publicación: 20/07/2025
Fecha de última actualización: 17/09/2025
Se ha detectado una vulnerabilidad, clasificada como crítica, en Onyx hasta la versión 0.29.1. Este problema afecta a la función generate_simple_sql del archivo backend/onyx/agents/agent_search/kb_search/nodes/a3_generate_simple_sql.py del componente Chat Interface. La manipulación provoca una inyección SQL. El ataque puede ejecutarse en remoto. El exploit se ha divulgado públicamente y podría utilizarse. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en KoaJS (CVE-2025-8129)
Severidad: MEDIA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 17/09/2025
Se encontró una vulnerabilidad clasificada como problemática en KoaJS (hasta la versión 3.0.0). La función afectada se encuentra en la librería lib/response.js del componente HTTP Header Handler. La manipulación del argumento Referrer provoca una redirección abierta. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.
Vulnerabilidad en Engeman Web (CVE-2025-8220)
Severidad: MEDIA
Fecha de publicación: 27/07/2025
Fecha de última actualización: 17/09/2025
Se ha detectado una vulnerabilidad clasificada como crítica en Engeman Web hasta la versión 12.0.0.1. Se ve afectada una función desconocida del archivo /Login/RecoveryPass del componente Password Recovery Page. La manipulación del argumento LanguageCombobox provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en Jingmen Zeyou Large File Upload Control (CVE-2025-8203)
Severidad: MEDIA
Fecha de publicación: 26/07/2025
Fecha de última actualización: 17/09/2025
Se ha detectado una vulnerabilidad crítica en Jingmen Zeyou Large File Upload Control hasta la versión 6.3. Se ve afectada una función desconocida del archivo /index.jsp. La manipulación del ID del argumento provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en NotesCMS (CVE-2025-52037)
Severidad: MEDIA
Fecha de publicación: 26/08/2025
Fecha de última actualización: 17/09/2025
Se ha detectado una vulnerabilidad en NotesCMS, clasificada como de gravedad media. Esta vulnerabilidad afecta a la página /index.php?route=sites. La manipulación del título de las descripciones de servicio genera una vulnerabilidad XSS almacenada. Se confirmó la presencia del problema en el código fuente a partir de la commit 7d821a0f028b0778b245b99ab3d3bff1ac10e2d3 (con fecha del 08/05/2024) y se corrigió en la commit 95322c5121dbd7070f3bd54f2848079654a0a8ea (con fecha del 31/03/2025). El ataque puede ejecutarse en remoto. Definición de la vulnerabilidad según CWE: CWE-79.