Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: corrige la desreferenciación de puntero NULL en amdgpu_gmc_filter_faults_remove<br /> <br /> En APUs como Raven y Renoir (GC 9.1.0, 9.2.2, 9.3.0), los búferes de anillo de interrupción ih1 e ih2 no están inicializados. Esto es intencional, ya que estos anillos IH secundarios solo están disponibles en GPUs discretas. Véase vega10_ih_sw_init() que explícitamente omite la inicialización de ih1/ih2 cuando AMD_IS_APU está configurado.<br /> <br /> Sin embargo, amdgpu_gmc_filter_faults_remove() usa incondicionalmente ih1 para obtener la marca de tiempo de la última entrada de interrupción. Cuando las fallas de reintento están habilitadas en APUs (noretry=0), esta función es llamada desde la ruta de recuperación de fallas de página SVM, lo que resulta en una desreferenciación de puntero NULL cuando amdgpu_ih_decode_iv_ts_helper() intenta acceder a ih-&amp;gt;ring[].<br /> <br /> El fallo se manifiesta como:<br /> <br /> BUG: desreferenciación de puntero NULL del kernel, dirección: 0000000000000004<br /> RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]<br /> Call Trace:<br /> amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]<br /> svm_range_restore_pages+0xae5/0x11c0 [amdgpu]<br /> amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]<br /> gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]<br /> amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]<br /> amdgpu_ih_process+0x84/0x100 [amdgpu]<br /> <br /> Este problema fue expuesto por el commit 1446226d32a4 (&amp;#39;drm/amdgpu: Eliminar GC HW IP 9.3.0 de noretry=1&amp;#39;) que cambió el valor predeterminado para la APU Renoir de noretry=1 a noretry=0, habilitando el manejo de fallas de reintento y, por lo tanto, ejercitando la ruta de código defectuosa.<br /> <br /> Solucione esto añadiendo una comprobación para ih1.ring_size antes de intentar usarlo. También restaure el soporte soft_ih del commit dd299441654f (&amp;#39;drm/amdgpu: Reestructurar la eliminación de fallas de reintento&amp;#39;). Esto es necesario si el hardware no soporta anillos IH de hardware secundarios.<br /> <br /> v2: actualizaciones adicionales (Alex)<br /> <br /> (seleccionado de commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/nvm: Corrige doble liberación en fallo de adición de aux<br /> <br /> Después de una exitosa auxiliary_device_init(), aux_dev-&amp;gt;dev.release (xe_nvm_release_dev()) es responsable de la kfree(nvm). Cuando hay un fallo con auxiliary_device_add(), el controlador llamará a auxiliary_device_uninit(), que llama a put_device(). De modo que la devolución de llamada .release se activará para liberar la memoria asociada con el auxiliary_device.<br /> <br /> Mueve la kfree(nvm) a la ruta de fallo de auxiliary_device_init() y elimina la ruta err goto para corregir el error a continuación.<br /> <br /> [ 13.232905] ==================================================================<br /> [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]<br /> [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273<br /> <br /> [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)<br /> ...<br /> [ 13.233125] Call Trace:<br /> [ 13.233126] <br /> [ 13.233127] dump_stack_lvl+0x7f/0xc0<br /> [ 13.233132] print_report+0xce/0x610<br /> [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0<br /> [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]<br /> ...<br /> <br /> v2: elimina la ruta err goto. (Alexander)<br /> <br /> (seleccionado de la confirmación a3187c0c2bbd947ffff97f90d077ac88f9c2a215)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> mm/shmem, swap: corrige la condición de carrera entre el truncamiento y la división de entradas de swap<br /> <br /> La función auxiliar para la liberación de swap de shmem no está manejando correctamente el orden de las entradas de swap. Utiliza xa_cmpxchg_irq para borrar la entrada de swap, pero obtiene el orden de la entrada antes de eso usando xa_get_order sin protección de bloqueo, y puede obtener un valor de orden obsoleto si la entrada se divide o cambia de otras maneras después de xa_get_order y antes de xa_cmpxchg_irq.<br /> <br /> Y además, el orden podría crecer y ser mayor de lo esperado, y causar que el truncamiento borre datos más allá del límite final. Por ejemplo, si la entrada objetivo y las entradas siguientes se intercambian (swap in) o se liberan, y luego se añadió un folio grande en su lugar y se intercambió (swap out), usando la misma entrada, el xa_cmpxchg_irq seguirá teniendo éxito, aunque es muy poco probable que ocurra.<br /> <br /> Para solucionar eso, se implementa directamente el cmpxchg de Xarray y se coloca la recuperación del orden y la verificación del valor en la misma sección crítica. Además, se asegura que el orden no exceda el límite final, se omite si la entrada cruza el límite.<br /> <br /> Omitir entradas de swap grandes que cruzan el límite final es seguro aquí. El truncamiento de shmem itera el rango dos veces; en la primera iteración, find_lock_entries ya filtró dichas entradas, y shmem intercambiará (swap in) las entradas que cruzan el límite final y truncará parcialmente el folio (dividirá el folio o al menos pondrá a cero parte de él). Así que, en el segundo bucle aquí, si vemos una entrada de swap que cruza el orden final, al menos ya debe tener su contenido borrado.<br /> <br /> Observé bloqueos aleatorios de swapoff y &amp;#39;kernel panics&amp;#39; al realizar pruebas de estrés de ZSWAP con shmem. Después de aplicar este parche, todos los problemas desaparecieron.

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