Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/active: Arregla el mal uso de barreras no inactivas como rastreadores de vallas Los usuarios informaron errores en las corrupciones de listas al usar i915 perf con varias aplicaciones gráficas que se ejecutan simultáneamente. El análisis de la causa raíz apuntó a un problema en el código de procesamiento de barreras: una ejecución entre la apertura/cierre de perf que reemplaza las barreras activas con solicitudes de perf en el contexto del kernel y las operaciones de preasignación/adquisición de barreras simultáneas realizadas durante el primer pin/último desanclaje del contexto del usuario. Al agregar una solicitud a un rastreador compuesto, intentamos reutilizar un rastreador de vallas existente, ya asignado y registrado con ese compuesto. El rastreador que obtenemos puede que ya rastree otra valla, puede ser una barrera inactiva o una barrera activa. Si el rastreador que obtenemos ocurre con una barrera no inactiva, entonces intentamos eliminar esa barrera de una lista de tareas de barrera a la que pertenece. Sin embargo, mientras hacemos eso no respetamos el valor de retorno de una función que realiza la eliminación de la barrera. Si la eliminación falla, terminaríamos reutilizando el rastreador aún registrado como tarea de barrera. Dado que el mismo campo de estructura se reutiliza tanto con las listas de devolución de llamadas de valla como con la lista de tareas de barrera, es probable que se produzcan daños en la lista. Ahora, las barreras se eliminan de una lista de tareas de barrera eliminando temporalmente su contenido, recorriéndolo con la omisión del nodo que se va a eliminar y, a continuación, rellenando la lista con el contenido modificado. Si estos intentos de eliminación concurrentes, intencionalmente agresivos, no se serializan, uno o más de ellos podrían fallar debido a que la lista está temporalmente vacía. El código relacionado que ignora los resultados de la eliminación de barrera se introdujo inicialmente en la versión 5.4 mediante el commit d8af05ff38ae ("drm/i915: Permitir compartir la barrera inactiva con otras solicitudes del kernel"). Sin embargo, todos los usuarios de la rutina de eliminación de barrera aparentemente estaban serializados en ese momento, por lo que el problema no se manifestó. Los resultados de git bisect con la ayuda de una prueba IGT igt@gem_barrier_race@remote-request recientemente desarrollada indican que podrían aparecer corrupciones en la lista después deel commit 311770173fac ("drm/i915/gt: Retirada de solicitud de programación cuando la línea de tiempo está inactiva"), introducida en la v5.5. Respetar los resultados de los intentos de eliminación de barreras: marcar la barrera como inactiva solo si se elimina correctamente de la lista. Luego, antes de configurar nuestra barrera como la que se rastrea actualmente, asegurarse de que el rastreador que tenemos no sea una barrera no inactiva. Si la comprobación falla, no usar ese rastreador, sino volver atrás e intentar obtener uno nuevo y utilizable. v3: usar Unlikely() para documentar el resultado esperado (Andi). Corregir errores gramaticales en la descripción de la confirmación. v2: sin cambios de código, - culpar a el commit 311770173fac ("drm/i915/gt: Programar el retiro de solicitudes cuando la línea de tiempo está inactiva"), v5.5, no confirmar d8af05ff38ae ("drm/i915: Permitir compartir la barrera de inactividad con otras solicitudes del kernel"), v5.4, - reformular la descripción deel commit. (Seleccionado de la confirmación 506006055769b10d1b2b4e22f636f3b45e0e9fc7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrección de UaF en el apagado del oyente Como informó Christoph después de haber refactorizado la inicialización del socket pasivo, la ruta de apagado del oyente mptcp es propensa a un problema de UaF. ERROR: KASAN: use-after-free en _raw_spin_lock_bh+0x73/0xe0 Escritura de tamaño 4 en la dirección ffff88810cb23098 por la tarea syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 No contaminado 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 kasan_check_range+0x14a/0x1a0 _raw_spin_lock_bh+0x73/0xe0 subflow_error_report+0x6d/0x110 sk_error_report+0x3b/0x190 tcp_disconnect+0x138c/0x1aa0 inet_child_forget+0x6f/0x2e0 inet_csk_listen_stop+0x209/0x1060 __mptcp_close_ssk+0x52d/0x610 mptcp_destroy_common+0x165/0x640 mptcp_destroy+0x13/0x80 __mptcp_destroy_sock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc puede expirar legítimamente entre el último recuento de referencias introducido en mptcp_subflow_queue_clean() y el acceso eventual posterior en inet_csk_listen_stop(). Tras la actualización anterior, ya no necesitamos la limpieza de sockets del receptor MSK con casos especiales: el trabajador de mptcp procesará cada uno de los sockets MSK no aceptados. Simplemente elimine el código innecesario. Tenga en cuenta que esta confirmación depende de las dos principales: mptcp: refactorizar la inicialización pasiva de sockets. mptcp: usar la cola de trabajo para eliminar los sockets no aceptados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de tarea bloqueada en ext4_xattr_delete_inode. Syzbot informó de un problema de tarea bloqueada: =================================================================== INFORMACIÓN: La tarea syz-executor232:5073 se bloqueó durante más de 143 segundos. No contaminada. 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-exec232 estado:D pila:21024 pid:5073 ppid:5072 indicadores:0x00004004 Rastreo de llamadas: context_switch kernel/sched/core.c:5244 [en línea] __schedule+0x995/0xe20 kernel/sched/core.c:6555 schedule+0xcb/0x190 kernel/sched/core.c:6631 __wait_on_freeing_inode fs/inode.c:2196 [en línea] find_inode_fast+0x35a/0x4c0 fs/inode.c:950 iget_locked+0xb1/0x830 fs/inode.c:1273 __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861 ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389 ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148 ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880 ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296 evict+0x2a4/0x620 fs/inode.c:664 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [en línea] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [en línea] __do_sys_mount fs/namespace.c:3697 [en línea] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa5406fd5ea RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970 RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432 R10: 0000000000804a03 R11: 0000000000000202 R12: 000000000000004 R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 000000000000000 == ... Para resolver este problema, solo necesitamos verificar si el ino del inodo EA y el padre es el mismo antes de obtener el inodo EA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Se corrige un acceso ilegal a memoria En la función kfd_wait_on_events(), la estructura kfd_event_waiter es asignada por alloc_event_waiters(), pero el campo de evento de la estructura waiter no se inicializa; Cuando copy_from_user() falla en la función kfd_wait_on_events(), ingresará al control de excepciones para liberar la memoria previamente asignada de la estructura waiter; Debido a que se accede al campo de evento de la estructura waiters en la función free_waiters(), esto da como resultado un acceso ilegal a la memoria y un bloqueo del sistema. Aquí está el registro de bloqueo: kernel localhost: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 kernel localhost: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 kernel localhost: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 kernel localhost: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 kernel localhost: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 núcleo del host local: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 núcleo del host local: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 núcleo del host local: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 núcleo localhost: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 núcleo localhost: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 núcleo localhost: Seguimiento de llamadas: núcleo localhost: _raw_spin_lock_irqsave+0x30/0x40 núcleo localhost: remove_wait_queue+0x12/0x50 núcleo localhost: kfd_wait_on_events+0x1b6/0x490 [hydcu] núcleo localhost: ? ftrace_graph_caller+0xa0/0xa0 núcleo local del host: kfd_ioctl+0x38c/0x4a0 [hydcu] núcleo local del host: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] núcleo local del host: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] núcleo local del host: ? ftrace_graph_caller+0xa0/0xa0 núcleo local del host: __x64_sys_ioctl+0x8e/0xd0 núcleo local del host: ? syscall_trace_enter.isra.18+0x143/0x1b0 kernel localhost: do_syscall_64+0x33/0x80 kernel localhost: entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel localhost: RIP: 0033:0x152a4dff68d7 Asigne la estructura con kcalloc y elimine la inicialización 0 redundante y una verificación de condición de bucle redundante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Ajuste insuficiente del valor predeterminado bpf_jit_limit Hemos visto informes recientes de usuarios de AWS EKS (Kubernetes) como el siguiente: Después de actualizar los nodos EKS de v20230203 a v20230217 en nuestros clústeres EKS 1.24 después de unos días, varios de los nodos tienen contenedores atascados en el estado ContainerCreating o las sondas de actividad/preparación informan el siguiente error: Sonda de preparación con error: error de rpc: código = desconocido desc = no se pudo ejecutar en el contenedor: no se pudo iniciar el ejecutable "4a11039f730203ffc003b7[...]": OCI runtime exec failed: exec failed: cannot start container process: cannot init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524: unknown Sin embargo, no habíamos visto este problema en las AMI anteriores y El problema solo comenzó a ocurrir en la versión v20230217 (tras la actualización del kernel 5.4 a la 5.10), sin otros cambios en el clúster subyacente ni en las cargas de trabajo. Probamos las sugerencias de ese problema (sysctl net.core.bpf_jit_limit=452534528), lo que permitió crear contenedores y ejecutar sondas de inmediato. Sin embargo, después de aproximadamente un día, el problema reapareció y el valor devuelto por cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}' aumentó de forma constante. Probé el árbol BPF para observar los tamaños de bpf_jit_charge_modmem y bpf_jit_uncharge_modmem, así como bpf_jit_current bajo el filtro BPF tcpdump, BPF seccomp y programas nativos (e)BPF. El comportamiento parece sensato y esperado, sin ninguna fuga de datos desde la perspectiva del servidor. El control bpf_jit_limit se añadió originalmente para evitar que las aplicaciones sin privilegios que cargaban programas BPF (por ejemplo, políticas BPF seccomp) consumieran toda la memoria del módulo mediante BPF JIT, impidiendo así la carga de módulos del kernel. El límite predeterminado se definió en 2018 y, si bien era adecuado en aquel entonces, hoy en día vemos muchos más consumidores de BPF. Ajuste el límite del pool BPF JIT de 1/4 a la mitad del espacio de memoria del módulo para reflejar mejor las necesidades actuales y evitar que más usuarios se enfrenten a problemas potencialmente difíciles de depurar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PPTT: Corrección para evitar la suspensión en el contexto atómico cuando PPTT está ausente. el commit 0c80f9e165f8 ("ACPI: PPTT: Dejar la tabla asignada para el uso en tiempo de ejecución") habilitó la asignación de PPTT una vez en la primera invocación de acpi_get_pptt() y nunca la desasignó, lo que permite su uso en tiempo de ejecución sin la molestia de asignar y desasignar la tabla. Esto era necesario para obtener información de LLC del PPTT en la ruta cpuhotplug, que se ejecuta en el contexto atómico, ya que acpi_get_table() podría estar en suspensión esperando un mutex. Sin embargo, no logró gestionar el caso en que no hay PPTT en el sistema, lo que provoca que acpi_get_pptt() se llame desde todas las CPU secundarias que intentan obtener la información de LLC en el contexto atómico sin conocer la ausencia de PPTT, lo que resulta en un error como el siguiente: | ERROR: función inactiva llamada desde contexto no válido en kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | Profundidad de anidamiento de RCU: 0, expected: 0 | swapper/1/0 no tiene bloqueos. | marca de evento irq: 0 | hardirqs habilitado por última vez en (0): 0x0 | hardirqs deshabilitado por última vez en (0): copy_process+0x61c/0x1b40 | softirqs habilitado por última vez en (0): copy_process+0x61c/0x1b40 | softirqs deshabilitado por última vez en (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.3.0-rc1 #1 | Rastreo de llamadas: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0 Actualice acpi_get_pptt() para considerar el hecho de que PPTT se verifica una vez y no está disponible en el sistema y devuelve NULL evitando cualquier intento de obtener PPTT y, por lo tanto, evitando cualquier posible suspensión esperando un mutex en el contexto atómico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: no ejecutar mt76_unregister_device() en hardware no registrado. Al intentar sondear una tarjeta PCI mt7921e sin firmware, se obtiene un sondeo exitoso donde no se ha llamado a ieee80211_register_hw. Al desinstalar el controlador, se llama a ieee802111_unregister_hw incondicionalmente, lo que provoca una desreferencia de puntero nulo en el kernel. Se solucionó el problema al ejecutar la rutina mt76_unregister_device solo para hardware registrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: usa workqueue para destruir sockets no aceptados Christoph informó un UaF en el momento de la búsqueda del token después de haber refactorizado la parte de inicialización del socket pasivo: ERROR: KASAN: use-after-free en __token_bucket_busy+0x253/0x260 Lectura de tamaño 4 en la dirección ffff88810698d5b0 por la tarea syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 No contaminado 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Necesitamos limpiar correctamente todos los recursos emparejados de nivel MPTCP y asegurarnos de liberar el msk al final, incluso cuando el subflujo no aceptado es destruido por los procesos internos de TCP mediante inet_child_forget(). Podemos reutilizar la infra MPTCP_WORK_CLOSE_SUBFLOW existente, comprobando explícitamente que para el escenario crítico: el subflujo cerrado es el de MPC, el msk no es aceptado y finalmente se realiza una limpieza completa. Con este cambio, __mptcp_destroy_sock() siempre se llama en los sockets msk, incluso en los aceptados. Ya no es necesario eliminar temporalmente una referencia sk al clonar msk. Tenga en cuenta que esta confirmación depende de la principal: mptcp: refactorizar la inicialización pasiva del socket.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd/core: Siempre borrar el estado de idx. La variable 'status' (que contiene los bits de desbordamiento no controlados) no se enmascara correctamente en algunos casos, mostrando la siguiente advertencia: ADVERTENCIA: CPU: 156 PID: 475601 en arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270. Esto parece estar sucediendo porque el bucle continúa antes de que se desactive el bit de estado, en caso de que x86_perf_event_set_period() devuelva 0. Esto también causa una inconsistencia porque el contador "controlado" se incrementa, pero el bit de estado no se limpia. Mueva la limpieza de bits junto arriba, junto cuando se incrementa el contador "controlado".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: se corrige la advertencia de seguimiento de llamadas ttm_bo en psp_hw_fini. El seguimiento de llamadas se produce al eliminar amdgpu tras el reinicio en modo 1. Durante el reinicio en modo 1, desde la suspensión hasta la reanudación, no es necesario reinicializar el búfer de firmware ta, lo que provocaba un aumento redundante en el recuento de pines de bo. [ 489.885525] Seguimiento de llamadas: [ 489.885525] [ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm] [ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu] [ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu] [ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu] [ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu] [ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0 [ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu] [ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu] [ 489.886132] ? __pm_runtime_resume+0x60/0x90 [ 489.886134] pci_device_remove+0x3e/0xb0 [ 489.886135] __device_release_driver+0x1ab/0x2a0 [ 489.886137] driver_detach+0xf3/0x140 [ 489.886138] bus_remove_driver+0x6c/0xf0 [ 489.886140] driver_unregister+0x31/0x60 [ 489.886141] pci_unregister_driver+0x40/0x90 [ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Se corrige el acceso a direcciones no válidas en lookup_rec() cuando el índice es 0 KASAN informó el siguiente problema: BUG: KASAN: use-after-free en lookup_rec Lectura de tamaño 8 en la dirección ffff000199270ff0 por la tarea modprobe CPU: 2 Comm: modprobe Rastreo de llamadas: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe Al verificar pg->records[pg->index - 1].ip en lookup_rec(), puede obtener un pg que se agregó recientemente a ftrace_pages_start en ftrace_process_locs(). Antes del primer pg->index++, el índice es 0 y acceder a pg->records[-1].ip causará este problema. No verifique la IP cuando pg->index sea 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corregir desplazamiento fuera de los límites en CalculateVMAndRowBytes [POR QUÉ] Cuando PTEBufferSizeInRequests es cero, UBSAN informa la siguiente advertencia porque dml_log2 devuelve un valor negativo inesperado: el exponente de desplazamiento 4294966273 es demasiado grande para el tipo de 32 bits 'int' [CÓMO] En el caso de que PTEBufferSizeInRequests sea cero, omita dml_log2() y asigne el resultado directamente.