Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommu/mediatek: corregir uso después de liberación en el aplazamiento de la detección<br /> <br /> El controlador está liberando las referencias tomadas a los dispositivos larb durante la detección después de una búsqueda exitosa, así como en caso de errores. Esto puede conducir potencialmente a un uso después de liberación en caso de que un dispositivo larb aún no se haya vinculado a su controlador, de modo que la detección del controlador iommu se aplace.<br /> <br /> Corregir esto al mantener las referencias como se espera mientras el controlador iommu está vinculado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> shmem: corrige la recuperación en fallos de renombrado<br /> <br /> Las inserciones de maple_tree pueden fallar si tenemos una escasez grave de memoria; simple_offset_rename() no se recupera bien si se encuentra con eso. Lo mismo ocurre con simple_offset_rename_exchange().<br /> <br /> Además, shmem_whiteout() espera que, si tiene éxito, el llamador avance a d_move(), es decir, que shmem_rename2() no falle después de la llamada exitosa de shmem_whiteout().<br /> <br /> No es difícil de arreglar, afortunadamente: mtree_store() no puede fallar si el índice en el que estamos intentando almacenar ya está presente en el árbol como un singleton.<br /> <br /> Para simple_offset_rename_exchange() eso es suficiente; solo necesitamos tener cuidado con el orden de las operaciones.<br /> <br /> Para simple_offset_rename() la solución es preinsertar el objetivo en el árbol para new_dir; el resto se puede hacer sin ninguna operación que pueda fallar.<br /> <br /> Esa preinserción tiene que hacerse en shmem_rename2() en lugar de en simple_offset_rename() mismo; de lo contrario, necesitaríamos lidiar con la posibilidad de fallo después de un shmem_whiteout() exitoso.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Input: lkkbd - deshabilitar el trabajo pendiente antes de liberar el dispositivo<br /> <br /> lkkbd_interrupt() programa lk-&amp;gt;tq a través de schedule_work(), y el manejador de trabajo lkkbd_reinit() desreferencia la estructura lkkbd y sus campos serio/input_dev.<br /> <br /> lkkbd_disconnect() y las rutas de error en lkkbd_connect() liberan la estructura lkkbd sin evitar que el trabajo de reinicio sea encolado de nuevo hasta que serio_close() retorne. Esto puede permitir que el manejador de trabajo se ejecute después de que la estructura haya sido liberada, lo que lleva a un potencial uso después de liberación.<br /> <br /> Usar disable_work_sync() en lugar de cancel_work_sync() para asegurar que el trabajo de reinicio no pueda ser reencolado, y llamarlo tanto en lkkbd_disconnect() como en las rutas de error de lkkbd_connect() después de serio_open().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> functionfs: corregir las condiciones de carrera de apertura/eliminación<br /> <br /> ffs_epfile_open() puede entrar en condición de carrera con la eliminación, lo que resulta en que file-&amp;gt;private_data apunte a un objeto liberado.<br /> <br /> Existe un recuento total de archivos abiertos en functionfs (tanto ep0 como los dinámicos) y cuando llega a cero, los archivos dinámicos se eliminan. Desafortunadamente, esa eliminación puede ocurrir mientras otro hilo está en ffs_epfile_open(), pero aún no ha incrementado el recuento. En ese caso, la apertura tendrá éxito, dejándonos con UAF en cualquier read() o write() posterior.<br /> <br /> La causa raíz es que ffs-&amp;gt;opened se utiliza incorrectamente; atomic_dec_and_test() frente a atomic_add_return() no es una buena idea cuando el objeto permanece visible todo el tiempo.<br /> <br /> Para desenredar eso<br /> * serializar los abridores en ffs-&amp;gt;mutex (tanto para ep0 como para archivos dinámicos)<br /> * hacer que los dinámicos usen atomic_inc_not_zero() y fallen si teníamos cero -&amp;gt;opened; en ese caso, el archivo que estamos abriendo está condenado.<br /> * hacer que los inodos de los archivos dinámicos se marquen al eliminarse (desde la devolución de llamada de simple_recursive_removal()) - borrar -&amp;gt;i_private allí.<br /> * hacer que la apertura de los dinámicos verifique que no hayan sido ya eliminados, junto con la comprobación de que el estado es FFS_ACTIVE.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: aic94xx: corrección de uso después de liberación en la ruta de eliminación de dispositivo<br /> <br /> La función asd_pci_remove() no logra sincronizarse con los tasklets pendientes antes de liberar la estructura asd_ha, lo que lleva a una potencial vulnerabilidad de uso después de liberación.<br /> <br /> Cuando se activa la eliminación de un dispositivo (mediante desconexión en caliente o descarga de módulo), puede ocurrir una condición de carrera.<br /> <br /> La corrección añade tasklet_kill() antes de liberar la estructura asd_ha, asegurando que todos los tasklets programados se completen antes de que continúe la limpieza.

En el núcleo de Linux, se ha solucionado la siguiente vulnerabilidad: ntfs: se establece un tamaño de bloque ficticio para leer boot_block al montar. Al montar, se utiliza sb-&amp;gt;s_blocksize para leer boot_block sin que esté definido ni validado. Establecer un tamaño de bloque ficticio antes de intentar leer el boot_block. El problema se puede reproducir con el siguiente código de Syz: mkdirat(0xffffffffffffff9c, &amp;amp;(0x7f0000000080)=“./file1\x00”, 0x0) r4 = openat$nullb(0xffffffffffffff9c, &amp;amp;(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &amp;amp;(0x7f0000000980)=0x4000) mount(&amp;amp;(0x7f0000000140)=@nullb, &amp;amp;(0x7f0000000040)=&amp;#39;./ cgroup\x00&amp;#39;, &amp;amp;(0x7f0000000000)=“ntfs3\x00”, 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0) Aquí, el ioctl establece el tamaño de bloque de bdev en 16384. Durante el montaje, get_tree_bdev_flags() llama a sb_set_blocksize(sb, block_size(bdev)), pero dado que block_size(bdev) &amp;gt; PAGE_SIZE, sb_set_blocksize() deja sb-&amp;gt;s_blocksize en cero. Más tarde, ntfs_init_from_boot() intenta leer el boot_block mientras sb-&amp;gt;s_blocksize sigue siendo cero, lo que desencadena el error. [almaz.alexandrovich@paragon-software.com: se ha cambiado el estilo de los comentarios y se ha añadido el manejo del valor de retorno]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: invalidar la caché de dentry en la creación fallida de whiteout<br /> <br /> F2FS puede montar sistemas de archivos con valores de profundidad de directorio corruptos que se ajustan en tiempo de ejecución a MAX_DIR_HASH_DEPTH. Cuando se realizan operaciones RENAME_WHITEOUT en dichos directorios, f2fs_rename realiza modificaciones de directorio (actualizando la entrada de destino y eliminando la entrada de origen) antes de intentar añadir la entrada de whiteout a través de f2fs_add_link.<br /> <br /> Si f2fs_add_link falla debido a la estructura de directorio corrupta, la función devuelve un error a VFS, pero las modificaciones parciales del directorio ya se han confirmado en el disco. VFS asume que toda la operación de renombrado falló y no actualiza la caché de dentry, dejando mapeos obsoletos.<br /> <br /> En la ruta de error, VFS no llama a d_move() para actualizar la caché de dentry. Esto resulta en que new_dentry sigue apuntando al antiguo inodo (new_inode) al que ya se le ha decrementado su i_nlink a cero. La caché obsoleta causa que las operaciones subsiguientes referencien incorrectamente el inodo liberado.<br /> <br /> Esto hace que las operaciones subsiguientes utilicen información de dentry en caché que ya no coincide con el estado en disco. Cuando un segundo renombrado apunta a la misma entrada, VFS intenta decrementar i_nlink en el inodo obsoleto, que ya puede tener i_nlink=0, lo que activa una ADVERTENCIA en drop_nlink().<br /> <br /> Secuencia de ejemplo:<br /> 1. Primer renombrado (RENAME_WHITEOUT): file2 ? file1<br /> - f2fs actualiza la entrada file1 en disco (apunta al inodo 8)<br /> - f2fs elimina la entrada file2 en disco<br /> - f2fs_add_link(whiteout) falla (directorio corrupto)<br /> - Devuelve error a VFS<br /> - VFS no llama a d_move() debido al error<br /> - La caché de VFS todavía tiene: file1 ? inodo 7 (¡obsoleto!)<br /> - el inodo 7 tiene i_nlink=0 (ya decrementado)<br /> <br /> 2. Segundo renombrado: file3 ? file1<br /> - VFS usa caché obsoleta: file1 ? inodo 7<br /> - Intenta drop_nlink en el inodo 7 (i_nlink ya es 0)<br /> - ADVERTENCIA en drop_nlink()<br /> <br /> Solucione esto invalidando explícitamente old_dentry y new_dentry cuando f2fs_add_link falla durante la creación de whiteout. Esto fuerza a VFS a actualizarse desde el disco en operaciones subsiguientes, asegurando la consistencia de la caché incluso cuando el renombrado tiene éxito parcialmente.<br /> <br /> Reproductor:<br /> 1. Monte la imagen F2FS con i_current_depth corrupto<br /> 2. renameat2(file2, file1, RENAME_WHITEOUT)<br /> 3. renameat2(file3, file1, 0)<br /> 4. El sistema activa una ADVERTENCIA en drop_nlink()

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ublk: limpiar referencias de copia de usuario al salir el servidor ublk<br /> <br /> Si un proceso de servidor ublk libera un archivo de dispositivo de caracteres ublk, cualquier solicitud despachada al servidor ublk pero aún no completada retendrá un valor de referencia de UBLK_REFCOUNT_INIT. Antes del commit e63d2228ef83 (&amp;#39;ublk: simplificar la anulación de solicitud ublk&amp;#39;), __ublk_fail_req() decrementaría el contador de referencias antes de completar la solicitud fallida. Sin embargo, ese commit optimizó __ublk_fail_req() para llamar directamente a __ublk_complete_rq() sin decrementar el contador de referencias de la solicitud.<br /> El contador de referencias filtrado permite incorrectamente operaciones de copia de usuario y copia cero en la solicitud ublk completada. También activa las advertencias WARN_ON_ONCE(refcount_read(&amp;amp;io-&amp;gt;ref)) en ublk_queue_reinit() y ublk_deinit_queue().<br /> El commit c5c5eb24ed61 (&amp;#39;ublk: evitar que se llame a ublk_io_release() después de cerrar el dispositivo de caracteres ublk&amp;#39;) ya solucionó el problema para dispositivos ublk que utilizan UBLK_F_SUPPORT_ZERO_COPY o UBLK_F_AUTO_BUF_REG. Sin embargo, la fuga del contador de referencias también afecta a UBLK_F_USER_COPY, el otro modo de copia de datos con contador de referencias. Corregir la condición en ublk_check_and_reset_active_ref() para incluir todos los modos de copia de datos con contador de referencias. Esto asegura que cualquier solicitud ublk aún propiedad del servidor ublk cuando este sale tenga sus contadores de referencias restablecidos a 0.

Tenda AX-1806 v1.0.0.1 se descubrió que contenía un desbordamiento de pila en el parámetro security_5g de la función sub_4CA50. Esta vulnerabilidad permite a los atacantes causar una denegación de servicio (DoS) a través de una solicitud manipulada.

Se descubrió que Tenda AX-3 v16.03.12.10_CN contenía un desbordamiento de pila en el parámetro mac2 de la función fromAdvSetMacMtuWan. Esta vulnerabilidad permite a los atacantes provocar una denegación de servicio (DoS) mediante una solicitud manipulada.

Se descubrió que Tenda AX-3 v16.03.12.10_CN contenía un desbordamiento de pila en el parámetro serviceName2 de la función fromAdvSetMacMtuWan. Esta vulnerabilidad permite a los atacantes causar una denegación de servicio (DoS) mediante una solicitud manipulada.

Se descubrió que Tenda AX-3 v16.03.12.10_CN contenía un desbordamiento de pila en el parámetro cloneType2 de la función fromAdvSetMacMtuWan. Esta vulnerabilidad permite a los atacantes causar una denegación de servicio (DoS) mediante una solicitud manipulada.