Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/iucv: MSG_PEEK provoca una pérdida de memoria en iucv_sock_destruct(). Pasar el indicador MSG_PEEK a skb_recv_datagram() incrementa el recuento de referencias de skb (skb->users) y iucv_sock_recvmsg() no decrementa el recuento de referencias de skb al salir. Esto da como resultado una pérdida de memoria de skb en skb_queue_purge() y WARN_ON en iucv_sock_destruct() durante el cierre del socket. Para solucionar esto, disminuya el recuento de referencias de skb en uno si MSG_PEEK está configurado para evitar la pérdida de memoria y WARN_ON. ADVERTENCIA: CPU: 2 PID: 6292 en net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: cargado Contaminado: GW 6.10.0-rc7 #1 Nombre del hardware: IBM 3931 A01 704 (z/VM 7.3.0) Rastreo de llamadas: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Última dirección del evento de interrupción: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: se corrige un posible desbordamiento de matriz en ucsi_ccg_sync_control(). El usuario puede controlar la variable "command" a través de debugfs. La preocupación es que si con_index es cero, entonces "&uc->ucsi->connector[con_index - 1]" sería un desbordamiento de matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Corregir parámetros de espacio de anillo de recepción cuando XDP está activo La configuración de MTU en el momento en que se adjunta un multi-buffer XDP determina si se utilizará el anillo de agregación y el controlador rx_skb_func. Esto se hace en bnxt_set_rx_skb_mode(). Si la MTU se cambia más tarde, es posible que sea necesario cambiar la configuración del anillo de agregación y que deje de estar sincronizada con la configuración realizada inicialmente en bnxt_set_rx_skb_mode(). Esto puede provocar una corrupción aleatoria de la memoria y fallas, ya que el hardware puede DMA datos más grandes que el tamaño de búfer asignado, como: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000003c0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 17 PID: 0 Comm: swapper/17 Kdump: cargado Tainted: GS OE 6.1.0-226bf9805506 #1 Nombre del hardware: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 26/08/2021 RIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en] Código: 8b 95 70 es ff es ff es 4c 8b 9d 48 es ff es ff es 66 41 89 87 b4 00 00 00 e9 0b f7 es ff es 0f b7 43 0a 49 8b 95 a8 04 00 00 25 es ff es 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202 RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 000000000000007ff RDX: 00000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380 RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf R10: 000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980 R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990 FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en] Para solucionar el problema, ahora llamamos a bnxt_set_rx_skb_mode() dentro de bnxt_change_mtu() para configurar correctamente la configuración de anillos AGG y actualizar rx_skb_func en función del nuevo valor de MTU. Además, BNXT_FLAG_NO_AGG_RINGS se borra al comienzo de bnxt_set_rx_skb_mode() para asegurarnos de que se configure o borre en función de la MTU actual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: deshacerse de userspace_irqchip_in_use El uso inadecuado de userspace_irqchip_in_use provocó que syzbot ejecutara el siguiente WARN_ON() en kvm_timer_update_irq(): ADVERTENCIA: CPU: 0 PID: 3281 en arch/arm64/kvm/arch_timer.c:459 kvm_timer_update_irq+0x21c/0x394 Rastreo de llamadas: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [en línea] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [en línea] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl fs/ioctl.c:893 [en línea] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] anybody_syscall+0x78/0x1b8 another_syscall arch/arm64/kernel/syscall.c:49 another_svc_common+0xe8/0x1b0 another_syscall arch/arm64/kernel/syscall.c:132 another_svc+0x40/0x50 another_syscall arch/arm64/kernel/syscall.c:151 another_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 La siguiente secuencia condujo al escenario: - El espacio de usuario crea una VM y una vCPU. - La vCPU se inicializa con KVM_ARM_VCPU_PMU_V3 durante KVM_ARM_VCPU_INIT. - Sin ninguna otra configuración, como vGIC o vPMU, el espacio de usuario emite KVM_RUN en la vCPU. Dado que se solicita la vPMU, pero no se configura, kvm_arm_pmu_v3_enable() falla en kvm_arch_vcpu_run_pid_change(). Como resultado, KVM_RUN regresa después de habilitar el temporizador, pero antes de incrementar 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignora el error y emite KVM_ARM_VCPU_INIT nuevamente. Como el temporizador ya está habilitado, el control se mueve a través del siguiente flujo, y finalmente llega a WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret); Teóricamente, dado que la funcionalidad de userspace_irqchip_in_use se puede reemplazar simplemente por '!irqchip_in_kernel()', deshágase de la clave estática para evitar la mala administración, lo que también ayuda con el problema de syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: imx-audmix: Agregar comprobación NULL en imx_audmix_probe. devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto en imx_audmix_probe() no se comprueba. Agregar comprobación NULL en imx_audmix_probe() para controlar el error de desreferencia de puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige la comprobación nula de pipe_ctx->plane_state en hwss_setup_dpp Esta confirmación soluciona un problema de desreferencia de puntero nulo en hwss_setup_dpp(). El problema podría ocurrir cuando pipe_ctx->plane_state es nulo. La corrección agrega una comprobación para garantizar que `pipe_ctx->plane_state` no sea nulo antes de acceder. Esto evita una desreferencia de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipe Esta confirmación soluciona un problema de desreferencia de puntero nulo en dcn20_program_pipe(). Anteriormente, el commit 8e4ed3cf1642 ("drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe") solucionó parcialmente el problema de desreferencia de puntero nulo. Sin embargo, en dcn20_update_dchubp_dpp(), se pasa la variable pipe_ctx y se accede nuevamente a plane_state a través de pipe_ctx. Varias declaraciones if llaman directamente a los atributos de plane_state, lo que lleva a posibles problemas de desreferencia de puntero nulo. Este parche agrega las comprobaciones nulas necesarias para garantizar la estabilidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se solucionó una posible pérdida de recursos en fw_log_firmware_info(). La instancia de alg debe liberarse en la ruta de excepción; de lo contrario, puede haber una pérdida de recursos aquí. Para mitigar esto, libere la instancia de alg con crypto_free_shash cuando kmalloc falle.

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: 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.