Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Mejora de la comprobación de SIGTRAP faltantes. Para detectar la falta de SIGTRAP, empleamos una advertencia en __perf_event_overflow(), que se activa si pending_sigtrap ya estaba configurado: al regresar al espacio de usuario sin consumir pending_sigtrap y luego volver a activar el evento, se reingresaría al kernel y se activaría la advertencia. Sin embargo, esto parecía pasar por alto el caso en el que algunos eventos no asociados con el progreso en la tarea del espacio de usuario pueden activarse y el controlador de interrupciones se ejecuta antes del trabajo de IRQ destinado a consumir pending_sigtrap (y generar la SIGTRAP). syzbot nos proporcionó este seguimiento de pila: | ADVERTENCIA: CPU: 0 PID: 3607 en kernel/events/core.c:9313 __perf_event_overflow | Módulos enlazados en: | CPU: 0 PID: 3607 Comm: syz-executor100 No contaminado 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0 | Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313 | <...> | Seguimiento de llamadas: | | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729 | __run_hrtimer kernel/time/hrtimer.c:1685 [inline] | __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749 | hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 | local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline] | __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113 | sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107 | asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649 | <...> | En este caso, syzbot generó un programa con el tipo de evento PERF_TYPE_SOFTWARE y la configuración PERF_COUNT_SW_CPU_CLOCK. El temporizador hrtimer se vuelve a ejecutar antes de que el trabajo de IRQ tenga la oportunidad de ejecutarse, sin haber regresado al espacio de usuario. Mejore el WARN para comprobar el progreso real en el espacio de usuario: aproxime esto almacenando un hash de 32 bits de la IP actual en pending_sigtrap. Si un evento se dispara mientras pending_sigtrap aún coincide con la IP anterior, asumimos que no hay progreso (los falsos negativos son posibles dado que podríamos regresar al espacio de usuario y disparar de nuevo en la misma IP).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Eliminar el bloqueo de fpregs antes de heredar los permisos de FPU Mike Galbraith informó lo siguiente contra una antigua bifurcación de preempt-rt, pero el mismo problema también se aplica al árbol preempt-rt actual. ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempción deshabilitada en: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: GE (no publicado) Rastreo de llamadas: dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe Mike dice: El problema se debe a que fpu_inherit_perms() se llama bajo fpregs_lock() y a que alcanzamos spin_lock_irq() debido a que fpu_state_size_dynamic() devuelve verdadero a pesar de que la clave estática __fpu_state_size_dynamic nunca se ha habilitado. La evaluación de Mike parece correcta. fpregs_lock en un kernel PREEMPT_RT deshabilita la preempción, por lo que llamar a spin_lock_irq() en fpu_inherit_perms() no es seguro. Este problema existe desde la confirmación 9e798e9aa14c ("x86/fpu: Preparar fpu_clone() para funciones habilitadas dinámicamente"). Aunque el informe de error original no debería haber habilitado las rutas, el error persiste. fpregs_lock es necesario al editar los registros de FPU o el estado de FP de una tarea, pero no es necesario para fpu_inherit_perms(). La única escritura de cualquier estado de FP en fpu_inherit_perms() es para el nuevo hijo, que aún no se está ejecutando y aún no puede cambiar de contexto ni ser tomado prestado por un hilo del kernel. Por lo tanto, fpregs_lock no protege nada en el nuevo hijo hasta que clone() se complete y pueda eliminarse antes. El siglock aún debe ser adquirido por fpu_inherit_perms(), ya que la lectura de los permisos del padre debe serializarse. [bp: Limpieza splat.]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd/uncore: Se corrige una fuga de memoria en la matriz de eventos. Cuando una CPU se conecta, se liberan los contextos de núcleo único (NB) y LLC por CPU, pero no la matriz de eventos dentro de la estructura del contexto. Esto provoca una fuga de memoria, identificada por el detector kmemleak. [...] objeto sin referencia 0xffff8c5944b8e320 (tamaño 32): comm "swapper/0", pid 1, jiffies 4294670387 (edad 151.072s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 objeto sin referencia 0xffff8c5944b8dd40 (tamaño 64): comm "swapper/0", pid 1, jiffies 4294670387 (edad 151.072s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso: [<00000000306efe8b>] preparación de CPU activada de AMD sin núcleo + 0x183/0x230 [<00000000ddc9e126>] devolución de llamada de invocación de CPUHp + 0x2cf/0x470 [<0000000093e727d4>] llamada de emisión de CPUHp + 0x14d/0x170 [<0000000045464d54>] estado de configuración de CPUHp bloqueado + 0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 [...] Solucione el problema liberando la matriz de eventos antes de liberar el contexto uncore.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sgx: Se ha añadido una comprobación de desbordamiento en sgx_validate_offset_length(). La función sgx_validate_offset_length() verifica los argumentos "offset" y "length" proporcionados por el espacio de usuario, pero no incluía una comprobación de desbordamiento al añadirlos. Añádala.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: fija correctamente el padre en blkcg_css_online. Se supone que blkcg_css_online fija el blkcg del padre, pero 397c9f46ee4d refactorizó las cosas y, de paso, lo modificó para fijar el CSS. Esto genera fijaciones adicionales y terminamos filtrando blkcgs y cgroups.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: sdhci-pci: Se corrige una posible fuga de memoria causada por la omisión de pci_dev_put(). pci_get_device() aumentará el recuento de referencias para el pci_dev devuelto. Necesitamos usar pci_dev_put() para disminuir el recuento de referencias antes de que amd_probe() regrese. No hay problema para la rama 'smbus_dev == NULL', ya que pci_dev_put() también puede gestionar el caso del parámetro de entrada NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm ioctl: se corrige el comportamiento incorrecto si list_versions se acelera al cargar módulos. __list_versions primero estimará el espacio requerido mediante la llamada "dm_target_iterate(list_version_get_needed, &needed)" y luego llenará el espacio mediante la llamada "dm_target_iterate(list_version_get_info, &iter_info)". Cada una de estas llamadas bloquea los destinos mediante las llamadas "down_read(&_lock)" y "up_read(&_lock)". Sin embargo, entre la primera y la segunda llamada "dm_target_iterate" no se mantiene el bloqueo y los módulos de destino se pueden cargar en este punto, por lo que la segunda llamada "dm_target_iterate" podría necesitar más espacio que el devuelto por la primera llamada "dm_target_iterate". El código intenta gestionar este desbordamiento (véase el comienzo de list_version_get_info), pero esta gestión es incorrecta. El código establece "param->data_size = param->data_start + needed" y "iter_info.end = (char *)vers+len": "needed" es el tamaño devuelto por la primera llamada a dm_target_iterate; "len" es el tamaño del búfer asignado por el espacio de usuario. "len" puede ser mayor que "needed"; en este caso, el código escribirá hasta "len" bytes en el búfer; sin embargo, param->data_size se establece en "needed", por lo que podría escribir datos que superen el valor de param->data_size. La interfaz ioctl solo copia hasta param->data_size en el espacio de usuario, por lo que parte del resultado se truncará. Corrija este error estableciendo "iter_info.end = (char *)vers + needed;" Esto garantiza que la segunda llamada "dm_target_iterate" solo escriba hasta el búfer necesario y finalice con "DM_BUFFER_FULL_FLAG" si se desborda dicho espacio. En este caso, el espacio de usuario asignará un búfer mayor y reintentará. Tenga en cuenta que también hay un error en list_version_get_needed: debemos agregar "strlen(tt->name) + 1" al tamaño necesario, no "strlen(tt->name)".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Se omite snd_BUG_ON() de snd_usbmidi_output_open(). snd_usbmidi_output_open() tiene una comprobación del puerto nulo con snd_BUG_ON(). Se usó snd_BUG_ON() porque esto no debería haber ocurrido, pero en realidad, el puerto nulo puede detectarse cuando el dispositivo proporciona una configuración de endpoint no válida en el descriptor, por lo que el controlador omite la asignación. Es decir, la comprobación en sí es válida y snd_BUG_ON() debería omitirse. De lo contrario, es confuso, como si se tratara de un error real, como lo detectó syzbot recientemente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige la advertencia de optc2_configure en dcn314 [Por qué] dcn314 usa optc2_configure_crc() que envuelve optc1_configure_crc() + establece registros adicionales que no son aplicables a dcn314. No es crítico, pero cuando se usa genera advertencias como: ADVERTENCIA: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c Seguimiento de llamadas: generic_reg_set_ex+0x6d/0xe0 [amdgpu] optc2_configure_crc+0x60/0x80 [amdgpu] dc_stream_configure_crc+0x129/0x150 [amdgpu] amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu] [How] Use optc1_configure_crc() directly

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/xen: Se corrige el manejo de errores de eventfd en kvm_xen_eventfd_assign(). No se debe llamar a eventfd_ctx_put() en caso de error. [Introducir un nuevo objetivo goto en su lugar. - Paolo]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp:cdg: permite llamar a tcp_cdg_release() varias veces. Aparentemente, mptcp puede llamar a tcp_disconnect() en un flujo ya desconectado. Esto generalmente funciona bien, a menos que el control de congestión actual sea CDG, ya que podría desencadenar una doble liberación [1]. En lugar de corregir MPTCP y futuros errores, podemos hacer que tcp_disconnect() sea más resistente. [1] ERROR: KASAN: doble liberación en slab_free mm/slub.c:3539 [en línea] ERROR: KASAN: doble liberación en kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0 PID: 3645 Comm: kworker/0:7 No contaminado 6.0.0-syzkaller-02734-g0326074ff465 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/09/2022 Cola de trabajo: eventos mptcp_worker Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145 __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327 mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline] mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 Allocated by task 3671: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] ____kasan_kmalloc mm/kasan/common.c:475 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525 kmalloc_array include/linux/slab.h:640 [inline] kcalloc include/linux/slab.h:671 [inline] tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380 tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391 do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513 tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801 mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844 __sys_setsockopt+0x2d6/0x690 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260 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+0x63/0xcd Freed by task 16: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969 inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157 tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649 tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624 tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525 tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759 ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: macvlan: exige una MTU mínima consistente. macvlan debería exigir una MTU mínima de 68, incluso al crear el enlace. Este parche evita el comportamiento actual (que podría provocar fallos en la pila IPv6 si se activa el enlace). $ ip link add macvlan1 link eno1 mtu 8 type macvlan # ¡Esto debería fallar! $ ip link sh dev macvlan1 5: macvlan1@eno1: mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: MTU menor que el mínimo del dispositivo. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu menor que el mínimo del dispositivo.