Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfc: llcp: Corrección de fuga de memoria en nfc_llcp_send_ui_frame().<br /> <br /> syzbot informó de varias fugas de memoria relacionadas con NFC, struct<br /> nfc_llcp_sock, sk_buff, nfc_dev, etc. [0]<br /> <br /> El registro principal sugirió que nfc_llcp_send_ui_frame() falló<br /> al asignar skb debido a que sock_error(sk) era -ENXIO.<br /> <br /> ENXIO es establecido por nfc_llcp_socket_release() cuando struct<br /> nfc_llcp_local es destruido por local_cleanup().<br /> <br /> El problema es que no hay sincronización entre<br /> nfc_llcp_send_ui_frame() y local_cleanup(), y skb<br /> podría ser puesto en local-&amp;gt;tx_queue después de que fuera purgado en<br /> local_cleanup():<br /> <br /> CPU1 CPU2<br /> ---- ----<br /> nfc_llcp_send_ui_frame() local_cleanup()<br /> |- do { &amp;#39;<br /> |- pdu = nfc_alloc_send_skb(..., &amp;amp;err)<br /> | .<br /> | |- nfc_llcp_socket_release(local, false, ENXIO);<br /> | |- skb_queue_purge(&amp;amp;local-&amp;gt;tx_queue); |<br /> | &amp;#39; |<br /> |- skb_queue_tail(&amp;amp;local-&amp;gt;tx_queue, pdu); |<br /> ... |<br /> |- pdu = nfc_alloc_send_skb(..., &amp;amp;err) |<br /> ^._________________________________.&amp;#39;<br /> <br /> local_cleanup() es llamado para struct nfc_llcp_local solo<br /> después de que nfc_llcp_remove_local() lo desvincula de llcp_devices.<br /> <br /> Si mantenemos local-&amp;gt;tx_queue.lock entonces, podemos sincronizar<br /> el hilo y nfc_llcp_send_ui_frame().<br /> <br /> Hagamos eso y verifiquemos list_empty(&amp;amp;local-&amp;gt;list) antes<br /> de encolar skb en local-&amp;gt;tx_queue en nfc_llcp_send_ui_frame().<br /> <br /> [0]:<br /> [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)<br /> [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> BUG: memory leak<br /> unreferenced object 0xffff8881272f6800 (size 1024):<br /> comm &amp;#39;syz.0.17&amp;#39;, pid 6096, jiffies 4294942766<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 &amp;#39;..@............<br /> backtrace (crc da58d84d):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4979 [inline]<br /> slab_alloc_node mm/slub.c:5284 [inline]<br /> __do_kmalloc_node mm/slub.c:5645 [inline]<br /> __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239<br /> sk_alloc+0x36/0x360 net/core/sock.c:2295<br /> nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979<br /> llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044<br /> nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31<br /> __sock_create+0x1a9/0x340 net/socket.c:1605<br /> sock_create net/socket.c:1663 [inline]<br /> __sys_socket_create net/socket.c:1700 [inline]<br /> __sys_socket+0xb9/0x1a0 net/socket.c:1747<br /> __do_sys_socket net/socket.c:1761 [inline]<br /> __se_sys_socket net/socket.c:1759 [inline]<br /> __x64_sys_socket+0x1b/0x30 net/socket.c:1759<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810fbd9800 (size 240):<br /> comm &amp;#39;syz.0.17&amp;#39;, pid 6096, jiffies 4294942850<br /> hex dump (first 32 bytes):<br /> 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.......<br /> 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/&amp;#39;....<br /> backtrace (crc 6cc652b1):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4979 [inline]<br /> slab_alloc_node mm/slub.c:5284 [inline]<br /> kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336<br /> __alloc_skb+0x203/0x240 net/core/skbuff.c:660<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0x69/0x3f0 net/core/sk<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Bluetooth: MGMT: Corrección de fuga de memoria en set_ssp_complete<br /> <br /> Corrige la fuga de memoria en set_ssp_complete() donde las estructuras mgmt_pending_cmd no son liberadas después de ser eliminadas de la lista de pendientes.<br /> <br /> El commit 302a1f674c00 (&amp;#39;Bluetooth: MGMT: Corrige posibles UAFs&amp;#39;) reemplazó las llamadas a mgmt_pending_foreach() con el manejo individual de comandos, pero omitió añadir llamadas a mgmt_pending_free() tanto en las rutas de error como de éxito de set_ssp_complete(). Otras funciones de completado como set_le_complete() fueron corregidas correctamente en el mismo commit.<br /> <br /> Esto causa una fuga de memoria de la estructura mgmt_pending_cmd y sus datos de parámetros asociados para cada comando SSP que se completa.<br /> <br /> Añade las llamadas faltantes a mgmt_pending_free(cmd) en ambas rutas de código para corregir la fuga de memoria. También corrige el mismo problema en set_advertising_complete().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mac80211: decodificar correctamente TTLM con mapa de enlace predeterminado<br /> <br /> Los elementos de Mapeo de TID a Enlace (TTLM) no contienen ningún indicador de presencia de mapeo de enlace si se utiliza un mapeo predeterminado y el análisis debe omitirse.<br /> <br /> Tenga en cuenta que los puntos de acceso no deberían informar explícitamente un TTLM anunciado con un mapeo predeterminado, ya que ese es el mapeo implícito si el elemento no está incluido; este es incluso el caso al volver al mapeo predeterminado. Sin embargo, mac80211 analizaría incorrectamente la trama y también leería un byte más allá del final del elemento.

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 /> 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:<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 /> 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: 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 /> 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 /> bpf, test_run: Restar el tamaño de xdp_frame del tamaño de metadatos permitido<br /> <br /> La estructura xdp_frame ocupa parte del headroom del frame XDP, limitando el tamaño de los metadatos. Sin embargo, en bpf_test_run, no tenemos esto en cuenta, lo que hace posible que el userspace suministre un tamaño de metadatos que es demasiado grande (ocupando todo el headroom).<br /> <br /> Si el userspace suministra un tamaño de metadatos tan grande en modo de paquete en vivo, la llamada a xdp_update_frame_from_buff() en la llamada a xdp_test_run_init_page() fallará, después de lo cual la transmisión de paquetes procede con una estructura de frame no inicializada, lo que lleva a las &amp;#39;Cosas Malas&amp;#39; habituales.<br /> <br /> El commit en la etiqueta Fixes corrigió un error relacionado donde la segunda comprobación en xdp_update_frame_from_buff() podría fallar, pero no añadió ninguna restricción adicional sobre el tamaño de los metadatos. Completar la corrección añadiendo una comprobación adicional sobre el tamaño de los metadatos. Reordenar ligeramente las comprobaciones para hacer la lógica más clara y añadir un comentario.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: send: verificar extents en línea en range_is_hole_in_parent()<br /> <br /> Antes de acceder al campo disk_bytenr de un elemento de extent de archivo, necesitamos verificar si estamos tratando con un extent en línea.<br /> Esto se debe a que para los extents en línea, sus datos comienzan en el desplazamiento del campo disk_bytenr. Así que acceder al disk_bytenr significa que estamos accediendo a datos en línea o, en caso de que los datos en línea sean menores de 8 bytes, podemos realmente causar un acceso a memoria inválido si este elemento de extent en línea es el primer elemento en la hoja o acceder a metadatos de otros elementos.

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