Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> octeon_ep: Corrección de fuga de memoria en octep_device_setup()<br /> <br /> En octep_device_setup(), si octep_ctrl_net_init() falla, la función retorna directamente sin desmapear los recursos mapeados y liberar la memoria de configuración asignada.<br /> <br /> Esto se corrige saltando a la etiqueta unsupported_dev, la cual realiza la limpieza necesaria. Esto se alinea con la lógica de manejo de errores de otras rutas en esta función.<br /> <br /> Probado únicamente en compilación. Problema encontrado usando una herramienta prototipo de análisis estático y revisión de código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> perf: sched: Soluciona el fallo de perf con la nueva función auxiliar is_user_task()<br /> <br /> Para realizar un seguimiento de pila (stacktrace) del espacio de usuario, la tarea actual debe ser una tarea de usuario que se haya ejecutado en el espacio de usuario. Solía ser posible comprobar si una tarea es una tarea de usuario o no simplemente verificando el campo mm de task_struct. Si no era NULL, era una tarea de usuario y si no, era una tarea del kernel.<br /> <br /> Pero las cosas han cambiado con el tiempo, y algunas tareas del kernel ahora tienen su propio campo mm.<br /> <br /> Se propuso la idea de probar PF_KTHREAD en su lugar y se utilizaron dos funciones para encapsular esta verificación en caso de que se volviera más complejo probar si una tarea era una tarea de usuario o no[1]. Pero esto fue rechazado y el código C simplemente verificó PF_KTHREAD directamente.<br /> <br /> Más tarde se descubrió que no todos los hilos del kernel establecen PF_KTHREAD. Los auxiliares de io-uring, en cambio, establecen PF_USER_WORKER y esto también necesitaba ser añadido.<br /> <br /> Pero verificar las banderas (flags) todavía no es suficiente. Hay una ventana muy pequeña cuando una tarea sale en la que libera su campo mm y este se vuelve a establecer en NULL. Si perf se activara en este momento, la prueba de las banderas diría que es una tarea del espacio de usuario, pero cuando perf leyera el campo mm, fallaría con una desreferencia de puntero NULL.<br /> <br /> Ahora hay banderas que se pueden usar para probar si una tarea está saliendo, pero se establecen en áreas que perf aún podría querer perfilar en la tarea del espacio de usuario (para ver dónde salió). La única prueba real es verificar tanto las banderas como el campo mm.<br /> <br /> En lugar de realizar esta modificación en cada ubicación, cree una nueva función auxiliar is_user_task() que realice todas las pruebas necesarias para saber si es seguro leer la memoria del espacio de usuario o no.<br /> <br /> [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/

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