Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kasan: eliminar kasan_find_vm_area() para evitar un posible bloqueo. No se pudo llamar a find_vm_area() en atomic_context. Si se llama a find_vm_area() para informar sobre el área de la máquina virtual, kasan puede provocar un bloqueo como: CPU0 CPU1 vmalloc(); alloc_vmap_area(); spin_lock(&vn->busy.lock) spin_lock_bh(&some_lock); spin_lock(&some_lock); kasan_report(); print_report(); print_address_description(); kasan_find_vm_area(); find_vm_area(); spin_lock(&vn->busy.lock) // ¡Bloqueo! Para evitar un posible bloqueo mientras kasan informa, elimine kasan_find_vm_area().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se corrige un error debido a la inexistencia de la estructura de registro de preasignación. Si se abre y enlaza un socket de servicio AF_RXRPC, pero las llamadas están preasignadas, rxrpc_alloc_incoming_call() generará un error porque la estructura rxrpc_backlog no se asigna hasta que se realiza la primera preasignación. Se soluciona este problema devolviendo NULL desde rxrpc_alloc_incoming_call() si no existe la estructura de registro de preasignación. Esto provocará la interrupción de la llamada entrante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/pf: Borrar todas las páginas LMTT al asignar. Nuestros objetos de búfer LMEM no se borran por defecto al asignar, y durante el aprovisionamiento de VF solo configuramos PTE LMTT para el rango LMEM realmente aprovisionado. Sin embargo, más allá de ese rango válido, podríamos dejar datos obsoletos que podrían apuntar a otras asignaciones de VF o incluso a las páginas PF. Borre explícitamente todas las páginas LMTT nuevas para evitar el riesgo de que una VF maliciosa intente explotar esa brecha. Mientras esté disponible, agregue aserciones para detectar cualquier sobrescritura de PTE no deseada y trazas de depuración de bajo nivel para rastrear el ciclo de vida de las PT LMTT. (Seleccionado de el commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/alloc_tag: no adquiere un bloqueo inexistente en alloc_tag_top_users() alloc_tag_top_users() intenta bloquear alloc_tag_cttype->mod_lock incluso cuando alloc_tag_cttype no está asignado porque: 1) el etiquetado de asignación está deshabilitado porque el perfil de memoria está deshabilitado (!alloc_tag_cttype) 2) el etiquetado de asignación está habilitado, pero aún no se ha inicializado (!alloc_tag_cttype) 3) el etiquetado de asignación está habilitado, pero falló la inicialización (!alloc_tag_cttype o IS_ERR(alloc_tag_cttype)) En todos los casos, alloc_tag_cttype no está asignado y, por lo tanto, alloc_tag_top_users() no debe intentar adquirir el semáforo. Esto genera un bloqueo por un error de asignación de memoria al intentar adquirir un semáforo inexistente: Oops: error de protección general, probablemente para una dirección no canónica 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000d8-0x00000000000000df] CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: GD 6.16.0-rc2 #1 VOLUNTARY Tainted: [D]=DIE Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:down_read_trylock+0xaa/0x3b0 Código: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016 RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000 RDX: 0000000000000001b RSI: 000000000000000a RDI: 0000000000000070 RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1 R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37 R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000 FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0 Rastreo de llamadas: codetag_trylock_module_list+0xd/0x20 Como señala David Wang, este problema se volvió más fácil de activar después de el commit 780138b12381 ("alloc_tag: verificar mem_profiling_support en alloc_tag_init"). Antes de el commit, el problema solo ocurría cuando no se asignaba ni inicializaba alloc_tag_cttype o si fallaba la asignación de memoria antes de llamar a alloc_tag_init(). Después de el commit, se puede activar fácilmente cuando el perfilado de memoria se compila, pero se deshabilita al arrancar. Para determinar correctamente si se ha llamado a alloc_tag_init() y si se han inicializado sus estructuras de datos, verifique que alloc_tag_cttype sea un puntero válido antes de adquirir el semáforo. Si la variable es NULL o un valor de error, no se ha inicializado correctamente. En tal caso, simplemente omita este paso y no intente adquirir el semáforo. [harry.yoo@oracle.com: v3]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/zcrx: corrección de advertencias de destrucción de pp. Con varios grupos de páginas y en otros casos, podemos asignar niovs al destruir el grupo de páginas. Se ha eliminado una advertencia incorrecta que verificaba que todos los niovs se devolvieran a zcrx en io_pp_zc_destroy(). Se informó anteriormente, pero aparentemente se perdió.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: descarta marcos de disociación erróneos en la interfaz STA. Cuando se opera en modo STA/AP concurrente con MLME de host habilitado, el firmware envía incorrectamente marcos de disociación a la interfaz STA cuando los clientes se desconectan de la interfaz AP. Esto genera advertencias del kernel ya que la interfaz STA procesa eventos de desconexión que no se aplican a ella: [ 1303.240540] ADVERTENCIA: CPU: 0 PID: 513 en net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Módulos vinculados: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 No contaminado 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Nombre del hardware: Toradex Verdin AM62 WB en placa de desarrollo Verdin (DT) [ 1303.343588] Cola de trabajo: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 00000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Rastreo de llamadas: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845]worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Agregue validación en la ruta de recepción de STA para verificar que los marcos de desasociación/desautorización se originen en el AP conectado. Las tramas que no superan esta comprobación se descartan prematuramente, lo que impide que lleguen a la capa MLME y activen WARN_ON(). Esta lógica de filtrado es similar a la utilizada en la función ieee80211_rx_mgmt_disassoc() de mac80211, que descarta las tramas de desasociación que no coinciden con el BSSID actual (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), garantizando así que solo se procesen las tramas relevantes. Probado en: - 8997 con firmware 16.68.1.p197

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Permitir que la CPU reprograme mientras se configuran atributos de memoria por página Cuando se ejecuta un invitado SEV-SNP con una cantidad de memoria suficientemente grande (1 TB+), el host puede experimentar bloqueos suaves de la CPU cuando ejecuta una operación en kvm_vm_set_mem_attributes() para configurar los atributos de memoria en todo el rango de memoria del invitado. watchdog: BUG: bloqueo suave: ¡CPU n.º 8 bloqueada durante 26 s! [qemu-kvm:6372] CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: cargado No contaminado 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntario) Nombre del hardware: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 13/11/2024 RIP: 0010:xas_create+0x78/0x1f0 Código: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 00000000000000000 RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 R13: ffffad890a356860 R14: 000000000000000 R15: ffffad890a356868 FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 PKRU: 55555554 Rastreo de llamadas: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f5578d031bb Código: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 00000000000000b RBP: 000001000000000 R08: 0000010000000000 R09: 0000017680000000 R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0 Mientras recorre el rango de memoria configurando los atributos, llame a cond_resched() para darle al programador la oportunidad de ejecutar una tarea de mayor prioridad en la cola de ejecución si es necesario y evitar permanecer en modo kernel el tiempo suficiente para activar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: nintendo: evitar bloqueos de suspensión/reinicio de bluetooth Asegúrese de que no bloqueemos ni hagamos que el kernel entre en pánico cuando usemos controladores conectados por bluetooth. Esto se informó como un problema en dispositivos Android que usan el kernel 6.6 debido al gancho de reanudación que se había agregado para los joycons usb. Primero, establezca un nuevo valor de estado en JOYCON_CTLR_STATE_SUSPENDED en un nintendo_hid_suspend recién agregado. Esto asegura que no bloquearemos el kernel esperando informes de entrada durante la suspensión de classdev led. Los bloqueos podrían ocurrir si la conectividad no es confiable o se pierde con el controlador antes de la suspensión. Segundo, dado que perdemos la conectividad durante la suspensión, no intentes joycon_init() para controladores bluetooth en la ruta nintendo_hid_resume. Probado a través de múltiples flujos de suspensión/reinicio al usar el controlador en modo USB y bluetooth.