Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Arreglar el slab smbd_response para permitir usercopy El manejo de los datos recibidos en el código del cliente smbdirect implica usar copy_to_iter() para copiar datos del tráiler de paquetes de la estructura smbd_reponse a un búfer folioq proporcionado por netfslib que encapsula un trozo de pagecache. Sin embargo, si CONFIG_HARDENED_USERCOPY=y, esto dará como resultado que las comprobaciones realizadas en copy_to_iter() generen un error similar a lo siguiente: CIFS: Intentando montar //172.31.9.1/test CIFS: VFS: Transporte RDMA establecido usercopy: ¡Intento de exposición de memoria del kernel detectado desde el objeto SLUB 'smbd_response_0000000091e24ea1' (desplazamiento 81, tamaño 63)!-----------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopy_abort+0x6c/0x80 ... Call Trace: __check_heap_object+0xe3/0x120 __check_object_size+0x4dc/0x6d0 smbd_recv+0x77f/0xfe0 [cifs] cifs_readv_from_socket+0x276/0x8f0 [cifs] cifs_read_from_socket+0xcd/0x120 [cifs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x30 El problema es que la respuesta smbd_response El campo de paquete de slab no está marcado como permitido para copia de usuario. Se soluciona pasando parámetros a kmem_slab_create() para indicar que se permite copy_to_iter() desde la región de paquete de los objetos slab smbd_response, menos el espacio de encabezado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Corregir la ejecución recv-recv de la llamada completada. Si una llamada recibe un evento (como datos entrantes), la llamada se coloca en la cola del socket y se puede despertar un hilo en recvmsg para que la procese. Una vez que el hilo ha recogido la llamada de la cola, eventos posteriores harán que se vuelva a poner en cola, y una vez que se libera el bloqueo del socket (recvmsg usa call->user_mutex para permitir que el socket se use en paralelo), un segundo hilo puede entrar y su recvmsg puede sacar la llamada de la cola del socket nuevamente. En tal caso, el primer hilo recibirá cosas de la llamada y el segundo hilo se bloqueará en call->user_mutex. En este punto, el primer hilo puede procesar tanto el evento para el que seleccionó la llamada como el evento para el que el segundo hilo la seleccionó, y podría ver que la llamada termina. En ese caso, la llamada se "liberará", desvinculándola del ID de llamada de usuario que se le asignó (RXRPC_USER_CALL_ID en el mensaje de control). El primer hilo retornará correctamente, pero el segundo hilo se reactivará con el user_mutex y, si detecta que el primer hilo ha liberado la llamada, generará el siguiente error: ¡error del kernel en net/rxrpc/recvmsg.c:474! Para solucionar esto, simplemente retire la llamada de la cola e ignore si ya está liberada. De todos modos, no podemos informar al espacio de usuario, ya que el ID de llamada de usuario ha quedado obsoleto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se corrige la inhabilitación de irq en local_bh_enable(). La función rxrpc_assess_MTU_size() realiza una llamada a la capa IP para determinar el tamaño de MTU de una ruta. Al aceptar una llamada entrante, se realiza una llamada desde rxrpc_new_incoming_call(), que mantiene las interrupciones deshabilitadas en el código que la realiza. Desafortunadamente, la capa IP usa local_bh_enable() que, dependiendo de la configuración, lanza una advertencia si las IRQ están habilitadas: WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0 ... RIP: 0010:__local_bh_enable_ip+0x43/0xd0 ... Call Trace: rt_cache_route+0x7e/0xa0 rt_set_nexthop.isra.0+0x3b3/0x3f0 __mkroute_output+0x43a/0x460 ip_route_output_key_hash+0xf7/0x140 ip_route_output_flow+0x1b/0x90 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590 rxrpc_new_incoming_peer+0x46/0x120 rxrpc_alloc_incoming_call+0x1b1/0x400 rxrpc_new_incoming_call+0x1da/0x5e0 rxrpc_input_packet+0x827/0x900 rxrpc_io_thread+0x403/0xb60 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 ... hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50 hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70 softirqs last enabled at (0): copy_process+0xc61/0x2730 softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90. Para solucionar esto, mueva la llamada a rxrpc_assess_MTU_size() fuera de rxrpc_init_peer() y a una posición más alta en la pila, donde pueda realizarse sin interrupciones deshabilitadas. No debería ser un problema para rxrpc_new_incoming_call() realizarlo después de que se eliminen los bloqueos, ya que pmtud lo realizará el hilo de E/S (y en este momento estamos en el hilo de E/S).

Vulnerabilidad de consumo incontrolado de recursos en Legion of the Bouncy Castle Inc. Bouncy Castle para Java - BC-FJA 2.1.0 bc-fips (módulos API) permite una asignación excesiva. Esta vulnerabilidad está asociada a los archivos de programa org.Bouncycastle.Crypto.Fips.NativeLoader. Este problema afecta a Bouncy Castle para Java - BC-FJA 2.1.0: de BC-FJA 2.1.0 a 2.1.0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: No llame a mmput desde la devolución de llamada del notificador MMU Si el proceso está saliendo, el mmput dentro de la devolución de llamada del notificador mmu de compactd o fork o numa balancing podría liberar la última referencia de la estructura mm para llamar a exit_mmap y free_pgtable, esto desencadena un bloqueo con el siguiente backtrace. El bloqueo perderá el proceso kfd ya que no se llama a la liberación del notificador mmu y causa fugas de VRAM. La solución es tomar la referencia mm mmget_non_zero al agregar prange a la lista diferida para emparejar con mmput en el trabajo de la lista diferida. Si prange se divide y se agrega a la lista pchild, pchild work_item.mm no se usa, así que elimine el parámetro mm de svm_range_unmap_split y svm_range_add_child. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu] (seleccionado de el commit a29e067bd38946f752b0ef855f3dfff87e77bec7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/CPU/AMD: Desactivar INVLPGB en Zen2 AMD Cyan Skillfish (Familia 17h, Modelo 47h, Stepping 0h) presenta un problema que provoca errores y pánicos del sistema al realizar el vaciado de TLB con INVLPGB. Sin embargo, el problema radica en que esa máquina tiene un CPUID mal configurado y no debería informar el bit INVLPGB. Por lo tanto, elimine la representación del indicador en el kernel para evitar confusiones. [bp: Masaje].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon: corrección de división por cero en damon_get_intervals_score() La implementación actual permite tener regiones de tamaño cero sin razones especiales, pero damon_get_intervals_score() se bloquea por división por cero cuando el tamaño de la región es cero. [ 29.403950] Oops: error de división: 0000 [#1] SMP NOPTI Este parche corrige el error, pero no deshabilita las regiones de tamaño cero para mantener la compatibilidad con versiones anteriores, ya que deshabilitar las regiones de tamaño cero podría ser un cambio importante para algunos usuarios. Además, el mismo bloqueo puede ocurrir cuando intervals_goal.access_bp es cero, por lo que esto también debería corregirse en los árboles estables.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: Se corrige el fallo del kernel al reiniciar la GPU La secuencia de reinicio completo de la GPU llama a pm_runtime_force_suspend() y pm_runtime_force_resume(), que según su documentación solo se deben usar durante las transiciones de PM de todo el sistema a estados de suspensión. Sin embargo, el problema principal es que, dependiendo de algún estado interno de PM en tiempo de ejecución, como se ve en pm_runtime_force_suspend() (si el recuento de uso es <= 1), pm_runtime_force_resume() podría no reanudar el dispositivo a menos que sea necesario. Si eso sucede, no se llama a la devolución de llamada de reanudación de PM en tiempo de ejecución pvr_power_device_resume(), no se vuelven a habilitar los relojes de la GPU y el kernel se bloquea en el siguiente intento de acceder a los registros de la GPU como parte de la secuencia de encendido. Reemplace las llamadas a pm_runtime_force_suspend() y pm_runtime_force_resume() con llamadas directas a las devoluciones de llamadas PM de tiempo de ejecución del controlador, pvr_power_device_suspend() y pvr_power_device_resume(), para garantizar que los relojes se vuelvan a habilitar y evitar el bloqueo del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: qcom: msm: marcar ciertos pines como inválidos para interrupciones En algunas plataformas, el pin UFS-reset no tiene lógica de interrupción en TLMM pero sin embargo está registrado como un GPIO en el kernel. Esto permite que el espacio de usuario active un BUG() en el controlador pinctrl-msm ejecutando, por ejemplo: `gpiomon -c 0 113` en RB2. El culpable exacto es solicitar pines cuyo ajuste intr_detection_width no es 1 o 2 para interrupciones. Esto alcanza un BUG() en msm_gpio_irq_set_type(). Potencialmente, bloquear el kernel debido a una solicitud inválida del espacio de usuario no es óptimo, así que revisemos los pines y marquemos aquellos que fallarían la verificación como inválidos para el chip irq ya que ni siquiera deberíamos registrarlos como irq disponibles. Esta función se puede extender si determinamos que hay más casos especiales como este.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/sched: Incremento del recuento de trabajos antes de intercambiar la cola de cola de spsc. Existe una pequeña competencia entre spsc_queue_push y el trabajador de ejecución de trabajos, en la que spsc_queue_push puede devolver un resultado no-first mientras el trabajador de ejecución de trabajos ya está inactivo debido a que el recuento de trabajos es cero. Si se produce esta competencia, se detiene la programación de trabajos, lo que provoca bloqueos mientras se espera en las barreras DMA del trabajo. Para solucionar esta competencia, incremente el recuento de trabajos antes de agregarlos a la cola de SPSC. Esta competencia se observó en una compilación drm-tip 6.16-rc1 con el controlador Xe en un caso de prueba SVM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: zd1211rw: Se corrige una posible desreferencia de puntero NULL en zd_mac_tx_to_dev(). Existe una posible desreferencia de puntero NULL en zd_mac_tx_to_dev(). Por ejemplo, es posible lo siguiente: T0 T1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; itype == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL. Dado que hay una pequeña diferencia entre la comprobación de la longitud de la cola de skb y su desencolado incondicional en zd_mac_tx_to_dev(), skb_dequeue() puede devolver NULL. A continuación, el puntero se pasa a zd_mac_tx_status(), donde se desreferencia. Para evitar posibles desreferencias de punteros NULL debido a situaciones como la anterior, compruebe que skb no sea NULL antes de pasarlo a zd_mac_tx_status(). Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: prevenir ataques A-MSDU en redes de malla Este parche es una mitigación para prevenir la vulnerabilidad de suplantación de A-MSDU para redes de malla. La actualización inicial del estándar IEEE 802.11, en respuesta a los FragAttacks, pasó por alto este caso (CVE-2025-27558). Puede considerarse una variante de CVE-2020-24588 pero para redes de malla. Este parche intenta detectar si un adversario convirtió una MSDU estándar en una A-MSDU. Esto se hace analizando una A-MSDU recibida como una MSDU estándar, calculando la longitud del encabezado Mesh Control y viendo si los 6 bytes después de este encabezado equivalen al comienzo de un encabezado rfc1042. Si son iguales, esto es un fuerte indicio de un intento de ataque en curso. Esta defensa se probó con mac80211_hwsim contra una red en malla que utiliza un campo de extensión de dirección de malla vacío (es decir, cuando se utilizan cuatro direcciones) y un campo de extensión de dirección de malla de 12 bytes (es decir, cuando se utilizan seis direcciones). También se probó la funcionalidad de las MSDU normales y las A-MSDU, y se confirmó su funcionamiento, tanto al utilizar un campo de extensión de dirección de malla vacío como al utilizar un campo de extensión de dirección de malla de 12 bytes. También se probó con mac80211_hwsim que los ataques A-MSDU en redes no en malla se siguen detectando y previniendo. Tenga en cuenta que la vulnerabilidad que se está reparando y la defensa que se está implementando también se analizaron en el siguiente documento y en la siguiente presentación IEEE 802.11: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx