Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm: No permitir que el espacio de usuario active advertencias del kernel en drm_gem_change_handle_ioctl()<br /> <br /> Dado que los identificadores GEM bo son u32 en la uapi y la implementación interna utiliza idr_alloc() que usa rangos int, pasar un nuevo identificador mayor que INT_MAX desencadena trivialmente una advertencia del kernel:<br /> <br /> idr_alloc():<br /> ...<br /> if (WARN_ON_ONCE(start &amp;lt; 0))<br /> return -EINVAL;<br /> ...<br /> <br /> Se soluciona rechazando los nuevos identificadores superiores a INT_MAX y al mismo tiempo haciendo más obvio el cálculo del límite final al moverlo al dominio int.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> firewire: core: corrige condición de carrera contra la lista de transacciones<br /> <br /> La lista de transacciones se enumera sin adquirir el bloqueo de la tarjeta al procesar el evento de respuesta AR. Esto causa un error de condición de carrera al procesar el evento de finalización de solicitud AT concurrentemente.<br /> <br /> Este commit corrige el error al poner el inicio del temporizador para la expiración de transacciones divididas dentro del alcance del bloqueo. Se consulta el valor de jiffies en la estructura de la tarjeta antes de adquirir el bloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpio: virtuser: corregir uso después de liberación en la ruta de liberación de configfs<br /> <br /> La ruta de liberación de configfs de gpio-virtuser usa guard(mutex) para proteger la estructura del dispositivo. Sin embargo, el dispositivo es liberado antes de que se ejecute la limpieza del guard, causando que mutex_unlock() opere sobre memoria liberada.<br /> <br /> Específicamente, gpio_virtuser_device_config_group_release() destruye el mutex y libera el dispositivo mientras aún está dentro del ámbito de guard(mutex). Cuando la función retorna, la limpieza del guard invoca mutex_unlock(&amp;amp;dev-&amp;gt;lock), resultando en un uso después de liberación de slab.<br /> <br /> Limitar la vida útil del mutex usando un scoped_guard() solo alrededor de la verificación de activación, para que el bloqueo sea liberado antes de que se llamen a mutex_destroy() y kfree().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> efivarfs: corrección de la propagación de errores en efivar_entry_get()<br /> <br /> efivar_entry_get() siempre devuelve éxito incluso si la función subyacente __efivar_entry_get() falla, enmascarando errores.<br /> <br /> Esto puede resultar en que memoria de pila no inicializada sea copiada al espacio de usuario en la ruta de efivarfs_file_read().<br /> <br /> Se soluciona devolviendo el error desde __efivar_entry_get().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): corregir mensaje de error<br /> <br /> Desde el commit 79a6d1bfe114 (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): desanclar URL en error de usb_submit_urb()&amp;#39;), un URB de reenvío fallido imprimirá un mensaje de información.<br /> <br /> En el caso de una lectura corta donde netdev aún no ha sido asignado, inicializar como NULL para evitar desreferenciar un valor indefinido. También informar el valor de error del reenvío fallido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: corrige la segmentación de reenvío de fraglist GRO<br /> <br /> Este parche mejora el manejo de segmentos GSO al verificar correctamente el flag SKB_GSO_DODGY para paquetes GSO con frag_list, abordando problemas de bajo rendimiento observados cuando una estación accede a servidores IPv4 a través de hotspots con una interfaz upstream solo IPv6.<br /> <br /> Específicamente, corrige un error en la segmentación GSO al reenviar paquetes GRO que contienen un frag_list. La función skb_segment_list no puede procesar correctamente los skbs GRO que han sido convertidos por XLAT, ya que XLAT solo traduce la cabecera del skb principal. Consecuentemente, los skbs en el frag_list pueden permanecer sin traducir, lo que resulta en inconsistencias de protocolo y un rendimiento reducido.<br /> <br /> Para abordar esto, el parche establece explícitamente el flag SKB_GSO_DODGY para paquetes GSO en los helpers de traducción de protocolo IPv4/IPv6 de XLAT (bpf_skb_proto_4_to_6 y bpf_skb_proto_6_to_4). Esto marca los paquetes GSO como potencialmente modificados después de la traducción de protocolo. Como resultado, la segmentación GSO evitará usar skb_segment_list y en su lugar recurrirá a skb_segment para paquetes con el flag SKB_GSO_DODGY. Esto asegura que solo los paquetes frag_list seguros y completamente traducidos sean procesados por skb_segment_list, resolviendo inconsistencias de protocolo y mejorando el rendimiento al reenviar paquetes GRO convertidos por XLAT.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: btrfs: no requerir estrictamente el umbral de metadatos sucios para la escritura de páginas de metadatos [ERROR] Existe un informe interno de que más de 1000 procesos están esperando en el io_schedule_timeout() de balance_dirty_pages(), causando un cuelgue del sistema y desencadenando un volcado de memoria del kernel. El kernel está basado en el kernel v6.4, pero el problema raíz todavía se aplica a cualquier kernel upstream anterior a la v6.18. [CAUSA] De Jan Kara por su sabiduría sobre el comportamiento de balanceo de páginas sucias primero. Este límite de suciedad del cgroup era lo que realmente estaba desempeñando el papel aquí porque el cgroup tenía solo una pequeña cantidad de memoria y por lo tanto el límite de suciedad para él era de aproximadamente 16MB. La limitación de suciedad es responsable de asegurar que nadie pueda ensuciar (significativamente) más memoria sucia de lo que hay de límite de suciedad. Así, cuando una tarea está ensuciando páginas, entra periódicamente en balance_dirty_pages() y la dejamos dormir allí para ralentizar el ensuciamiento. Cuando el sistema ya está por encima del límite de suciedad (ya sea globalmente o dentro de un cgroup de la tarea en ejecución), no permitiremos que la tarea salga de balance_dirty_pages() hasta que el número de páginas sucias caiga por debajo del límite. Así que en este caso particular, como ya mencioné, había un cgroup con una cantidad de memoria relativamente pequeña y como resultado con un límite de suciedad establecido en 16MB. Una tarea de ese cgroup ha ensuciado páginas por un valor de aproximadamente 28MB en el inodo btree de btrfs y estas eran prácticamente las únicas páginas sucias en ese cgroup. Así que eso significa que la única forma de reducir las páginas sucias de ese cgroup es realizar el writeback de las páginas sucias del inodo btree de btrfs, y solo después de eso esos procesos pueden salir de balance_dirty_pages(). Ahora volviendo a la parte de btrfs, btree_writepages() es responsable de realizar el writeback de las páginas sucias del inodo btree. El problema aquí es que hay un umbral interno de btrfs que si los bytes sucios del inodo btree están por debajo del umbral de 32M, no realizará ningún writeback. Este comportamiento es para agrupar la mayor cantidad posible de metadatos para que no escribamos de vuelta esos bloques de árbol y luego los volvamos a copiar en escritura (re-COW) para otra modificación. Estos 32MiB internos son más altos que el tamaño de página sucia existente (28MiB), lo que significa que no se realizará ningún writeback, causando un interbloqueo entre btrfs y cgroup: - Btrfs no quiere realizar el writeback del inodo btree hasta que haya más páginas sucias - Cgroup/MM no quiere más páginas sucias para el inodo btree de btrfs Así, cualquier proceso que toque ese inodo btree es puesto a dormir hasta que el número de páginas sucias se reduzca. Muchas gracias a Jan Kara por el análisis de la causa raíz. [MEJORA] Desde el commit del kernel b55102826d7d (&amp;#39;btrfs: establecer AS_KERNEL_FILE en el btree_inode&amp;#39;), las páginas del inodo btree de btrfs solo se cargarán al cgroup raíz, el cual debería tener un límite mucho mayor que el umbral de 32MiB de btrfs. Así que no debería afectar a kernels más nuevos. Pero para todos los kernels LTS actuales, todos están afectados por este problema, y realizar un backport de todo el AS_KERNEL_FILE puede no ser una buena idea. Incluso para kernels más nuevos, sigo pensando que es una buena idea eliminar el umbral interno en btree_writepages(), ya que en la mayoría de los casos cgroup/MM tiene una mejor visión del uso de la memoria de todo el sistema que el umbral fijo de btrfs. Para los llamadores internos que usan btrfs_btree_balance_dirty(), ya que esa función ya está realizando una comprobación de umbral interna, ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: zlib: corregir la fuga de folio en la aceleración de hardware S390<br /> <br /> [BUG]<br /> Después del commit aa60fe12b4f4 (&amp;#39;btrfs: zlib: refactorizar la preparación del búfer de aceleración de hardware S390x&amp;#39;), ya no liberamos el folio de la caché de páginas del folio devuelto por btrfs_compress_filemap_get_folio() para la ruta de aceleración de hardware S390.<br /> <br /> [CAUSA]<br /> Antes de ese commit, llamábamos a kumap_local() y folio_put() después de manejar cada folio.<br /> <br /> Aunque el momento no es ideal (libera el folio anterior al principio del bucle y depende de una limpieza adicional fuera del bucle), al menos maneja la liberación del folio correctamente.<br /> <br /> Mientras que el código refactorizado es más fácil de leer, carece de la llamada para liberar el folio del filemap.<br /> <br /> [SOLUCIÓN]<br /> Añadir el folio_put() faltante para copy_data_into_buffer().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Bluetooth: hci_uart: corrección de desreferencia de puntero nulo en hci_uart_write_work<br /> <br /> hci_uart_set_proto() establece HCI_UART_PROTO_INIT antes de llamar a hci_uart_register_dev(), que llama a proto-&amp;gt;open() para inicializar hu-&amp;gt;priv. Sin embargo, si una activación de escritura TTY ocurre durante esta ventana, hci_uart_tx_wakeup() puede programar write_work antes de que hu-&amp;gt;priv sea inicializado, lo que lleva a una desreferencia de puntero NULL en hci_uart_write_work() cuando proto-&amp;gt;dequeue() accede a hu-&amp;gt;priv.<br /> <br /> La condición de carrera es:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> hci_uart_set_proto()<br /> set_bit(HCI_UART_PROTO_INIT)<br /> hci_uart_register_dev()<br /> activación de escritura tty<br /> hci_uart_tty_wakeup()<br /> hci_uart_tx_wakeup()<br /> schedule_work(&amp;amp;hu-&amp;gt;write_work)<br /> proto-&amp;gt;open(hu)<br /> // inicializa hu-&amp;gt;priv<br /> hci_uart_write_work()<br /> hci_uart_dequeue()<br /> proto-&amp;gt;dequeue(hu)<br /> // accede a hu-&amp;gt;priv (¡NULL!)<br /> <br /> Esto se soluciona moviendo set_bit(HCI_UART_PROTO_INIT) después de que proto-&amp;gt;open() se complete con éxito, asegurando que hu-&amp;gt;priv esté inicializado antes de que se pueda programar cualquier trabajo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> ext4: corregir la fuga de iloc.bh en ext4_xattr_inode_update_ref<br /> <br /> La rama de error para ext4_xattr_inode_update_ref olvidó liberar el refcount para iloc.bh. Esto se encontró al revisar el código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/damon/sysfs: limpieza de subdirectorios de attrs en caso de fallo en la configuración del directorio de contexto<br /> <br /> Cuando la configuración de un directorio sysfs de DAMON de contexto falla después de la configuración del directorio attrs/, los subdirectorios del directorio attrs/ no se limpian. Como resultado, la interfaz sysfs de DAMON queda casi rota hasta que el sistema se reinicia, y la memoria para el directorio no eliminado se fuga.<br /> <br /> Limpiar los directorios en caso de tales fallos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> virtio_net: Corrige un error de desalineación en la estructura virtnet_info<br /> <br /> Usa el nuevo ayudante TRAILING_OVERLAP() para corregir un error de desalineación junto con la siguiente advertencia:<br /> <br /> drivers/net/virtio_net.c:429:46: advertencia: la estructura que contiene un miembro de array flexible no está al final de otra estructura [-Wflex-array-member-not-at-end]<br /> <br /> Este ayudante crea una unión entre un miembro de array flexible (FAM) y un conjunto de miembros que de otro modo lo seguirían (en este caso &amp;#39;u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];&amp;#39;). Esto superpone los miembros finales (rss_hash_key_data) sobre el FAM (hash_key_data) mientras mantiene el FAM y el inicio de los MIEMBROS alineados. El static_assert() asegura que esta alineación se mantenga.<br /> <br /> Nótese que debido al relleno de cola en la estructura flexible &amp;#39;struct virtio_net_rss_config_trailer&amp;#39;, &amp;#39;rss_trailer.hash_key_data&amp;#39; (en el desplazamiento 83 en la estructura virtnet_info) y &amp;#39;rss_hash_key_data&amp;#39; (en el desplazamiento 84 en la estructura virtnet_info) están desalineados por un byte. Ver a continuación:<br /> <br /> ```<br /> struct virtio_net_rss_config_trailer {<br /> __le16 max_tx_vq; /* 0 2 */<br /> __u8 hash_key_length; /* 2 1 */<br /> __u8 hash_key_data[]; /* 3 0 */<br /> <br /> /* size: 4, cachelines: 1, members: 3 */<br /> /* padding: 1 */<br /> /* last cacheline: 4 bytes */<br /> };<br /> ```<br /> <br /> ```<br /> struct virtnet_info {<br /> ...<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */<br /> <br /> /* XXX last struct has 1 byte of padding */<br /> <br /> u8 rss_hash_key_data[40]; /* 84 40 */<br /> ...<br /> /* size: 832, cachelines: 13, members: 48 */<br /> /* sum members: 801, holes: 8, sum holes: 31 */<br /> /* paddings: 2, sum paddings: 5 */<br /> };<br /> ```<br /> <br /> Después de los cambios, esos miembros están correctamente alineados en el desplazamiento 795:<br /> <br /> ```<br /> struct virtnet_info {<br /> ...<br /> union {<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */<br /> struct {<br /> unsigned char __offset_to_hash_key_data[3]; /* 792 3 */<br /> u8 rss_hash_key_data[40]; /* 795 40 */<br /> }; /* 792 43 */<br /> }; /* 792 44 */<br /> ...<br /> /* size: 840, cachelines: 14, members: 47 */<br /> /* sum members: 801, holes: 8, sum holes: 35 */<br /> /* padding: 4 */<br /> /* paddings: 1, sum paddings: 4 */<br /> /* last cacheline: 8 bytes */<br /> };<br /> ```<br /> <br /> Como resultado, la clave RSS pasada al dispositivo se desplaza 1 byte: el último byte se corta y, en su lugar, se añade un byte (posiblemente no inicializado) al principio.<br /> <br /> Como última nota, &amp;#39;struct virtio_net_rss_config_hdr *rss_hdr;&amp;#39; también se mueve al final, ya que parece que esos tres miembros deberían permanecer juntos. :)