Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige una desreferencia de puntero NULL cuando no se puede iniciar una nueva transacción [ERROR] Syzbot informó una desreferencia de puntero NULL con el siguiente bloqueo: FAULT_INJECTION: forzando un fallo. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... Información de BTRFS (dispositivo loop0): balance: finalizado con estado: -12 Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Seguimiento de llamadas: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [en línea] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] El fallo de asignación ocurre en start_transaction() dentro de prepare_to_relocate(), y durante el manejo de errores llamamos a unset_reloc_control(), lo que hace que fs_info->balance_ctl sea NULL. Luego continuamos con la limpieza de la ruta de error en btrfs_balance() llamando a reset_balance_state() que llamará a del_balance_item() para eliminar por completo el elemento de balance en el árbol raíz. Sin embargo, durante la pequeña ventana entre set_reloc_contrl() y unset_reloc_control(), podemos tener una actualización del árbol de subvolumen y crear un reloc_root para ese subvolumen. Luego pasamos a la btrfs_commit_transaction() final de del_balance_item() y a btrfs_update_reloc_root() dentro de commit_fs_roots(). Esa función verifica si fs_info->reloc_ctl está en la etapa merge_reloc_tree, pero dado que fs_info->reloc_ctl es NULL, da como resultado una desreferencia de puntero NULL. [SOLUCIÓN] Solo hay que añadir una comprobación adicional en fs_info->reloc_ctl dentro de btrfs_update_reloc_root(), antes de comprobar fs_info->reloc_ctl->merge_reloc_tree. El manejo de DEAD_RELOC_TREE sirve para evitar modificaciones adicionales del árbol de reubicación durante la etapa de fusión, pero como no hay ningún reloc_ctl, no tenemos que preocuparnos por eso.

Una vulnerabilidad de cross-site scripting (XSS) almacenado en el componente HikaShop Joomla anterior a la versión 5.1.1 permite a atacantes remotos ejecutar código JavaScript arbitrario en el navegador web de un usuario, mediante la inclusión de una carga maliciosa en el parámetro `description` de cualquier producto. El parámetro `description` no se desinfecta en el backend.

Nginx UI es una interfaz de usuario web para el servidor web Nginx. Nginx UI v2.0.0-beta.35 y anteriores obtienen el valor del campo json sin verificación y pueden construir un valor en forma de `../../`. Se pueden escribir archivos arbitrarios en el servidor, lo que puede provocar la pérdida de permisos. La versión 2.0.0-beta.26 corrige el problema.

Nginx UI es una interfaz de usuario web para el servidor web Nginx. Antes de la versión 2.0.0-beta.36, la ruta de registro de nginxui era controlable. Este problema se puede combinar con el recorrido del directorio en `/api/configs` para leer directorios y contenidos de archivos en el servidor. La versión 2.0.0-beta.36 soluciona el problema.

Nginx UI es una interfaz de usuario web para el servidor web Nginx. Antes de la versión 2.0.0-beta.36, cuando Nginx UI configura logrotate, no verifica la entrada y la pasa directamente a exec.Command, lo que provoca la ejecución arbitraria de comandos. La versión 2.0.0-beta.36 corrige este problema.

secp256k1-node es un enlace de Node.js para una librería C optimizada para operaciones EC en la curva secp256k1. En la versión basada en `elliptic`, `loadUncompressedPublicKey` tiene una comprobación de que la clave pública está en la curva. Sin embargo, antes de las versiones 5.0.1, 4.0.4 y 3.8.1, `loadCompressedPublicKey` no tiene esa comprobación. Eso permite al atacante usar claves públicas en curvas de baja cardinalidad para extraer suficiente información para restaurar completamente la clave privada a partir de tan solo 11 sesiones ECDH, y de manera muy económica en cuanto a potencia de cómputo. Otras operaciones en claves públicas también se ven afectadas, incluyendo, por ejemplo, `publicKeyVerify()` que devuelve incorrectamente `true` en esas claves no válidas, y, por ejemplo, `publicKeyTweakMul()` que también devuelve resultados predecibles que permiten restaurar el ajuste. Las versiones 5.0.1, 4.0.4 y 3.8.1 contienen una solución para el problema.

El índice prepareUnique puede provocar que los secundarios se bloqueen debido a la aplicación incorrecta de restricciones de índice en los secundarios, lo que en casos extremos puede provocar que varios secundarios se bloqueen y no haya primarios. Este problema afecta a las versiones de MongoDB Server v6.0 anteriores a la 6.0.17, a las versiones de MongoDB Server v7.0 anteriores a la 7.0.13 y a las versiones de MongoDB Server v7.3 anteriores a la 7.3.4.

OneDev es un servidor Git con CI/CD, kanban y paquetes. Una vulnerabilidad en versiones anteriores a la 11.0.9 permite que usuarios no autenticados lean archivos arbitrarios a los que puede acceder el proceso del servidor OneDev. Este problema se ha solucionado en la versión 11.0.9.

Se encontró una vulnerabilidad de use after free en la emulación del adaptador de bus host SCSI QEMU LSI53C895A. Este problema puede provocar un bloqueo o un escape de la máquina virtual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: establece el cifrado para el rango NDP seguro El puntero de cifrado no está establecido, pero se anula la referencia al intentar establecer su contenido, lo que genera una anulación de la referencia del puntero NULL. Solucione el problema apuntando al parámetro de cifrado antes de anular la referencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powercap: intel_rapl: Arreglo de un byte en get_rpi() La matriz rp->priv->rpi es rpi_msr o rpi_tpmi, que tienen una cantidad de elementos NR_RAPL_PRIMITIVES. Por lo tanto, el > debe ser >= para evitar un acceso de un byte.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arregla las escrituras del ayudante en mapas de solo lectura Lonial encontró un problema que a pesar del mapa BPF congelado del lado del usuario y del BPF (como en el caso de .rodata), aún era posible escribir en él desde el lado del programa BPF a través de ayudantes específicos que tienen ARG_PTR_TO_{LONG,INT} como argumentos. En check_func_arg() cuando el argumento es como se menciona, el meta->raw_mode nunca se establece. Más tarde, check_helper_mem_access(), bajo el caso de PTR_TO_MAP_VALUE como tipo base de registro, asume BPF_READ para la llamada posterior a check_map_access_type() y dado que el mapa BPF es de solo lectura, tiene éxito. Los ayudantes realmente necesitan ser anotados como ARG_PTR_TO_{LONG,INT} | MEM_UNINIT cuando los resultados se escriben en ellos en lugar de leerse de ellos. Este último indica que está bien pasar un puntero a la memoria no inicializada, ya que la memoria se escribe de todos modos. Sin embargo, ARG_PTR_TO_{LONG,INT} es un caso especial de ARG_PTR_TO_FIXED_SIZE_MEM solo que con un requisito de alineación adicional. Por lo tanto, es mejor deshacerse de los casos especiales ARG_PTR_TO_{LONG,INT} por completo y reutilizar los tipos de memoria de tamaño fijo. Para esto, agregue MEM_ALIGNED para garantizar adicionalmente la alineación dado que estos ayudantes escriben directamente en los argumentos a través de * = val. El .arg*_size se ha inicializado reflejando el tamaño real de (*). MEM_ALIGNED solo se puede usar en combinación con los tipos de argumentos anotados MEM_FIXED_SIZE, ya que en los casos !MEM_FIXED_SIZE el verificador no conoce el tamaño del búfer a priori y, por lo tanto, no puede escribir ciegamente * = val.