Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/psi: corrige el use after free en ep_remove_wait_queue() si se elimina un cgroup no raíz cuando hay un subproceso que registró un activador y está sondeando un archivo de presión dentro en cgroup, la cola de espera de sondeo se libera en la siguiente ruta: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pression_release psi_trigger_destroy Sin embargo, el hilo de sondeo aún tiene una referencia al archivo de presión y accederá a la cola de espera liberada cuando el archivo se cierre o al salir: fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue Esto da como resultado un use after free como se pega a continuación. El problema fundamental aquí es que cgroup_file_release() (y en consecuencia la vida útil de la cola de espera) no está ligada a la vida real del archivo. Usar wake_up_pollfree() aquí puede no ser ideal, pero está en línea con el comentario en la confirmación 42288cb44c4b ("espera: agregar wake_up_pollfree()") ya que la vida útil de la cola de espera no está ligada a la del archivo y puede considerarse como otro caso especial. . Si bien esto se podría solucionar haciendo que cgroup_file_release() esté vinculado de alguna manera a fput(), requeriría una refactorización considerable en cgroups o en una capa superior, lo que podría ser más justificable si identificamos más casos como este. ERROR: KASAN: use-after-free en _raw_spin_lock_irqsave+0x60/0xc0 Escritura de tamaño 4 en la dirección ffff88810e625328 por tarea a.out/4404 CPU: 19 PID: 4404 Comm: a.out No contaminado 6.2.0-rc6 #38 Hardware nombre: Amazon EC2 c5a.8xlarge/, BIOS 1.0 16/10/2017 Seguimiento de llamadas: dump_stack_lvl+0x73/0xa0 print_report+0x16c/0x4e0 kasan_report+0xc3/0xf0 kasan_check_range+0x2d2/0x310 _raw_spin_lock_irqsave+0x60/0x c0 remove_wait_queue+0x1a /0xa0 ep_free+0x12c/0x170 ep_eventpoll_release+0x26/0x30 __fput+0x202/0x400 task_work_run+0x11d/0x170 do_exit+0x495/0x1130 do_group_exit+0x100/0x100 get_signal+0xd67/0xde0 arch _do_signal_or_restart+0x2a/0x2b0 exit_to_user_mode_prepare+0x94/0x100 syscall_exit_to_user_mode+0x20 /0x40 do_syscall_64+0x52/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd Asignado por tarea 4404: kasan_set_track+0x3d/0x60 __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 Pressure_write+0x1 46/0x2e0 cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/ 0x220 vfs_write+0x3d8/0x5c0 ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd Liberado por la tarea 4407: kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/ 0x40 ____kasan_slab_free+0x11d/0x170 slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/ 0x180 psi_trigger_destroy+0x2e8/0x310 cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0 __kernfs_remove+0x1fb/0x310 ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700 cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/ 0x140 vfs_rmdir+0xfe/0x240 do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd

Una vulnerabilidad de Cross Site Scripting Almacenado (XSS) en la función "Importación de usuarios y nombre de inicio de sesión del usuario" en ILIAS 7 anterior a 7.30 e ILIAS 8 anterior a 8.11 permite a atacantes remotos autenticados con privilegios administrativos inyectar scripts web o HTML de su elección mediante la carga de archivos XML.

Una vulnerabilidad de Cross Site Scripting Almacenado (XSS) en ILIAS 7 anterior a 7.30 e ILIAS 8 anterior a 8.11 permite a atacantes remotos autenticados con privilegios de tutor inyectar scripts web o HTML de su elección mediante la carga de archivos XML.

ILIAS 7 anterior a 7.30 e ILIAS 8 anterior a 8.11, así como ILIAS 9.0, permiten a atacantes remotos autenticados con privilegios administrativos ejecutar comandos del sistema operativo mediante la carga de archivos con tipos peligrosos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, s390: solucione una posible pérdida de memoria sobre jit_data. Asegúrese de liberar jit_data mediante kfree() en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: iscsi: corrige el uso after free de iscsi_task. Confirmación d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") se agregaron llamadas iscsi_get_conn()/iscsi_put_conn() durante el manejo de abortos pero luego también cambió el manejo del caso en el que detectamos una tarea ya completada y ahora terminamos haciendo un acceso al código común de put/cleanup. Esto da como resultado un uso de iscsi_task después de la liberación, porque el código de limpieza común colocará iscsi_task. Esto revierte el ir a y mueve iscsi_get_conn() a después de haber verificado si iscsi_task es válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: programa de reparación, verificación, interrupción, ruta de pila de emergencia. La ruta de pila de emergencia saltaba a una etiqueta 3: dentro de la macro __GEN_COMMON_BODY para la ruta normal después de haber terminado, en lugar de saltar por encima. él. Por un pequeño milagro, este es el lugar correcto para construir un nuevo marco de interrupción con el puntero de pila existente, por lo que las cosas básicamente funcionaron bien con un marco de trampa 700 de aspecto extraño agregado en la parte superior (que tenía el ->nip incorrecto, por lo que no decodificar mensajes de error tampoco). Solucione este problema evitando el uso de etiquetas numéricas al saltar sobre macros no triviales. Antes: LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 Módulos NUMA PowerNV vinculados en: CPU: 0 PID: 88 Comm: sh No contaminado 5.15.0-rc2-00034-ge057cdade6e5 #2637 NIP: 7265677368657265 LR c00000000 006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3a50 TRAP: 0700 No contaminado MSR: 9000000000021031 CR: 00000700 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: 0000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000 001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 000 0000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28 c0000000012700 00 0000000042000000 0000000048ab0778 c000000080647e80 NIP [7265677368657265] 0x7265677368657265 LR [c00000000006c0c8] /0xb10 Seguimiento de llamadas : [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (no confiable) --- interrupción: 700 en decrementer_common_virt+0xb8/0x230 NIP: c0000000000098b8 LR: c00000000006c0 c8 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 MSR no contaminado: 9000000000021031 CR: 22424282 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 0000000000002400 c000000001513800 00000000 00000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 00000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 00000000000000001 GPR16: 0000000000000000 0000 000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 00000000000000080 00007fff89d90158 GPR24: 000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 --- interrupción: 700 Volcado de instrucciones: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ final de seguimiento 6d28218e0cc3c949 ]--- Después: ------------[ cortar aquí ]-------- ---- ¡ERROR del kernel en arch/powerpc/kernel/exceptions-64s.S:491! Vaya: Excepción en modo kernel, sign: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 Módulos NUMA PowerNV vinculados en: CPU: 0 PID: 88 Comm: iniciar sesión No está contaminado 5.15.0-rc2-00034- ge057cdade6e5-dirty #2638 NIP: c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 No contaminado MSR: 90000000000210 31 CR: 24482227 XER: 00040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868 GPR04: 00000000100f0d29 0000000042000000 0000000000000 007 0000000000000009 GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c GPR12: 9000000000009033 c000000001 6b0000 00000000100f0d29 c000000005b22f00 GPR16: 00000000ffff0000 0000000000000001 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: corrige un MCE irrecuperable que llama al controlador asíncrono desde NMI. El controlador de verificación de la máquina no se considera NMI en 64s. El controlador inicial es el verdadero controlador NMI y luego programa el controlador machine_check_exception para que se ejecute cuando las interrupciones estén habilitadas. Esto funciona bien excepto en el caso de un MCE irrecuperable, donde el NMI verdadero se toma cuando MSR[RI] está claro, no se puede recuperar, por lo que llama a machine_check_exception directamente para que se pueda hacer algo al respecto. Llamar a un controlador asíncrono desde el contexto NMI puede provocar que el estado irq y otras cosas se corrompan. Esto también puede desencadenar el ERROR en arch/powerpc/include/asm/interrupt.h:168 BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE)); Solucione este problema creando una versión _async del controlador que se llama en el caso normal, y una versión NMI que se llama para interrupciones irrecuperables.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/entry: borra X86_FEATURE_SMAP cuando CONFIG_X86_SMAP=n confirmación 3c73b81a9164 ("x86/entry, selftests: mejora aún más las comprobaciones de seguridad de entrada del usuario") agregó una advertencia si AC está configurado en el núcleo. La confirmación 662a0221893a3d ("x86/entry: Reparar aserción de AC") cambió la advertencia para que solo se active si la CPU admite SMAP. Sin embargo, la advertencia aún puede activarse en una máquina que admite SMAP pero donde está deshabilitado en la configuración del kernel y cuando se ejecuta la autoprueba syscall_nt, por ejemplo: ------------[ cortar aquí ]--- --------- ADVERTENCIA: CPU: 0 PID: 49 en irqentry_enter_from_user_mode CPU: 0 PID: 49 Comm: init Tainted: GT 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 01/04/2014 RIP: 0010:irqentry_enter_from_user_mode... Seguimiento de llamadas:? irqentry_enter? exc_general_protection? asm_exc_general_protection? Se podría agregar asm_exc_general_protectio IS_ENABLED(CONFIG_X86_SMAP) a la condición de advertencia, pero incluso esto no sería suficiente en caso de que SMAP esté deshabilitado en el momento del arranque con el parámetro "nosmap". Para ser coherente con el comportamiento de "nosmap", borre X86_FEATURE_SMAP cuando !CONFIG_X86_SMAP. Encontrado usando Entry-fuzz + satrandconfig. [pb: mensaje de confirmación de masaje. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la fuga de pin_count de gart.bo gmc_v{9,10}_0_gart_disable() no se llama y coincide con la función gart_enbale correspondiente en el caso SRIOV. Esto provocará una pérdida de pin_count de gart.bo al descargar el controlador.

Una vulnerabilidad de Cross Site Scripting Almacenado (XSS) en la característica "Importación de rol de usuario y título de rol de usuario" en ILIAS 7 anterior a 7.30 e ILIAS 8 anterior a 8.11 permite a atacantes remotos autenticados con privilegios administrativos inyectar scripts web o HTML de su elección mediante la carga de archivos XML.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: mdio: arreglar pérdida de memoria. Syzbot informó una pérdida de memoria en la interfaz del bus MDIO, el problema estaba en una lógica de estado incorrecta. MDIOBUS_ALLOCATED indica 2 estados: 1. El bus solo está asignado 2. El bus asignado y __mdiobus_register() falla, pero se llamó a device_register() En caso de que se haya llamado a device_register() debemos llamar a put_device() para liberar correctamente la memoria asignada para esto dispositivo, pero mdiobus_free() llama solo a kfree(dev) en caso de estado MDIOBUS_ALLOCATED. Para evitar este comportamiento, necesitamos configurar bus->state en MDIOBUS_UNREGISTERED _antes_ de llamar a device_register(), porque put_device() debe llamarse incluso en caso de fallo de device_register( .