Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> x86/vmware: Solución para las sobrescrituras de hiperllamadas<br /> <br /> Fedora QA informó el siguiente pánico:<br /> <br /> BUG: unable to handle page fault for address: 0000000040003e54<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025<br /> RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90<br /> ..<br /> Call Trace:<br /> vmmouse_report_events+0x13e/0x1b0<br /> psmouse_handle_byte+0x15/0x60<br /> ps2_interrupt+0x8a/0xd0<br /> ...<br /> <br /> porque la emulación de ratón QEMU VMware tiene errores y borra los 32 bits superiores de %rdi donde el kernel mantenía un puntero.<br /> <br /> El controlador QEMU vmmouse guarda y restaura el estado del registro en un &amp;#39;uint32_t data[6];&amp;#39; y, como resultado, restaura el estado con todos los bits altos borrados.<br /> <br /> RDI originalmente contenía el valor de una dirección de pila de kernel válida (0xff5eeb3240003e54). Después de la hiperllamada de vmware, ahora contiene 0x40003e54, y obtenemos un fallo de página como resultado cuando es desreferenciado.<br /> <br /> La solución adecuada estaría en QEMU, pero esto evita el problema en el kernel para mantener las configuraciones antiguas funcionando, cuando los kernels antiguos no habían guardado ningún estado en %rdi durante la hiperllamada.<br /> <br /> En teoría, este mismo problema existe para todas las hiperllamadas en el controlador vmmouse; en la práctica, solo se ha visto con vmware_hypercall3() y vmware_hypercall4(). Por ahora, simplemente marca RDI/RSI como sobrescritos para esas dos llamadas. Esto debería tener un efecto mínimo en la generación de código en general, ya que debería ser raro que el compilador quiera mantener RDI/RSI activos a través de hiperllamadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: rechazar nuevas transacciones si el fs es completamente de solo lectura<br /> <br /> [ERROR]<br /> Hay un informe de error donde un fs fuertemente fuzzed se monta con todas las opciones de montaje de rescate, lo que lleva a las siguientes advertencias durante el desmontaje:<br /> <br /> BTRFS: Transacción abortada (error -22)<br /> Módulos enlazados:<br /> CPU: 0 UID: 0 PID: 9758 Comm: repro.out No contaminado<br /> 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)<br /> Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [en línea]<br /> RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611<br /> Rastro de llamada:<br /> <br /> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705<br /> btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157<br /> btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517<br /> btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708<br /> btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130<br /> btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499<br /> btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628<br /> evict+0x5f4/0xae0 fs/inode.c:837<br /> __dentry_kill+0x209/0x660 fs/dcache.c:670<br /> finish_dput+0xc9/0x480 fs/dcache.c:879<br /> shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661<br /> generic_shutdown_super+0x67/0x2c0 fs/super.c:621<br /> kill_anon_super+0x3b/0x70 fs/super.c:1289<br /> btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127<br /> deactivate_locked_super+0xbc/0x130 fs/super.c:474<br /> cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318<br /> task_work_run+0x1d4/0x260 kernel/task_work.c:233<br /> exit_task_work include/linux/task_work.h:40 [en línea]<br /> do_exit+0x694/0x22f0 kernel/exit.c:971<br /> do_group_exit+0x21c/0x2d0 kernel/exit.c:1112<br /> __do_sys_exit_group kernel/exit.c:1123 [en línea]<br /> __se_sys_exit_group kernel/exit.c:1121 [en línea]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121<br /> x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea]<br /> do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x44f639<br /> Código: No se pueden acceder a los bytes del código de operación en 0x44f60f.<br /> RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br /> <br /> <br /> Dado que las opciones de montaje de rescate marcarán el fs completo como de solo lectura, no debería activarse ninguna nueva transacción.<br /> <br /> Pero durante el desmontaje expulsaremos todos los inodos, lo que puede activar una nueva transacción, y activa advertencias en un fs fuertemente corrupto.<br /> <br /> [CAUSA]<br /> Btrfs permite nuevas transacciones incluso en un fs de solo lectura, esto es para permitir que la reproducción del registro ocurra incluso en montajes de solo lectura, al igual que lo hacen ext4/xfs.<br /> <br /> Sin embargo, con las opciones de montaje de rescate, el fs es completamente de solo lectura y no puede ser remontado como lectura-escritura, por lo tanto, en ese caso también deberíamos rechazar cualquier nueva transacción.<br /> <br /> [SOLUCIÓN]<br /> Si encontramos que el fs tiene opciones de montaje de rescate, deberíamos tratar el fs como un error, para que no se pueda iniciar ninguna nueva transacción.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amd/pm: Deshabilitar el acceso MMIO durante el reinicio del Modo 1 de SMU<br /> <br /> Durante el reinicio del Modo 1, el ASIC se somete a un ciclo de reinicio y se vuelve temporalmente inaccesible a través de PCIe. Cualquier intento de acceder a los registros MMIO durante esta ventana (por ejemplo, desde manejadores de interrupciones u otros hilos del controlador) puede resultar en transacciones PCIe incompletas, lo que lleva a pánicos NMI o cuelgues del sistema.<br /> <br /> Para evitar esto, establecer la bandera &amp;#39;no_hw_access&amp;#39; en verdadero inmediatamente después de activar el reinicio. Esto indica a otros componentes del controlador que omitan los accesos a registros mientras el dispositivo está fuera de línea.<br /> <br /> Se añade una barrera de memoria &amp;#39;smp_mb()&amp;#39; para asegurar que la actualización de la bandera sea globalmente visible para todos los núcleos antes de que el controlador entre en el estado de suspensión/espera.<br /> <br /> (seleccionado de la confirmación 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bonding: anotar condiciones de carrera de datos alrededor de slave-&amp;gt;last_rx<br /> <br /> slave-&amp;gt;last_rx y slave-&amp;gt;target_last_arp_rx[...] pueden ser leídos y escritos sin bloqueo. Añadir anotaciones READ_ONCE() y WRITE_ONCE().<br /> <br /> syzbot informó:<br /> <br /> ERROR: KCSAN: condición de carrera de datos en bond_rcv_validate / bond_rcv_validate<br /> <br /> escritura en 0xffff888149f0d428 de 8 bytes por interrupción en la CPU 1:<br /> bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335<br /> bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533<br /> __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039<br /> __netif_receive_skb_one_core net/core/dev.c:6150 [inline]<br /> __netif_receive_skb+0x59/0x270 net/core/dev.c:6265<br /> netif_receive_skb_internal net/core/dev.c:6351 [inline]<br /> netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410<br /> ...<br /> <br /> escritura en 0xffff888149f0d428 de 8 bytes por interrupción en la CPU 0:<br /> bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335<br /> bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533<br /> __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039<br /> __netif_receive_skb_one_core net/core/dev.c:6150 [inline]<br /> __netif_receive_skb+0x59/0x270 net/core/dev.c:6265<br /> netif_receive_skb_internal net/core/dev.c:6351 [inline]<br /> netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410<br /> br_netif_receive_skb net/bridge/br_input.c:30 [inline]<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ...<br /> <br /> valor cambiado: 0x0000000100005365 -&amp;gt; 0x0000000100005366

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm, swap: restaurar el atributo swap_space para evitar un kernel panic<br /> <br /> El commit 8b47299a411a (&amp;#39;mm, swap: marcar el espacio de direcciones de swap como ro y añadir verificación de depuración de contexto&amp;#39;) hizo que el espacio de direcciones de swap fuera de solo lectura. Esto puede llevar a un kernel panic si arch_prepare_to_swap devuelve un fallo bajo una fuerte presión de memoria, como sigue,<br /> <br /> el1_abort+0x40/0x64<br /> el1h_64_sync_handler+0x48/0xcc<br /> el1h_64_sync+0x84/0x88<br /> errseq_set+0x4c/0xb8 (P)<br /> __filemap_set_wb_err+0x20/0xd0<br /> shrink_folio_list+0xc20/0x11cc<br /> evict_folios+0x1520/0x1be4<br /> try_to_shrink_lruvec+0x27c/0x3dc<br /> shrink_one+0x9c/0x228<br /> shrink_node+0xb3c/0xeac<br /> do_try_to_free_pages+0x170/0x4f0<br /> try_to_free_pages+0x334/0x534<br /> __alloc_pages_direct_reclaim+0x90/0x158<br /> __alloc_pages_slowpath+0x334/0x588<br /> __alloc_frozen_pages_noprof+0x224/0x2fc<br /> __folio_alloc_noprof+0x14/0x64<br /> vma_alloc_zeroed_movable_folio+0x34/0x44<br /> do_pte_missing+0xad4/0x1040<br /> handle_mm_fault+0x4a4/0x790<br /> do_page_fault+0x288/0x5f8<br /> do_translation_fault+0x38/0x54<br /> do_mem_abort+0x54/0xa8<br /> <br /> Restaurar el espacio de direcciones de swap como no ro para evitar el pánico.

El plugin Advanced AJAX Product Filters para WordPress es vulnerable a la inyección de objetos PHP en todas las versiones hasta la 3.1.9.6, inclusive, a través de la deserialización de entrada no confiable en la función shortcode_check dentro de la capa de compatibilidad de Live Composer. Esto hace posible que atacantes autenticados, con acceso de nivel de Autor y superior, inyecten un objeto PHP. No hay una cadena POP conocida presente en el software vulnerable, lo que significa que esta vulnerabilidad no tiene impacto a menos que otro plugin o tema que contenga una cadena POP esté instalado en el sitio. Si una cadena POP está presente a través de un plugin o tema adicional instalado en el sistema objetivo, puede permitir al atacante realizar acciones como eliminar archivos arbitrarios, recuperar datos sensibles o ejecutar código dependiendo de la cadena POP presente. Nota: Esta vulnerabilidad requiere que el plugin Live Composer también esté instalado y activo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: iwlwifi: Implementar settime64 como un stub para PTP de MVM/MLD<br /> <br /> Desde el commit dfb073d32cac (&amp;#39;ptp: Devolver -EINVAL en ptp_clock_register si las operaciones requeridas son NULL&amp;#39;), se requiere que el reloj PTP registrado a través de ptp_clock_register tenga ptp_clock_info.settime64 establecido; sin embargo, ni la implementación del reloj PTP de MVM ni la de MLD lo establecen, lo que resulta en advertencias cuando la interfaz se inicia, como<br /> <br /> WARNING: drivers/ptp/ptp_clock.c:325 at ptp_clock_register+0x2c8/0x6b8, CPU#1: wpa_supplicant/469<br /> CPU: 1 UID: 0 PID: 469 Comm: wpa_supplicant Not tainted 6.18.0+ #101 PREEMPT(full)<br /> ra: ffff800002732cd4 iwl_mvm_ptp_init+0x114/0x188 [iwlmvm]<br /> ERA: 9000000002fdc468 ptp_clock_register+0x2c8/0x6b8<br /> iwlwifi 0000:01:00.0: Failed to register PHC clock (-22)<br /> <br /> No encuentro una interfaz de firmware apropiada para implementar settime64() para iwlwifi MLD/MVM, por lo tanto, en su lugar, creo un stub que solo devuelve -EOPTNOTSUPP, suprimiendo la advertencia y permitiendo que el reloj PTP sea registrado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> LoongArch: Establecer el protection_map[] correcto para VM_NONE/VM_SHARED<br /> <br /> Para plataformas de 32 bits, _PAGE_PROTNONE es 0, por lo que establecer un VMA como VM_NONE o VM_SHARED hará que las páginas no estén presentes, lo que luego causará un Oops con un fallo de página del kernel.<br /> <br /> Solucionarlo al establecer el protection_map[] correcto para VM_NONE/VM_SHARED, reemplazando _PAGE_PROTNONE con _PAGE_PRESENT.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mac80211: no advertir para conexiones en canales inválidos<br /> <br /> No está claro (para mí) cómo exactamente syzbot logró activar esto,<br /> pero parece concebible que, por ejemplo, la regulación cambió y ha<br /> deshabilitado un canal entre el escaneo (se verifica que el canal sea<br /> utilizable por cfg80211_get_ies_channel_number) y la conexión en<br /> el canal más tarde.<br /> <br /> Con un escenario que no está cubierto en otro lugar descrito anteriormente,<br /> la advertencia no es buena, reemplázala con un mensaje de error (más informativo).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> md: suspender el array mientras se actualiza raid_disks a través de sysfs<br /> <br /> En raid1_reshape(), se llama a freeze_array() antes de modificar el pool de memoria r1bio (conf-&amp;gt;r1bio_pool) y conf-&amp;gt;raid_disks, y se llama a unfreeze_array() después de que se completa la actualización.<br /> <br /> Sin embargo, freeze_array() solo espera hasta que nr_sync_pending y (nr_pending - nr_queued) de todos los buckets lleguen a cero. Cuando ocurre un error de E/S, nr_queued se incrementa y el r1bio correspondiente se encola en retry_list o bio_end_io_list. Como resultado, freeze_array() puede desbloquearse antes de que estos r1bios sean liberados.<br /> <br /> Esto puede llevar a una situación en la que conf-&amp;gt;raid_disks y el mempool ya han sido actualizados mientras que los r1bios encolados, asignados con el valor antiguo de raid_disks, son liberados posteriormente. En consecuencia, free_r1bio() puede acceder a memoria fuera de los límites en put_all_bios() y liberar r1bios de tamaño incorrecto al nuevo mempool, lo que podría causar problemas también con el mempool.<br /> <br /> Dado que solo la E/S normal podría aumentar nr_queued mientras ocurre un error de E/S, suspender el array evita este problema.<br /> <br /> Nota: La actualización de raid_disks a través de ioctl SET_ARRAY_INFO ya suspende el array. Por lo tanto, suspendemos el array al actualizar raid_disks a través de sysfs para evitar este problema también.

El plugin Ultimate Member – User Profile, Registration, Login, Member Directory, Content Restriction &amp;amp; Membership Plugin para WordPress es vulnerable a cross-site scripting reflejado a través de los parámetros de filtro (por ejemplo, &amp;#39;filter_first_name&amp;#39;) en todas las versiones hasta la 2.11.1, inclusive, debido a una sanitización de entrada y un escape de salida insuficientes. Esto permite a los atacantes no autenticados inyectar scripts web arbitrarios en páginas que se ejecutan si logran engañar a un usuario para que realice una acción como hacer clic en un enlace.

Existe una vulnerabilidad de ejecución de código arbitrario en la funcionalidad de directiva Code Stream de OpenCFD OpenFOAM 2506. Un archivo de simulación de OpenFOAM especialmente diseñado puede conducir a la ejecución de código arbitrario. Un atacante puede proporcionar un archivo malicioso para activar esta vulnerabilidad.