Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: kprobe: Se corrige la posible desreferencia de puntero nulo en trace_event_file en kprobe_event_gen_test_exit(). Cuando trace_get_event_file() falla, se asigna gen_kretprobe_test como código de error. Si se elimina el módulo kprobe_event_gen_test, se producirá la desreferencia de puntero nulo en kprobe_event_gen_test_exit(). Compruebe si gen_kprobe_test o gen_kretprobe_test son códigos de error o nulos antes de desreferenciarlos. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000012 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 2210 Comm: modprobe No contaminado 6.1.0-rc1-00171-g2159299a3b74-dirty #217 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test] Código: No se puede acceder a los bytes del código de operación en 0xffffffff9ffffff2. RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246 RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 000000000000000 RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c RBP: ffffffffa0000000 R08: 000000000000004 R09: 00000000001e95c0 R10: 000000000000000 R11: 000000000000001 R12: 0000000000000800 R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 000000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: kprobe: Se corrige la posible desreferencia de PTR nula en trace_array en kprobe_event_gen_test_exit(). Cuando test_gen_kprobe_cmd() falla después de kprobe_event_gen_cmd_end(), se ejecuta el comando "eliminar", lo que llama a kprobe_event_delete() y libera el recurso correspondiente. Sin embargo, trace_array en gen_kretprobe_test apuntará al recurso no válido. Establezca gen_kretprobe_test en NULL después de llamar a kprobe_event_delete() para evitar la desreferencia de PTR nula. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000070 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 246 Comm: modprobe Tainted: GW 6.1.0-rc1-00174-g9522dc5c87da-dirty #248 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0 Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000 RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064 R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000 FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __ftrace_set_clr_event+0x3e/0x60 trace_array_set_clr_event+0x35/0x50 ? 0xffffffffa0000000 kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test] __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f89eeb061b7

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc/vmw_vmci: se corrige una fuga de información en vmci_host_do_receive_datagram() `struct vmci_event_qp` asignado por qp_notify_peer() que contiene relleno, que puede llevar datos no inicializados al espacio de usuario, como lo observó KMSAN: ERROR: KMSAN: fuga de información del kernel en instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit se almacenó en la memoria en: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach controladores/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 controladores/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 controladores/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair controladores/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 controladores/misc/vmw_vmci/vmci_host.c:927 ... Variable local ev creada en: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 de 48 sin inicializar. El acceso a memoria de tamaño 48 comienza en ffff888035155e00. Datos copiados a la dirección de usuario 0000000020000100. Use memset() para evitar las filtraciones de información. También se especula que se debe corregir qp_notify_peer_local(), que podría presentar el mismo problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: zfcp: Arregla doble liberación de solicitud FSF cuando falla el envío de qdio Solíamos usar el tipo incorrecto de entero en 'zfcp_fsf_req_send()' para almacenar en caché el ID de solicitud FSF al enviar una nueva solicitud FSF. Esto se usa en caso de que el envío falle y necesitemos eliminar la solicitud de nuestra tabla hash interna nuevamente (para no mantener una referencia no válida y usarla cuando liberemos la solicitud nuevamente). En 'zfcp_fsf_req_send()' solíamos almacenar en caché el ID como 'int' (con signo y 32 bits de ancho), pero el resto del código zfcp (y la especificación del firmware) maneja el ID como 'unsigned long'/'u64' (sin signo y 64 bits de ancho [s390x ELF ABI]). Por un lado, esto presenta el problema obvio de que, cuando el ID supera los 32 bits (esto puede ocurrir con relativa rapidez), se trunca a 32 bits al almacenarlo en la variable de caché, por lo que ya no coincide con el ID original. El segundo problema, menos obvio, es que, incluso cuando el ID original aún no supera los 32 bits, en cuanto se establece el bit 32 en el ID original (0x80000000 = 2'147'483'648), se produce una discrepancia al convertirlo a 'unsigned long'. Como la variable en caché es de tipo con signo, el compilador utilizará una instrucción de extensión de signo para cargar la variable de 32 bits en un registro de 64 bits (p. ej., 'lgf %r11,188(%r15)'). Entonces, una vez que pasamos la variable en caché a 'zfcp_reqlist_find_rm()' para eliminar la solicitud de nuevo, todos los ceros iniciales se invertirán a unos para extender el signo y ya no coincidirán con el ID original (esto se ha observado en la práctica). Si no podemos eliminar correctamente la solicitud de la tabla hash de nuevo después de que 'zfcp_qdio_send()' falle (esto sucede regularmente cuando zfcp no puede notificar al adaptador sobre el nuevo trabajo porque el adaptador ya se ha ido durante, por ejemplo, una conmutación de ChpID), terminaremos con una doble liberación. Liberamos incondicionalmente la solicitud en la función de llamada cuando 'zfcp_fsf_req_send()' falla, pero debido a que la solicitud aún está en la tabla hash, terminamos con una referencia de memoria obsoleta, y una vez que el adaptador zfcp se reinicia durante la recuperación o el apagado, terminamos liberando la misma memoria dos veces. Los seguimientos de pila resultantes varían según el kernel y no tienen correlación directa con el lugar donde ocurre el error. A continuación se muestran tres ejemplos que se han visto en la práctica: corrupción de list_del. next->prev debería ser 00000001b9d13800, pero era 00000000dead4ead. (next=00000001bd131a00) ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:62! evento de monitor: 0040 ilc:2 [#1] PREEMPT Módulos SMP vinculados: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: cargado Nombre del hardware: ... Krnl PSW: 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 00000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Código Krnl: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Rastreo de llamadas: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes: Omitir la limpieza del post_handler de aggrprobe en el caso de kprobe-on-ftrace. En __unregister_kprobe_top(), si la sonda actualmente no registrada tiene post_handler, pero otras sondas secundarias de aggrprobe no lo tienen, se limpia el post_handler de aggrprobe. Si se trata de una sonda basada en ftrace, existe un problema. En llamadas posteriores a disarm_kprobe(), usaremos kprobe_ftrace_ops porque post_handler es NULL. Pero estamos preparados con kprobe_ipmodify_ops. Esto activa una ADVERTENCIA en __disarm_kprobe_ftrace() e incluso puede provocar un use-after-free: No se pudo desarmar kprobe-ftrace en kernel_clone+0x0/0x3c0 (error -2) ADVERTENCIA: CPU: 5 PID: 137 en kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Módulos vinculados en: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod No contaminado 6.1.0-rc4-dirty #18 [...] Seguimiento de llamadas: __disable_kprobe+0xcd/0xe0 __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. De esta forma, podemos desactivarla correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: tcm_loop: Se corrige una posible fuga de nombre en tcm_loop_setup_hba_bus(). Si device_register() falla en tcm_loop_setup_hba_bus(), se debe liberar el nombre asignado por dev_set_name(). Como se indica en el comentario de device_register(), se debe usar put_device() para liberar la referencia en la ruta de error. Para solucionar esto, se debe llamar a put_device(); luego, el nombre se puede liberar en kobject_cleanup(). El 'tl_hba' se liberará en tcm_loop_release_adapter(), por lo que no es necesario ir a la etiqueta de error en este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd: Se corrige el fallo debido a la competencia entre amd_pmu_enable_all, perf NMI y la limitación. amd_pmu_enable_all() realiza lo siguiente: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); Un perf NMI de otro evento puede interponerse entre estos dos pasos. El controlador de perf NMI deshabilita y habilita internamente _todos_ los eventos, incluido el que amd_pmu_enable_all() interceptado por nmi estaba habilitando. Si ese evento habilitado involuntariamente tiene un período de muestreo muy bajo y causa NMI sucesivas inmediatas, lo que provoca su limitación, x86_pmu_stop() borra cpuc->events[idx] y cpuc->active_mask. Esto provocará que amd_pmu_enable_event() se llame con event=NULL cuando amd_pmu_enable_all() se reanude tras gestionar las NMI. Esto provoca un fallo del kernel: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - not-present page [...] Rastreo de llamadas: amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb amd_pmu_disable_all()/amd_pmu_enable_all() Las llamadas dentro del controlador NMI de rendimiento se añadieron recientemente como parte de la habilitación de BRS, pero no estoy seguro de si realmente las necesitamos. Podemos deshabilitar BRS al principio y volver a habilitarlo al regresar de NMI. Esto solucionará el problema al no habilitar los eventos cuyas máscaras activas estén configuradas, pero que aún no estén habilitadas en la PMU de hardware.

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.