Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: evite el posible use-after-free en hci_error_reset Mientras se maneja el evento HCI_EV_HARDWARE_ERROR, si el controlador BT subyacente no responde, el mecanismo de reinicio de GPIO liberaría hci_dev y provocaría un error. use-after-free en hci_error_reset. Este es el seguimiento de llamadas observado en un dispositivo ChromeOS con Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] Process_one_work+0x1d8/0x33f trabajador_thread+0x21b/0x373 kthread+0x13a /0x152 ? pr_cont_work+0x54/0x54? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 Este parche mantiene el recuento de referencias en hci_dev mientras procesa un evento HCI_EV_HARDWARE_ERROR para evitar posibles fallas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: stmmac: Borrar variable al destruir la cola de trabajo Actualmente, al suspender el controlador y detener la cola de trabajo, se verifica si la cola de trabajo no es NULL y, de ser así, se destruye. La función destroy_workqueue() drena la cola y borra la variable, pero no establece la variable de la cola de trabajo en NULL. Esto puede causar pánico en el núcleo/módulo si el código intenta borrar la cola de trabajo que no se inicializó. Este escenario es posible al reanudar el controlador suspendido en stmmac_resume(), porque no hay control para stmmac_hw_setup() fallido, que puede fallar y regresar si el motor DMA no se pudo inicializar y la cola de trabajo se inicializa después del motor DMA. Si el motor DMA no se inicializa, la reanudación se realizará normalmente, pero la interfaz no funcionará y la cola de TX eventualmente expirará, lo que provocará el error "Restablecer adaptador". Esto luego destruye la cola de trabajo durante el proceso de reinicio. Y dado que la cola de trabajo se inicializa después del motor DMA y se puede omitir, provocará pánico en el núcleo/módulo. Para protegerse contra este posible bloqueo, establezca la variable workqueue en NULL al destruir workqueue. El registro/rastreo del fallo es el siguiente: [88.031977]------------[ cortar aquí ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac) : Se agotó el tiempo de espera de la cola de transmisión 1 [88.032017] ADVERTENCIA: CPU: 0 PID: 0 en net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[fin de rastreo e70de432e4d5c2c0] --- [88.032282]sxgmac 16d88000.ethernet eth0: Restablecer el adaptador. [88.036359]------------[ cortar aquí ]------------ [88.036519]Rastreo de llamadas: [88.036523] Flush_workqueue+0x3e4/0x430 [88.036528] Drain_workqueue+ 0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0 x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part. 0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] Process_one_work+0x1d8/0x4a0 [88.036573] trabajador_thread+0x54/0x408 [8 8.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+ 0x10/0x20 [88.036588]---[fin de seguimiento e70de432e4d5c2c1]--- [88.036597]No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000004

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: veth: borra GRO al borrar XDP incluso cuando está desactivado veth configura NETIF_F_GRO automáticamente cuando XDP está habilitado, porque ambas funciones utilizan la misma maquinaria NAPI. La lógica para borrar NETIF_F_GRO se encuentra en veth_disable_xdp(), que se llama tanto en ndo_stop como cuando XDP está desactivado. Para evitar que la bandera se borre cuando se baja el dispositivo, la eliminación se omite cuando IFF_UP no está configurado. De hecho, bajar el dispositivo no debería modificar sus características. Desafortunadamente, esto significa que la limpieza también se omite cuando XDP está deshabilitado _mientras_ el dispositivo está inactivo. Y no hay nada en el camino abierto para volver a sincronizar las funciones del dispositivo. IOW, si el usuario habilita XDP, lo deshabilita y luego enciende el dispositivo, terminaremos con un indicador GRO perdido pero sin instancias NAPI. No dependemos del indicador GRO en la ruta de datos, por lo que la ruta de datos no fallará. Nos bloquearemos (o colgaremos), sin embargo, la próxima vez que se sincronicen las funciones (ya sea por el usuario a través de ethtool o por un compañero cambiando su configuración). La bandera GRO desaparecerá y Veth intentará desactivar las NAPI. Pero el camino abierto nunca los creó ya que XDP estaba desactivado, la bandera GRO estaba perdida. Si NAPI se inicializó antes, colgaremos napi_disable(). Si nunca fue así, fallaremos al intentar detener el hrtimer no inicializado. Mueva las actualizaciones del indicador GRO a las rutas de activación/desactivación de XDP, en lugar de mezclarlas con las rutas ndo_open/ndo_close.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ip_tunnel: evita el crecimiento perpetuo del espacio libre syzkaller activado después de kasan splat: ERROR: KASAN: use-after-free en __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Lectura del tamaño 1 en la dirección ffff88812fb4000e mediante la tarea syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_key incluir/linux /skbuff.h:1514 [en línea] ___skb_get_hash net/core/flow_dissector.c:1791 [en línea] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [en línea] ip_tunnel_xmit +0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice .h:3134 [en línea] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c :323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit incluir /linux /netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 . .. El símbolo se produce porque skb->data apunta más allá del área asignada de skb->head. Esto se debe a que la capa vecina hace: __skb_pull(skb, skb_network_offset(skb)); ... pero skb_network_offset() devuelve un desplazamiento negativo y el argumento __skb_pull() no está firmado. OIA, nosotros, skb->los datos, se "ajustan" en un valor enorme. El valor negativo se devuelve porque la distancia de skb->head y skb->data es superior a 64k y skb->network_header (u16) se ha ajustado. El error está en la infraestructura ip_tunnel, lo que puede hacer que dev->needed_headroom se incremente hasta el infinito. El reproductor syzkaller consta de paquetes que se enrutan a través de un túnel gre y una ruta de paquetes encapsulados gre que apuntan a otro túnel (ipip). La encapsulación ipip encuentra gre0 como el siguiente dispositivo de salida. Esto da como resultado el siguiente patrón: 1). El primer paquete se enviará a través de gre0. La búsqueda de ruta encontró un dispositivo de salida, ipip0. 2). ip_tunnel_xmit para gre0 aumenta gre0->needed_headroom según el dispositivo de salida futuro, rt.dev->needed_headroom (ipip0). 3). ipoutput/start_xmit mueve skb a ipip0. que ejecuta la misma ruta de código nuevamente (xmit recursividad). 4). El paso de enrutamiento para el paquete post-gre0-encap encuentra gre0 como dispositivo de salida para usar con el paquete encapsulado ipip0. tunl0->needed_headroom luego se incrementa según el espacio libre del dispositivo gre0 (ya aumentado). Esto se repite para cada paquete futuro: gre0->needed_headroom se infla porque el paso ipip0 de los paquetes anteriores incrementó el espacio libre rt->dev (gre0), y ipip0 se incrementó porque se aumentó el espacio necesario_headroom de gre0. Para cada paquete posterior, gre/ipip0->needed_headroom crece hasta que las reasignaciones posteriores a la expansión del cabezal dan como resultado una distancia skb->head/data de más de 64k. Una vez que eso sucede, skb->network_header (u16) se ajusta cuando pskb_expand_head intenta asegurarse de que skb_network_offset() no cambie después de la expansión/reasignación del espacio libre. Después de esto, skb_network_offset(skb) devuelve un resultado diferente (y negativo) posterior a la expansión del espacio libre.---trucado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netlink: Fix kernel-infoleak-after-free en __skb_datagram_iter syzbot informó el siguiente problema de acceso al valor uninit [1]: netlink_to_full_skb() crea un nuevo `skb` y coloca el ` skb->data` pasó como primer argumento de netlink_to_full_skb() al nuevo `skb`. El tamaño de los datos se especifica como `len` y se pasa a skb_put_data(). Este `len` se basa en `skb->end` que no es un desplazamiento de datos sino un desplazamiento del búfer. El `skb->end` contiene datos y espacio de adaptación. Dado que el tailroom no se inicializa cuando se crea el nuevo `skb`, KMSAN detecta un área de memoria no inicializada al copiar los datos. Este parche resolvió este problema corrigiendo la longitud de `skb->end` a `skb->len`, que es el desplazamiento de datos real. ERROR: KMSAN: kernel-infoleak-after-free en instrument_copy_to_user include/linux/instrumented.h:114 [en línea] ERROR: KMSAN: kernel-infoleak-after-free en copy_to_user_iter lib/iov_iter.c:24 [en línea] ERROR: KMSAN: kernel-infoleak-after-free en iterate_ubuf include/linux/iov_iter.h:29 [en línea] ERROR: KMSAN: kernel-infoleak-after-free en iterate_and_advance2 include/linux/iov_iter.h:245 [en línea] ERROR: KMSAN: kernel-infoleak-after-free en iterate_and_advance include/linux/iov_iter.h:271 [en línea] ERROR: KMSAN: kernel-infoleak-after-free en _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/ linux/instrumented.h:114 [en línea] copy_to_user_iter lib/iov_iter.c:24 [en línea] iterate_ubuf include/linux/iov_iter.h:29 [en línea] iterate_and_advance2 include/linux/iov_iter.h:245 [en línea] iterate_and_advance include/ linux/iov_iter.h:271 [en línea] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [en línea] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter +0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [en línea] paquete_recvmsg+0xd9c/0x2000 net/packet/af_packet .c:3482 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg net/socket.c:1066 [en línea] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [en línea ] new_sync_read fs/read_write.c:389 [en línea] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [en línea] __se_sys_read fs/ read_write.c:621 [en línea] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/common.c: 83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se almacenó en la memoria en: skb_put_data include/linux/skbuff.h:2622 [en línea] netlink_to_full_skb net/netlink/af_netlink.c:181 [en línea] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [ en línea] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [en línea] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [en línea] netlink_unicast_kernel net/netlink/af_netlink.c :1341 [en línea] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c :745 [en línea] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [en línea] __do_sys_sendmsg net/socket.c:267 6 [en línea ] __se_sys_sendmsg net/socket.c:2674 [en línea] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x44/0x110 arch/x86/ entrada/ common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: free_pages_prepare mm/page_alloc.c:1087 [en línea] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cadence-qspi: elimina las llamadas auxiliares de suspensión en todo el sistema desde los ganchos PM en tiempo de ejecución No se espera que las devoluciones de llamada ->runtime_suspend() y ->runtime_resume() llamen a spi_controller_suspend() y spi_controller_resume(). Elimina llamadas a aquellos en el controlador cadence-qspi. Esos ayudantes tienen actualmente dos funciones: - Detienen/inician la cola, incluido el trato con el kworker. - Alternan el indicador SPI_CONTROLLER_SUSPENDED del controlador SPI. Requiere adquirir ctlr->bus_lock_mutex. El primer paso es irrelevante porque cadence-qspi no está en cola. Sin embargo, el segundo paso tiene dos implicaciones: - Se produce un punto muerto, porque ->runtime_resume() se llama en un contexto donde el bloqueo ya está tomado (en la devolución de llamada ->exec_op(), donde se incrementa el recuento de uso). - No permitiría todas las operaciones una vez que el dispositivo se autosuspenda. Aquí hay un breve árbol de llamadas que resalta el interbloqueo mutex: spi_mem_exec_op() ... spi_mem_access_start() mutex_lock(&ctlr->bus_lock_mutex) cqspi_exec_mem_op() pm_runtime_resume_and_get() cqspi_resume() spi_controller_resume() mutex_lock(&ctlr->bus_lock_mutex) ... spi_mem _acceso_end () mutex_unlock(&ctlr->bus_lock_mutex) ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cadence-qspi: corrige la referencia del puntero en los ganchos PM en tiempo de ejecución dev_get_drvdata() se utiliza para adquirir el puntero a cqspi y el controlador SPI. Ninguno de los dos integra al otro; Esto conduce a la corrupción de la memoria. En una plataforma determinada (Mobileye EyeQ5), la corrupción de la memoria está oculta dentro de cqspi->f_pdata. Además, esta memoria no inicializada se utiliza como mutex (ctlr->bus_lock_mutex) por spi_controller_suspend().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: corrige el use-after-free en el descifrado fallido del trabajo pendiente Cuando la solicitud de descifrado va al trabajo pendiente y crypto_aead_decrypt devuelve -EBUSY, tls_do_decryption esperará hasta que se hayan completado todos los descifrados asíncronos. Si uno de ellos falla, tls_do_decryption devolverá -EBADMSG y tls_decrypt_sg salta a la ruta del error, liberando todas las páginas. Pero las páginas se pasaron a la devolución de llamada asíncrona y tls_decrypt_done ya las publicó. El único caso asíncrono verdadero es cuando crypto_aead_decrypt devuelve -EINPROGRESS. Con -EBUSY, ya esperamos para poder decirle a tls_sw_recvmsg que los datos están disponibles para copia inmediata, pero debemos notificar a tls_decrypt_sg (a través del nuevo indicador ->async_done) que la memoria ya ha sido liberada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige la doble liberación al desmantelar el socket cuando el servidor MPTCP acepta una conexión entrante, clona su socket de escucha. Sin embargo, el puntero a 'inet_opt' para el nuevo socket tiene el mismo valor que el original: como consecuencia, al salir del programa es posible observar el siguiente símbolo: ERROR: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free de addr ffff888485950880 por task swapper/25/0 CPU: 25 PID: 0 Comm: swapper/25 Kdump: cargado No contaminado 6.8.0-rc1+ #609 Nombre de hardware: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF /iF, BIOS 3.0 26/07/2013 Seguimiento de llamadas: dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x 54f/0x8b0 __sk_destruct+0x48/ 0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 asm_sysvec_apic _timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Código: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 00000000000000000 RBX: ffff88887facddc8 RCX: 00000 00000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 00000000000000004 R08: 0000000000000002 R09: 0000000000043 080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 00000000000000000 R15: 00000022c880ec80 cpuidle_enter+ 0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 second_startup_64_no_verify+0x184/0x18b Asignado por tarea 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_net lbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 seguridad_socket_post_create+0x63/0xb0 __sock_create+0x305 /0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Liberado por la tarea 68 58: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/ 0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy _sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/ 0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_ local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 Process_backlog+0x1e3/0x650 __napi_poll+0xa6/ 0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 La dirección con errores pertenece al objeto en ffff888485950880 que pertenece al caché kmalloc-64 de tamaño 64. La dirección con errores se encuentra a 0 bytes dentro de la región de 64 bytes [ffff888485950880, ffff88848 59508c0) El La dirección con errores pertenece a la página física: página:0000000056d1e95e refcount:1 mapcount:0 mapeo:0000000000000000 índice:0xffff888485950700 pfn:0x485950 banderas: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1f ffff) tipo_página: 0xffffffff() sin procesar : 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888485950780: fa fb fb ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pmdomain: arm: corrigió la desreferencia NULL en la eliminación de scmi_perf_domain Al descargar el módulo scmi_perf_domain obtuvo el siguiente símbolo, cuando en el DT se proporcionó al SYSTEM bajo prueba el '#power-domain- Faltaba la propiedad de las células. De hecho, esta configuración particular hace que la sonda se retire antes de tiempo sin dar ningún error, lo que lleva a que la devolución de llamada ->remove() también se ejecute, pero sin todas las estructuras inicializadas esperadas en su lugar. Agregue un cheque y salve anticipadamente la eliminación también. Seguimiento de llamadas: scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain] scmi_dev_remove+0x28/0x40 [scmi_core] device_remove+0x54/0x90 device_release_driver_internal+0x1dc/0x240 driver_detach+0x58/0xa8 bus_remove_driver+0x78 /0x108 controlador_unregister+0x38/0x70 scmi_driver_unregister+0x28/0x180 [ scmi_core] scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain] __arm64_sys_delete_module+0x1a8/0x2c0 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x2 4/0x38 el0_svc+0x34/0xb8 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Código : a90153f3 f9403c14 f9414800 955f8a05 (b9400a80) ---[ final de seguimiento 00000000000000000 ]---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommufd: Se corrigió falla de protección en iommufd_test_syz_conv_iova Syzkaller informó el siguiente error: falla de protección general, probablemente para dirección no canónica 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr- deref en el rango [0x00000000000001c0-0x00000000000001c7] Seguimiento de llamadas: lock_acquire lock_acquire+0x1ce/0x4f0 down_read+0x93/0x4a0 iommufd_test_syz_conv_iova+0x56/0x1f0 iommufd_test_access_rw.isra. 0+0x2ec/0x390 iommufd_test+0x1058/0x1e30 iommufd_fops_ioctl+0x381/0x510 vfs_ioctl __do_sys_ioctl __se_sys_ioctl __x64_sys_ioctl +0x170/0x1e0 do_syscall_x64 do_syscall_64+0x71/0x140 Esto se debe a que el nuevo iommufd_access_change_ioas() establece access->ioas en NULL durante su proceso, por lo que el bloqueo podría desaparecer en un contexto de ejecución concurrente. Solucione este problema haciendo el mismo acceso->ioas cordura que hacen las funciones iommufd_access_rw() y iommufd_access_pin_pages().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommufd: corrige el error de sobrescritura de iopt_access_list_id Syzkaller informó lo siguiente WARN_ON: ADVERTENCIA: CPU: 1 PID: 4738 en drivers/iommu/iommufd/io_pagetable.c:1360 Seguimiento de llamadas: iommufd_access_change_ioas+0x2fe /0x4e0 iommufd_access_destroy_object+0x50/0xb0 iommufd_object_remove+0x2a3/0x490 iommufd_object_destroy_user iommufd_access_destroy+0x71/0xb0 iommufd_test_staccess_release+0x89/0xd0 __fput+0x272/0x b50 __fput_sync+0x4b/0x60 __do_sys_close __se_sys_close __x64_sys_close+0x8b/0x110 do_syscall_x64 La falta de coincidencia entre el puntero de acceso en la lista y el puntero pasado resulta de una sobrescritura de acceso->iopt_access_list_id, en iopt_add_access(). Llamado desde iommufd_access_change_ioas() cuando xa_alloc() tiene éxito pero iopt_calculate_iova_alignment() falla. Agregue un new_id en iopt_add_access() y actualice solo iopt_access_list_id cuando regrese exitosamente.