Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: core: corrige el bloqueo en usb_kill_urb agregando barreras de memoria el syzbot fuzzer ha identificado un error en el que los procesos se bloquean esperando que regrese usb_kill_urb(). Resulta que el problema no es desvincular la URB; eso funciona bien. Más bien, el problema surge cuando no se recibe la notificación de activación de que la URB ha completado. El motivo son los pedidos de acceso a la memoria en los sistemas SMP. En forma resumida, usb_kill_urb() y __usb_hcd_giveback_urb() operando simultáneamente en diferentes CPU realizan las siguientes acciones: CPU 0 CPU 1 ------------------------- --- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->rechazar); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Limitando su atención a urb->reject y urb->use_count, puede ver que el patrón general de accesos en la CPU 0 es: escribir urb->reject, luego leer urb->use_count; mientras que el patrón general de accesos en la CPU 1 es: escribir urb->use_count, luego leer urb->reject. En los círculos de modelos de memoria se hace referencia a este patrón como SB (por "Store Buffering"), y es bien sabido que sin una aplicación adecuada del orden deseado de accesos (en forma de barreras de memoria) es completamente posible que una o ambas CPU para ejecutar sus lecturas antes de sus escrituras. El resultado final será que a veces la CPU 0 ve el antiguo valor no incrementado de urb->use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb->reject. En consecuencia, la CPU 0 termina en la cola de espera y nunca se activa, lo que provoca el bloqueo observado en usb_kill_urb(). El mismo patrón de accesos ocurre en usb_poison_urb() y la ruta de falla de usb_hcd_submit_urb(). El problema se soluciona agregando barreras de memoria adecuadas. Para proporcionar un orden adecuado de acceso a la memoria en el patrón SB, se requiere una barrera completa en ambas CPU. Los accesos atomic_inc() y atomic_dec() en sí no proporcionan ningún orden de memoria, pero como están presentes, podemos usar la barrera de memoria optimizada smp_mb__after_atomic() en las distintas rutinas para obtener el efecto deseado. Este parche agrega las barreras de memoria necesarias.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: xhci-plat: corrige el bloqueo al suspender si se habilita la activación remota. Falló en la plataforma i.mx8qm al suspender si se habilita la activación remota. Error interno: aborto externo sincrónico: 96000210 [#1] PREEMPT Módulos SMP vinculados en: CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12 Nombre del hardware: Freescale i.MX8QM MEK (DT) Cola de trabajo: events_unbound async_run_entry_fn pstate: 600000c5 (nZCv daIF - PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: xhci_disable_hub_port_wake.isra.62+0x60/0xf8 lr: xhci_disable_hub_port_wake.isra.62+0x34/0xf8 sp: ffff80001394bbf0 x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578 x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000 x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001 x20: 0000000000000000 x19: ffff800014e90490 x18: 000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0 x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453 x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff000811 93a29c x2: 0000000000000001 x1: 0000000000000000 x0: ffff000814591620 Rastreo de llamadas: xhci_disable_hub_port_wake.isra.62+0x60/0xf8 xhci_suspend+0x58/0x510 0x50/ 0x78 platform_pm_suspend+0x2c/0x78 dpm_run_callback.isra.25+0x50/0xe8 __device_suspend+0x108/0x3c0 El flujo básico: 1. llamada de suspensión en tiempo de ejecución xhci_suspend, los dispositivos principales xhci controlan el reloj. 2. echo mem >/sys/power/state, system _device_suspend llama a xhci_suspend 3. xhci_suspend llama a xhci_disable_hub_port_wake, que accede al registro, pero el reloj ya está cerrado por la suspensión del tiempo de ejecución. Este problema fue ocultado por el controlador de dominio de energía, que solicita la reanudación del tiempo de ejecución antes. Pero el siguiente compromiso lo elimina y hace que este problema suceda. commit c1df456d0f06e ("PM: dominios: no reanudar el tiempo de ejecución de los dispositivos en genpd_prepare()") Este parche llama al tiempo de ejecución para reanudar antes de la suspensión para asegurarse de que el reloj esté encendido antes del registro de acceso. Testeb-by: Abel Vesa

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: extable: corrige los índices de registro load_unaligned_zeropad() En ex_handler_load_unaligned_zeropad() extraemos erróneamente los datos y los índices de registro de direcciones de ex->type en lugar de ex->data. Como ex->type contendrá EX_TYPE_LOAD_UNALIGNED_ZEROPAD (es decir, 4): * Siempre trataremos a X0 como el registro de dirección, ya que EX_DATA_REG_ADDR se extrae de los bits [9:5]. Por lo tanto, podemos intentar eliminar la referencia a una dirección arbitraria ya que X0 puede tener un valor arbitrario. * Siempre trataremos a X4 como el registro de datos, ya que EX_DATA_REG_DATA se extrae de los bits [4:0]. Por lo tanto, corromperemos X4 y provocaremos un comportamiento arbitrario dentro de load_unaligned_zeropad() y su llamador. Solucione este problema extrayendo ambos valores de ex->data como se pretendía originalmente. En una imagen QEMU habilitada para MTE, nos encontramos con el siguiente bloqueo: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 Rastreo de llamadas: fixup_exception+0xc4/0x108 __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0 xf4 el1_abort+ 0x40/0x64 el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_s ys_openat+0x74/0xa0 invoke_syscall+0x48/0x148 el0_svc_common+0xb8/0xf8 do_el0_svc+ 0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 Código: f8695a69 71007d1f 540000e0 927df12a (f940014a)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: x86: abandonar por la fuerza la virt anidada cuando se alterna el estado de SMM. Dejar por la fuerza la operación de virtualización anidada si el espacio de usuario alterna el estado de SMM mediante KVM_SET_VCPU_EVENTS o KVM_SYNC_X86_EVENTS. Si el espacio de usuario fuerza a la vCPU a salir de SMM mientras es posterior a VMXON y luego inyecta un SMI, vmx_enter_smm() sobrescribirá vmx->nested.smm.vmxon y terminará con vmxon=false y smm.vmxon=false, pero todos los demás Estado nVMX asignado. No intente manejar la transición con elegancia ya que (a) la mayoría de las transiciones no tienen sentido, por ejemplo, forzar SMM mientras se ejecuta L2, (b) no hay suficiente información para manejar todas las transiciones, por ejemplo, SVM quiere acceder al estado de guardado de SMRAM, y (c) KVM_SET_VCPU_EVENTS debe preceder a KVM_SET_NESTED_STATE durante la restauración del estado, ya que este último no permite colocar la vCPU en L2 si SMM está activo y no permite etiquetar la vCPU como posterior a VMXON en SMM si SMM no está activo. El abuso de KVM_SET_VCPU_EVENTS se manifiesta como una ADVERTENCIA y una pérdida de memoria en nVMX debido a una falla al liberar el VMCS oculto de vmcs01, pero el error va mucho más allá de una simple pérdida de memoria; por ejemplo, activar SMM mientras L2 está activo coloca la vCPU en un estado arquitectónicamente imposible. ADVERTENCIA: CPU: 0 PID: 3606 en free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [en línea] ADVERTENCIA: CPU: 0 PID: 3606 en free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx. c:2656 Módulos vinculados en: CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [en línea] RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Código: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00 Seguimiento de llamadas: kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123 kvm_vcpu_destroy arch/x86/kvm/../. ./../virt/kvm/kvm_main.c:441 [en línea] kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460 kvm_free_vcpus arch/x86 /kvm/x86.c:11564 [en línea] kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c :1217 [en línea] kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250 kvm_vm_release+0x3f/0x50 arch/x86/kvm/../.. /../virt/kvm/kvm_main.c:1273 __fput+0x286/0x9f0 fs/file_table.c:311 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [en línea] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x4b0/0x28c0 kernel/signal.c:2862 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c :868 handle_signal_work kernel/entry/common.c:148 [en línea] exit_to_user_mode_loop kernel/entry/common.c:172 [en línea] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c :289 [en línea] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Libere la matriz kvm_cpuid_entry2 en KVM_RUN KVM_SET_CPUID{,2} posterior a KVM_RUN KVM_SET_CPUID{,2} Libere la matriz "struct kvm_cpuid_entry2" en KVM_RUN KVM_SET_CPUID{,2} posterior a éxito para corregir una pérdida de memoria , las personas que llaman a kvm_set_cpuid() liberan la matriz solo en caso de falla. ERROR: pérdida de memoria, objeto sin referencia 0xffff88810963a800 (size 2048): comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00 ................ 47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00 GenuntelineI.... backtrace: [] kmalloc_node include/linux/slab.h:604 [inline] [] kvmalloc_node+0x3e/0x100 mm/util.c:580 [] kvmalloc include/linux/slab.h:732 [inline] [] vmemdup_user+0x22/0x100 mm/util.c:199 [] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423 [] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251 [] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:874 [inline] [] __se_sys_ioctl fs/ioctl.c:860 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: LAPIC: cancele también el temporizador de preferencia durante SET_LAPIC La siguiente advertencia aparece durante el reinicio del invitado. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 1931 en arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+ 0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Contaminado: GI 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Seguimiento de llamadas: 79 /0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b Esto se puede activar al no exponer el modo tsc-deadline y reiniciar el invitado. La función lapic_shutdown() que se llama en la ruta sys_reboot no desarmará el temporizador de vuelo, simplemente enmascara el LVTT. lapic_shutdown() borra el estado de APIC con LVT_MASKED y el bit del modo de temporizador es 0, esto puede activar el cambio del modo de temporizador entre tsc-deadline y oneshot/periódico, lo que puede provocar que el temporizador de preferencia se cancele en apic_update_lvtt(). Sin embargo, no podemos depender de esto cuando no exponemos el modo tsc-deadline y los modos oneshot/periódico emulados por el temporizador de preferencia. Qemu sincronizará los estados alrededor del reinicio, cancelemos el temporizador de preferencia en KVM_SET_LAPIC.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Wrap dcn301_calculate_wm_and_dlg para FPU. Refleja la lógica de dcn30. Sin esta solución, aparecen muchas ADVERTENCIAS y algunos pánicos del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: coloque correctamente la referencia ceph_string después del intento de creación asíncrona. La referencia adquirida por try_prep_async_create se ha filtrado actualmente. Asegúrate de que lo pongamos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo/histograma: corrige una posible pérdida de memoria para kstrdup(). Falta kfree() en una ruta de error para liberar la memoria asignada por kstrdup(): p = param = kstrdup( datos->params[i], GFP_KERNEL); Por eso es mejor liberarlo mediante kfree(p).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi: runtime: evite los servicios de tiempo de ejecución EFIv2 en máquinas Apple x86 Aditya informa [0] que su reciente MacbookPro falla en el firmware cuando usa los servicios variables en tiempo de ejecución. El culpable parece ser una llamada a QueryVariableInfo(), que no utilizamos para llamar a máquinas Apple x86 en el pasado, ya que recientemente se actualizaron del firmware EFI v1.10 al firmware EFI v2.40, y QueryVariableInfo() (junto con con UpdateCapsule() et al) se agregó en EFI v2.00. El único servicio de tiempo de ejecución introducido en EFI v2.00 que realmente usamos en Linux es QueryVariableInfo(), ya que los basados en cápsulas son opcionales y generalmente no se usan en tiempo de ejecución (toda la infraestructura de actualización de firmware LVFS/fwupd utiliza programas EFI auxiliares que invocan la cápsula). actualizar en el momento del arranque, no en el tiempo de ejecución) y, en primer lugar, no lo implementan las máquinas Apple. QueryVariableInfo() se utiliza para establecer variables de forma "segura", es decir, sólo cuando hay suficiente espacio. Esto evita que las máquinas con firmwares defectuosos dañen sus NVRAM cuando se quedan sin espacio. Dado que las máquinas Apple han estado usando los servicios EFI v1.10 solo durante más tiempo (la especificación EFI v2.0 se lanzó en 2006 y el soporte de Linux para los servicios de ejecución recientemente introducidos se agregó en 2011, pero el MacbookPro12,1 se lanzó en 2015 todavía afirma ser solo EFI v1.10), evitemos los EFI v2.0 en todas las máquinas Apple x86. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: protección contra el acceso a pt_regs NULL en bpf_get_task_stack() task_pt_regs() puede devolver NULL en powerpc para subprocesos del kernel. Luego, esto se usa en __bpf_get_stack() para verificar el modo de usuario, lo que genera un kernel ups. Protéjase contra esto verificando el valor de retorno de task_pt_regs() antes de intentar obtener la cadena de llamadas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: vlan: corrige la pérdida de memoria en __allowed_ingress Cuando se usa el estado por VLAN, si la vigilancia de VLAN y las estadísticas están deshabilitadas, el marco de ingreso sin etiquetar o con etiqueta de prioridad irá a verificar pvid estado. Si el estado del puerto está reenviando y el estado del pvid no está aprendiendo/reenviando, se descartará la trama sin etiquetar o con etiqueta de prioridad, pero no se liberará la memoria skb. Debería liberar skb cuando __allowed_ingress devuelva falso.