Vulnerabilidades

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 /> 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 /> scsi: target: iscsi: Corrección de uso después de liberación en iscsit_dec_conn_usage_count()<br /> <br /> En iscsit_dec_conn_usage_count(), la función llama a complete() mientras mantiene el conn-&amp;gt;conn_usage_lock. Tan pronto como se invoca complete(), el proceso en espera (como iscsit_close_connection()) puede despertarse y proceder a liberar la estructura iscsit_conn.<br /> <br /> Si el proceso en espera libera la memoria antes de que el hilo actual alcance spin_unlock_bh(), resulta en un KASAN slab-uso después de liberación, ya que la función intenta liberar un bloqueo dentro de la estructura de conexión ya liberada.<br /> <br /> Esto se corrige liberando el spinlock antes de llamar a complete().

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 /> 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.

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 /> 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 /> 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.

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.

Vulnerabilidad de salto de ruta en el servicio web AMR Printer Management 1.01 Beta, que permite a atacantes remotos leer archivos arbitrarios del sistema Windows subyacente mediante el uso de secuencias de salto de ruta especialmente diseñadas en solicitudes dirigidas al servicio de gestión web. El servicio es accesible sin autenticación y se ejecuta con privilegios elevados, amplificando el impacto de la vulnerabilidad. Un atacante puede explotar esta condición para acceder a archivos sensibles y privilegiados en el sistema utilizando cargas útiles de salto de ruta. La explotación exitosa de esta vulnerabilidad podría conducir a la divulgación no autorizada de información interna del sistema, comprometiendo la confidencialidad del entorno afectado.

Se ha identificado una debilidad en huggingface smolagents 1.24.0. Afecta a la función requests.get/requests.post del componente LocalPythonExecutor. La ejecución de una manipulación puede conducir a una falsificación de petición del lado del servidor. Es posible lanzar el ataque remotamente. El exploit se ha puesto a disposición del público y podría ser utilizado para ataques. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió de ninguna manera.