Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: se corrige una fuga de memoria en query_regdb_file(). En la función query_regdb_file(), el parámetro alpha2 se duplica mediante kmemdup() y posteriormente se libera en regdb_fw_cb(). Sin embargo, request_firmware_nowait() puede fallar sin llamar a regdb_fw_cb() y, por lo tanto, provocar una fuga de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: APEI: Se corrige el desbordamiento de enteros en ghes_estatus_pool_init(). Se cambia num_ghes de int a unsigned int, lo que evita un desbordamiento y provoca el fallo de vmalloc(). El desbordamiento ocurre en ghes_estatus_pool_init() al calcular len durante la ejecución de la siguiente instrucción, ya que ambos operandos de multiplicación son int con signo: len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE); El siguiente seguimiento de llamadas se observa debido a este error: [ 9.317108] swapper/0: error de vmalloc: tamaño 18446744071562596352, excede el total de páginas, modo: 0xcc0 (GFP_KERNEL), nodemask = (null), cpuset = /, mems_allowed = 0-1 [ 9.317131] Seguimiento de llamadas: [ 9.317134] [ 9.317137] dump_stack_lvl + 0x49/0x5f [ 9.317145] dump_stack + 0x10/0x12 [ 9.317146] warn_alloc.cold + 0x7b/0xdf [ 9.317150] ? __adjunto_dispositivo+0x16a/0x1b0 [ 9.317155] __rango_nodo_vmalloc+0x702/0x740 [ 9.317160] ? agregado_dispositivo+0x17f/0x920 [ 9.317164] ? nombre_conjunto_dispositivo+0x53/0x70 [ 9.317166] ? agregado_dispositivo_plataforma+0xf9/0x240 [ 9.317168] __nodo_vmalloc+0x49/0x50 [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0 [ 9.317176] vmalloc+0x21/0x30 [ 9.317177] ghes_estatus_pool_init+0x43/0xa0 [ 9.317179] acpi_hest_init+0x129/0x19c [ 9.317185] acpi_init+0x434/0x4a4 [9.317188]? acpi_sleep_proc_init+0x2a/0x2a [9.317190] do_one_initcall+0x48/0x200 [9.317195] kernel_init_freeable+0x221/0x284 [9.317200] ? rest_init+0xe0/0xe0 [ 9.317204] kernel_init+0x1a/0x130 [ 9.317205] ret_from_fork+0x22/0x30 [ 9.317208] [ rjw: Asunto y ediciones del registro de cambios ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: meson: vdec: corrige posible pérdida de recuento de referencias en vdec_probe(). Se debe llamar a v4l2_device_unregister para colocar el recuento de referencias obtenido por v4l2_device_register cuando vdec_probe falla o se llama a vdec_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: entrada: evitar la recursión de kprobe. La función cortex_a76_erratum_1463225_debug_handler() se llama al gestionar excepciones de depuración (y excepciones síncronas de instrucciones BRK), y por lo tanto se llama cuando se ejecuta una función sondeada. Si el compilador no inserta en línea cortex_a76_erratum_1463225_debug_handler(), se puede sondear. Si se sondea cortex_a76_erratum_1463225_debug_handler(), cualquier excepción de depuración o excepción de punto de interrupción de software resultará en excepciones recursivas que conducen a un desbordamiento de pila. Esto se puede activar con la autoprueba ftrace multiple_probes y como se muestra en el ejemplo a continuación. Esta es una regresión causada por el commit 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround"), que eliminó la anotación NOKPROBE_SYMBOL() asociada a la función. Mi intención era que cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: Comprobar si hay un cpu_buffer nulo en ring_buffer_wake_waiters() En algunas máquinas, el número de CPU listadas puede ser mayor que el de CPU reales existentes. El subsistema de rastreo asigna un directorio per_cpu con acceso al búfer de anillo por CPU a través de un archivo cpuX. Pero para ahorrar espacio, el búfer de anillo solo asignará búferes para las CPU en línea, aunque la matriz de CPU será tan grande como nr_cpu_ids. Con la adición de despertar a los que esperan en el búfer de anillo al cerrar el archivo, ring_buffer_wake_waiters() ahora debe asegurarse de que el búfer esté asignado (con el irq_work asignado con él) antes de intentar despertar a los que esperan, ya que provocará una desreferencia de puntero nulo. Durante la depuración, añadí una comprobación de valores nulos para el propio búfer (lo cual es correcto), así como comprobaciones de punteros nulos contra buffer->buffers (lo cual no es correcto y generará una advertencia), además de asegurarme de que el número de CPU introducido esté dentro del nr_cpu_ids (lo cual tampoco es correcto si no lo está). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/tdx: Pánico en configuraciones incorrectas que generan #VE al acceder a memoria "privada". Toda la memoria normal del kernel es "memoria privada TDX". Esto incluye todo, desde las pilas del kernel hasta el texto del kernel. Gestionar excepciones en accesos arbitrarios a la memoria del kernel es prácticamente imposible, ya que pueden ocurrir en lugares muy peligrosos, como la entrada/salida del kernel. Sin embargo, el hardware TDX, en teoría, puede generar una excepción de virtualización (#VE) en cualquier acceso a memoria privada. Sin embargo, no es tan grave como parece. TDX se puede configurar para que nunca genere estas excepciones en memoria privada con un "atributo TD" llamado ATTR_SEPT_VE_DISABLE. El invitado no tiene forma de *configurar* este atributo, pero puede comprobarlo. Asegúrese de que ATTR_SEPT_VE_DISABLE esté configurado en el arranque inicial. Si no está configurado, utilice panic(). No hay una forma sensata de que Linux se ejecute con este atributo sin configurar, por lo que es apropiado usar panic(). Hay una pequeña ventana durante el arranque antes de la comprobación donde el kernel tiene un controlador de #VE temprano. Sin embargo, este controlador solo sirve para la E/S de puerto y también se pondrá en pánico() en cuanto detecte cualquier otro #VE, como uno generado por un acceso a memoria privada. [dhansen: Reescribir el registro de cambios y reorganizar con el nuevo tdx_parse_tdinfo(). Añadir la prueba de Kirill porque hice cambios desde que escribió esto.]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Inicializar bloqueos de gfn_to_pfn_cache en un asistente dedicado. Trasladar la inicialización del bloqueo de gfn_to_pfn_cache a otro asistente y llamar al nuevo asistente durante la creación de la máquina virtual o la vCPU. Es posible que se produzcan condiciones de competencia debido a la capacidad de kvm_gfn_to_pfn_cache_init() de reinicializar los bloqueos de la caché. Por ejemplo: una competencia entre ioctl(KVM_XEN_HVM_EVTCHN_SEND) y kvm_gfn_to_pfn_cache_init() provoca un bloqueo de gpc de shinfo dañado. (hilo 1) | (hilo 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Renombra "cache_init" y "cache_destroy" como activate+deactivate para evitar que la caché se destruya o libere. Ten en cuenta que hay más ejecuciones en el nuevo nombre kvm_gpc_activate() que se abordarán por separado. [sean: se indica que se trata de una corrección de error]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: smm: el número de GPR en la imagen SMRAM depende del formato de la imagen. En un host de 64 bits, si el invitado no tiene X86_FEATURE_LM, KVM accederá a 16 GPRS en la imagen SMRAM de 32 bits, lo que provocará un acceso a la RAM fuera de los límites. En un host de 32 bits, rsm_load_state_64/enter_smm_save_state_64 se compila, por lo que no se puede producir un desbordamiento de acceso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Rechazar intentos de consumir o actualizar gfn_to_pfn_cache inactivo. Rechazar kvm_gpc_check() y kvm_gpc_refresh() si la caché está inactiva. No verificar el indicador de activo durante la actualización es particularmente grave, ya que KVM puede terminar con una caché válida inactiva, lo que puede provocar diversos errores de use-after-free, como consumir un puntero de kernel nulo o perder una invalidación de mmu_notifier debido a que la caché no está en la lista de gfns para invalidar. Tenga en cuenta que "active" debe establecerse solo si la caché está en la lista de cachés, es decir, es accesible mediante eventos mmu_notifier. Si se produce un evento mmu_notifier relevante mientras la caché está activa, pero no está en la lista, KVM no adquirirá el bloqueo de la caché y, por lo tanto, no serializará el evento mmu_notifier con usuarios activos ni con kvm_gpc_refresh(). Una competencia entre KVM_XEN_ATTR_TYPE_SHARED_INFO y KVM_XEN_HVM_EVTCHN_SEND puede explotarse para activar el error. 1. Desactivar caché shinfo: kvm_xen_hvm_set_attr caso KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = falso gpc->khva = NULL gpc->active = falso Resultado: activo = falso, válido = falso 2. Causar actualización de caché: kvm_arch_vm_ioctl caso KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check devolver -EWOULDBLOCK porque !gpc->valid kvm_xen_set_evtchn_fast devolver -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = verdadero gpc->khva = no NULL Resultado: activo = falso, válido = verdadero 3. Competencia ioctl KVM_XEN_HVM_EVTCHN_SEND contra ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl caso KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr caso KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ La comprobación pasa porque gpc->valid sigue siendo cierto, aunque gpc->khva ya sea NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tun: Se corrigen las fugas de memoria de napi_get_frags que informa kmemleak tras ejecutar test_progs: objeto sin referencia 0xffff8881b1672dc0 (tamaño 232): comm "test_progs", pid 394388, jiffies 4354712116 (edad 841,975 s) volcado hexadecimal (primeros 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] El problema ocurre en los siguientes escenarios: tun_get_user() napi_gro_frags() napi_frags_finish() caso GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- Mientras napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() no se llama, napi->rx_list no está vacío <-- no solicita completar el trabajo de gro, causará pérdidas de memoria en <-- siguientes tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list no está vacío, lo que causó pérdidas de memoria Para corregirlo, agregue napi_complete() después de napi_gro_frags().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arreglar conversión de tipo de registro incorrecta en release_reference() Algunas funciones auxiliares asignarán memoria. Para evitar fugas de memoria, el verificador requiere que el programa eBPF libere estas memorias llamando a las funciones auxiliares correspondientes. Cuando se libera un recurso, todos los registros de puntero correspondientes al recurso deben invalidarse. El verificador usa release_references() para realizar este trabajo, aplicando __mark_reg_unknown() a cada registro relevante. Les dará a estos registros el tipo SCALAR_VALUE. Un registro que contendrá un valor de puntero en tiempo de ejecución, pero de tipo SCALAR_VALUE, puede permitir que el usuario sin privilegios obtenga un puntero del kernel almacenando este registro en un mapa. Usar __mark_reg_not_init() mientras NO allow_ptr_leaks puede mitigar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hyperv: corrige posible pérdida de memoria en mousevsc_probe() Si hid_add_device() devuelve un error, debe llamar a hid_destroy_device() para liberar hid_dev que está asignado en hid_allocate_device().