Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Fix use-after-free of slot->bus on hot remove Dennis informa un fallo de arranque en portátiles Lenovo recientes con un dock USB4. Desde el commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") y el commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), los routers host USB4 v2 y v1 se restablecen al sondear el controlador Thunderbolt. El restablecimiento borra los bits de estado de detección de presencia y de enlace de capa de enlace de datos activo en el puerto raíz del router host USB4 y, por lo tanto, provoca la eliminación en caliente del dock. El fallo se produce cuando pciehp se desvincula de uno de los puertos de bajada del dock: pciehp crea un pci_slot al vincularlo y lo destruye al desvincularlo. El pci_slot contiene un puntero al pci_bus debajo del puerto de bajada, pero nunca se adquiere una referencia en ese pci_bus. El pci_bus se destruye antes que el pci_slot, por lo que se produce un use-after-free cuando pci_slot_release() accede a slot->bus. En principio, esto no debería suceder porque pci_stop_bus_device() desvincula pciehp (y, por lo tanto, destruye el pci_slot) antes de que pci_remove_bus_device() destruya el pci_bus. Sin embargo, el seguimiento de la pila proporcionado por Dennis muestra que pciehp se desvincula de pci_remove_bus_device() en lugar de pci_stop_bus_device(). Para comprender la importancia de esto, es necesario saber que el núcleo PCI utiliza un proceso de dos pasos para eliminar una parte de la jerarquía: primero desvincula todos los controladores en la subjerarquía en pci_stop_bus_device() y luego elimina los dispositivos en pci_remove_bus_device(). No hay ninguna precaución para evitar la vinculación del controlador entre pci_stop_bus_device() y pci_remove_bus_device(). En el caso de Dennis, parece que la eliminación de la jerarquía por parte de pciehp compite con la vinculación del controlador por parte de pci_bus_add_devices(). pciehp está vinculado al puerto descendente después de que se haya ejecutado pci_stop_bus_device(), por lo que se desvincula mediante pci_remove_bus_device() en lugar de pci_stop_bus_device(). Debido a que pci_bus ya se ha destruido en ese punto, los accesos a él dan como resultado un use-after-free. Se podría concluir que es necesario evitar la vinculación del controlador después de que se haya ejecutado pci_stop_bus_device(). Sin embargo, parece arriesgado que pci_slot apunte a pci_bus sin contener una referencia. Confiar únicamente en el orden correcto de la desvinculación del controlador frente a la destrucción de pci_bus ciertamente no es programación defensiva. Si pci_slot necesita acceder a datos en pci_bus, debe adquirir una referencia. Modifique pci_create_slot() en consecuencia. Dennis informa que el bloqueo no se puede reproducir con este cambio. Rastreo de pila abreviado: pcieport 0000:00:07.0: PME: Señalización con IRQ 156 pcieport 0000:00:07.0: pciehp: Ranura n.º 12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, creó la ranura física 12 pcieport 0000:00:07.0: pciehp: Ranura (12): Tarjeta no presente... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 comando de escritura 0 Oops: error de protección general, probablemente para una dirección no canónica 0x6b6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp No contaminado 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 ranura de destrucción pci pciehp_remove servicio de eliminación de puerto pcie dispositivo de liberación de controlador interno de bus eliminar dispositivo_eliminar_dispositivo anular_registro_dispositivo eliminar_iter dispositivo_para_cada_hijo_eliminar_puerto_pcie dispositivo_eliminar_dispositivo_liberación_controlador_interno_bus_eliminar_dispositivo dispositivo_eliminar pci_remove_bus_device (invocación recursiva) -- truncado----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: No retire la instrucción MMIO abortada Devolver una interrupción al invitado para un acceso MMIO no compatible es una característica documentada de KVM UAPI. Sin embargo, está claro que esta instalación ha sido sometida a pruebas limitadas, ya que el espacio de usuario puede causar trivialmente una ADVERTENCIA en el retorno de MMIO: ADVERTENCIA: CPU: 0 PID: 30558 en arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Rastreo de llamadas: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [en línea] __se_sys_ioctl fs/ioctl.c:893 [en línea] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] anybody_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 nobody_svc_common+0x1e0/0x23c hate_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 El splat se queja de que KVM está avanzando la PC mientras hay una excepción pendiente, es decir, que KVM está retirando la instrucción MMIO a pesar de una interrupción externa sincrónica pendiente. Womp womp. Corrija el evidente error de UAPI omitiendo toda la emulación MMIO en caso de que haya una excepción sincrónica pendiente. Tenga en cuenta que si bien el espacio de usuario puede dejar pendiente una excepción asincrónica (SError, IRQ o FIQ), aún es seguro retirar la instrucción MMIO en este caso ya que (1) son asincrónicas por definición y (2) KVM depende del soporte de hardware para dejar pendiente/entregar estas excepciones en lugar de la máquina de estado del software para el avance de la PC.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: soluciona el problema de que los recursos no se liberan correctamente en xenbus_dev_probe() Este parche soluciona un problema en la función xenbus_dev_probe(). En la función xenbus_dev_probe(), dentro de la rama if (err) en la línea 313, el programa devuelve incorrectamente err directamente sin liberar los recursos asignados por err = drv->probe(dev, id). Como el valor de retorno no es cero, las capas superiores suponen que la lógica de procesamiento ha fallado. Sin embargo, la operación de sondeo se realizó antes sin una operación de eliminación correspondiente. Dado que el sondeo realmente asigna recursos, no realizar la operación de eliminación podría provocar problemas. Para solucionar este problema, seguimos la lógica de liberación de recursos de la función xenbus_dev_remove() agregando un nuevo bloque fail_remove antes del bloque fail_put. Después de ingresar a la rama if (err) en la línea 313, la función usará una declaración goto para saltar al bloque fail_remove, lo que garantiza que los recursos adquiridos previamente se liberen correctamente, evitando así la fuga del recuento de referencias. Este error fue identificado por una herramienta de análisis estático experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas en los que los recursos no se administran correctamente. En este caso, la herramienta marcó la operación de liberación faltante como un problema potencial, lo que llevó al desarrollo de este parche.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Se corrigen posibles accesos fuera de los límites para dispositivos Extigy y Mbox Un dispositivo falso puede proporcionar un valor bNumConfigurations que exceda el valor inicial utilizado en usb_get_configuration para asignar dev->config. Esto puede provocar accesos fuera de los límites más adelante, por ejemplo, en usb_destroy_configuration.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en la gestión de solicitudes SMB Existe una condición de ejecución entre la gestión de solicitudes SMB en `ksmbd_conn_handler_loop()` y la liberación de `ksmbd_conn` en el controlador de cola de trabajo `handle_ksmbd_work()`. Esto conduce a una UAF. - KASAN: slab-use-after-free Leer en handle_ksmbd_work - KASAN: slab-use-after-free en rtlock_slowlock_locked Esta condición de ejecución surge de la siguiente manera: - `ksmbd_conn_handler_loop()` espera a que `conn->r_count` llegue a cero: `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);` - Mientras tanto, `handle_ksmbd_work()` decrementa `conn->r_count` usando `atomic_dec_return(&conn->r_count)`, y si llega a cero, llama a `ksmbd_conn_free()`, que libera a `conn`. - Sin embargo, después de que `handle_ksmbd_work()` disminuya `conn->r_count`, aún puede acceder a `conn->r_count_q` en la siguiente línea: `waitqueue_active(&conn->r_count_q)` o `wake_up(&conn->r_count_q)` Esto da como resultado un UAF, ya que `conn` ya se ha liberado. Se puede hacer referencia al descubrimiento de este UAF en la siguiente PR para el soporte de syzkaller para solicitudes SMB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: comprobar si hay desbordamientos en io_pin_pages ADVERTENCIA: CPU: 0 PID: 5834 en io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 No contaminado 6.12.0-next-20241118-syzkaller #0 Seguimiento de llamadas: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [en línea] El parámetro uaddr de io_pin_pages() proviene directamente del usuario y puede ser basura. No le agregue tamaño, ya que puede desbordarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige el fallo al desvincular Si hay un error durante alguna inicialización relacionada con el firmware, se llama a la función ath12k_dp_cc_cleanup para liberar recursos. Sin embargo, esto se libera de nuevo cuando se desvincula el dispositivo (ath12k_pci), y obtenemos: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000020 en RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] Seguimiento de llamadas: ath12k_dp_cc_cleanup ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... El problema siempre se puede reproducir desde una máquina virtual porque la inicialización del direccionamiento MSI está fallando. Para solucionar el problema, simplemente establezca en NULL la estructura liberada en ath12k_dp_cc_cleanup al final.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan La matriz channels en cfg80211_scan_request tiene un atributo __counted_by adjunto, que apunta a la variable n_channels. Este atributo se utiliza en la comprobación de los límites y, si no se configura antes de que se complete la matriz, el desinfectante de los límites emitirá una advertencia o un pánico del kernel si se configura CONFIG_UBSAN_TRAP. Este parche establece el tamaño de la memoria asignada como el valor inicial para n_channels. Se actualiza con el número real de elementos agregados después de que se complete la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corregir advertencia al desvincular Si hay un error durante alguna inicialización relacionada con el firmware, se liberan los búferes dp->tx_ring[i].tx_status. Sin embargo, esto se libera nuevamente cuando se desvincula el dispositivo (ath12k_pci), y obtenemos: ADVERTENCIA: CPU: 0 PID: 2098 en mm/slub.c:4689 free_large_kmalloc+0x4d/0x80 Rastreo de llamadas: free_large_kmalloc ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... El problema siempre se puede reproducir desde una VM porque la inicialización de la dirección MSI está fallando. Para solucionar el problema, simplemente configure los búferes en NULL después de liberar para evitar la doble liberación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: clk-loongson2: Se corrige un desbordamiento de búfer potencial en el acceso a miembros de la matriz flexible El miembro de la matriz flexible `hws` en `struct clk_hw_onecell_data` está anotado con el atributo `counted_by()`. Esto significa que cuando se asigna memoria para esta matriz, el _contador_, que en este caso es el miembro `num` en la estructura flexible, se debe establecer en el número máximo de elementos que la matriz flexible puede contener, o menos. En este caso, el número total de elementos para la matriz flexible se determina mediante la variable `clks_num` al asignar espacio de montón a través de `devm_kzalloc()`, como se muestra a continuación: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Por lo tanto, `clp->clk_data.num` debe establecerse en `clks_num` o menos, y no superar `clks_num`, como es el caso actualmente. De lo contrario, si los datos se escriben en `clp->clk_data.hws[clks_num]`, la instrumentación proporcionada por el compilador no detectará el desbordamiento, lo que provocará un error de corrupción de memoria en tiempo de ejecución. Solucione este problema estableciendo `clp->clk_data.num` en `clks_num`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: clk-loongson2: Se corrige un error de corrupción de memoria en struct loongson2_clk_provider. Se asigna algo de espacio de montón para la estructura flexible `struct clk_hw_onecell_data` y su miembro de matriz flexible `hws` a través de la estructura compuesta `struct loongson2_clk_provider` en la función `loongson2_clk_probe()`, como se muestra a continuación: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Luego, se escriben algunos datos en la matriz flexible: 350 clp->clk_data.hws[p->id] = hw; Esto corrompe `clk_lock`, que es la variable spinlock que sigue inmediatamente al miembro `clk_data` en `struct loongson2_clk_provider`: struct loongson2_clk_provider { void __iomem *base; struct device *dev; struct clk_hw_onecell_data clk_data; spinlock_t clk_lock; /* proteger el acceso a los registros DIV */ }; El problema es que la estructura flexible actualmente está ubicada en el medio de `struct loongson2_clk_provider` en lugar de al final. Solucione esto moviendo `struct clk_hw_onecell_data clk_data;` al final de `struct loongson2_clk_provider`. Además, agregue un comentario de código para ayudar a evitar que esto vuelva a suceder en caso de que se agreguen nuevos miembros a la estructura en el futuro. Este cambio también corrige la siguiente advertencia -Wflex-array-member-not-at-end: drivers/clk/clk-loongson2.c:32:36: advertencia: la estructura que contiene un miembro de matriz flexible no está al final de otra estructura [-Wflex-array-member-not-at-end]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtlwifi: Reduce drásticamente los intentos de leer efuse en caso de fallos Syzkaller informó de una tarea colgada con uevent_show() en el seguimiento de la pila. Ese problema específico fue abordado por otra confirmación [0], pero incluso con esa corrección aplicada (por ejemplo, ejecutando v6.12-rc5) nos enfrentamos a otro tipo de tarea colgada que proviene del mismo reproductor [1]. Al investigar eso, pudimos reducirlo a la siguiente ruta: (a) Syzkaller emula un adaptador WiFi USB Realtek utilizando raw-gadget y la infraestructura dummy_hcd. (b) Durante el sondeo de rtl8192cu, el controlador termina realizando un procedimiento de lectura de efuse (que está relacionado con la carga de EEPROM IIUC), y aquí radica el problema: la función read_efuse() llama a read_efuse_byte() muchas veces, como iteraciones de bucle dependiendo del tamaño de efuse (en nuestro ejemplo, 512 en total). Este procedimiento para leer bytes de efuse se basa en un bucle que realiza una lectura de E/S hasta *10k* veces en caso de fallas. Medimos el tiempo del bucle dentro de read_efuse_byte() solamente, y en este reproductor (que involucra la capa de emulación dummy_hcd), toma 15 segundos cada uno. Como consecuencia, tenemos al controlador atascado en su rutina de sondeo por mucho tiempo, exponiendo un seguimiento de pila como el siguiente si intentamos reiniciar el sistema, por ejemplo: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 lectura_efuse_byte+0x13c/0x146 lectura_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] Proponemos reducir drásticamente los intentos de realizar lecturas de E/S en caso de fallos, restringidos a dispositivos USB (dado que son inherentemente más lentos que los PCIe). Al reintentar hasta 10 veces (en lugar de 10000), obtuvimos capacidad de respuesta en el reproductor, aunque parece razonable creer que no existe una implementación sensata de dispositivos USB en el campo que requiera esta cantidad de reintentos en cada lectura de E/S para funcionar correctamente. En base a esa suposición, sería bueno tenerlo retroportado a estable, pero tal vez no desde la implementación del controlador (el número 10k proviene del día 0), tal vez hasta la serie 6.x tenga sentido. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] Una nota sobre eso: este informe de syzkaller presenta múltiples reproductores que difieren según el tipo de dispositivo USB emulado. Para este caso específico, verifique la entrada de 2024/08/08 06:23 en la lista de fallas; la reproducción en C está disponible en https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.