Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrige pérdida de memoria de proc->delivered_freeze Si se borra una notificación de congelamiento con BC_CLEAR_FREEZE_NOTIFICATION antes de llamar a binder_freeze_notification_done(), entonces se separa de su referencia (por ejemplo, ref->freeze) pero el trabajo permanece en cola en proc->delivered_freeze. Esto genera una pérdida de memoria cuando el proceso finaliza, ya que no se liberan las entradas pendientes en proc->delivered_freeze: objeto sin referencia 0xffff38e8cfa36180 (tamaño 64): comm "binder-util", pid 655, jiffies 4294936641 volcado hexadecimal (primeros 32 bytes): b8 e9 9e c8 e8 38 ff ff b8 e9 9e c8 e8 38 ff ff .....8.......8.. 0b 00 00 00 00 00 00 00 3c 1f 4b 00 00 00 00 00 ........<.K..... backtrace (crc 95983b32): [<000000000d0582cf>] kmemleak_alloc+0x34/0x40 [<000000009c99a513>] __kmalloc_cache_noprof+0x208/0x280 [<00000000313b1704>] binder_thread_write+0xdec/0x439c [<000000000cbd33bb>] binder_ioctl+0x1b68/0x22cc [<000000002bbedeeb>] __arm64_sys_ioctl+0x124/0x190 [<00000000b439adee>] invocar_syscall+0x6c/0x254 [<00000000173558fc>] Este parche corrige la fuga al garantizar que todas las entradas pendientes en proc->delivered_freeze se liberen durante binder_deferred_release().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección del UAF congelado en binder_release_work() Cuando se limpia una referencia de binder, cualquier trabajo congelado en cola en el proceso asociado también debe eliminarse. De lo contrario, la referencia se libera mientras su ref->freeze.work todavía está en cola en proc->work, lo que genera un problema de use-after-free, como lo muestra el siguiente informe de KASAN: ====================================================================== ERROR: KASAN: slab-use-after-free en binder_release_work+0x398/0x3d0 Lectura de tamaño 8 en la dirección ffff31600ee91488 por la tarea kworker/5:1/211 CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 No contaminado 6.11.0-rc7-00382-gfc6c92196396 #22 Hardware nombre: linux,dummy-virt (DT) Cola de trabajo: eventos binder_deferred_func Rastreo de llamadas: binder_release_work+0x398/0x3d0 binder_deferred_func+0xb60/0x109c process_one_work+0x51c/0xbd4 worker_thread+0x608/0xee8 Asignado por la tarea 703: __kmalloc_cache_noprof+0x130/0x280 binder_thread_write+0xdb4/0x42a0 binder_ioctl+0x18f0/0x25ac __arm64_sys_ioctl+0x124/0x190 activate_syscall+0x6c/0x254 Liberado por la tarea 211: kfree+0xc4/0x230 binder_deferred_func+0xae8/0x109c process_one_work+0x51c/0xbd4 worker_thread+0x608/0xee8 ======================================================================= Este commit corrige el problema al garantizar que cualquier trabajo de congelamiento en cola se elimine al limpiar una referencia de binder.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección de OOB en binder_add_freeze_work() En binder_add_freeze_work() iteramos sobre proc->nodes con el proc->inner_lock retenido. Sin embargo, este bloqueo se elimina temporalmente para adquirir primero el node->lock (orden de anidación de bloqueos). Esto puede competir con binder_deferred_release() que elimina los nodos del proc->nodes rbtree y los agrega a la lista binder_dead_nodes. Esto genera una iteración rota en binder_add_freeze_work() ya que rb_next() usará datos de binder_dead_nodes, lo que activa un acceso fuera de los límites: ====================================================================== ERROR: KASAN: global fuera de los límites en rb_next+0xfc/0x124 Lectura de tamaño 8 en la dirección ffffcb84285f7170 por la tarea freeze/660 CPU: 8 UID: 0 PID: 660 Comm: freeze No contaminado 6.11.0-07343-ga727812a8d45 #18 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: rb_next+0xfc/0x124 binder_add_freeze_work+0x344/0x534 binder_ioctl+0x1e70/0x25ac __arm64_sys_ioctl+0x124/0x190 La dirección con errores pertenece a la variable: binder_dead_nodes+0x10/0x40 [...] =================================================================== Esto es posible porque proc->nodes (rbtree) y binder_dead_nodes (lista) comparten entradas en binder_node a través de una unión: struct binder_node { [...] union { struct rb_node rb_node; struct hlist_node dead_node; }; Corrija la ejecución comprobando que el procedimiento sigue activo. Si no es así, simplemente salga de la iteración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: reparar el UAF del nodo en binder_add_freeze_work() En binder_add_freeze_work() iteramos sobre proc->nodes con el proc->inner_lock retenido. Sin embargo, este bloqueo se elimina temporalmente para adquirir primero el node->lock (orden de anidamiento de bloqueos). Esto puede competir con binder_node_release() y activar un use-after-free: ====================================================================== ERROR: KASAN: use-after-free de losa en _raw_spin_lock+0xe4/0x19c Escritura de tamaño 4 en la dirección ffff53c04c29dd04 por la tarea freeze/640 CPU: 5 UID: 0 PID: 640 Comm: freeze No contaminado 6.11.0-07343-ga727812a8d45 #17 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: _raw_spin_lock+0xe4/0x19c binder_add_freeze_work+0x148/0x478 binder_ioctl+0x1e70/0x25ac __arm64_sys_ioctl+0x124/0x190 Asignado por la tarea 637: __kmalloc_cache_noprof+0x12c/0x27c binder_new_node+0x50/0x700 binder_transaction+0x35ac/0x6f74 binder_thread_write+0xfb8/0x42a0 binder_ioctl+0x18f0/0x25ac __arm64_sys_ioctl+0x124/0x190 Liberado por la tarea 637: kfree+0xf0/0x330 binder_thread_read+0x1e88/0x3a68 binder_ioctl+0x16d8/0x25ac __arm64_sys_ioctl+0x124/0x190 == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: combina todas las operaciones de vaciado de TLB de la dirección virtual de sombra de KASAN en una sola operación. Al compilar la fuente del kernel 'make -j $(nproc)' con el kernel habilitado para KASAN en funcionamiento en una máquina de 256 núcleos, se muestra el siguiente bloqueo suave: watchdog: BUG: soft lockup - ¡CPU n.º 28 atascada durante 22 s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: cargado No contaminado 6.10.0-rc5 #95 Cola de trabajo: eventos drain_vmap_area_work RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0 Código: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Rastreo de llamadas: ? watchdog_timer_fn+0x2cd/0x390 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x300/0x6d0 ? sched_clock_cpu+0x69/0x4e0 ? __pfx___hrtimer_run_queues+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? ktime_get_update_offsets_now+0x7f/0x2a0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? hrtimer_interrupt+0x2ca/0x760 ? __sysvec_apic_timer_interrupt+0x8c/0x2b0 ? sysvec_apic_timer_interrupt+0x6a/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? smp_call_function_many_cond+0x1d8/0xbb0 ? __pfx_do_kernel_range_flush+0x10/0x10 en_cada_máscara_de_cond_de_cpu+0x20/0x40 flush_tlb_kernel_range+0x19b/0x250 ? srso_return_thunk+0x5/0x5f ? kasan_release_vmalloc+0xa7/0xc0 purga_vmap_node+0x357/0x820 ? __pfx_purge_vmap_node+0x10/0x10 __purge_vmap_area_lazy+0x5b8/0xa10 drenaje_vmap_area_work+0x21/0x30 proceso_uno_work+0x661/0x10b0 subproceso_trabajador+0x844/0x10e0 ? srso_return_thunk+0x5/0x5f ? __kthread_parkme+0x82/0x140 ? __pfx_worker_thread+0x10/0x10 kthread+0x2a5/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Análisis de depuración: 1. El siguiente registro de ftrace muestra que la CPU de bloqueo pasa demasiado tiempo iterando vmap_nodes y vaciando TLB al purgar estructuras vm_area. (Parte de la información está recortada). kworker: funcgraph_entry: | drain_vmap_area_work() { kworker: funcgraph_entry: | mutex_lock() { kworker: funcgraph_entry: 1.092 us | __cond_resched(); kworker: funcgraph_exit: 3.306 us | } ... ... kworker: funcgraph_entry: | flush_tlb_kernel_range() { ... ... kworker: funcgraph_exit: # 7533.649 us | } ... ... kworker: funcgraph_entry: 2.344 us | mutex_unlock(); kworker: funcgraph_exit: $ 23871554 us | } La función drain_vmap_area_work() tarda más de 23 segundos. Hay 2805 llamadas a flush_tlb_kernel_range() en el registro de ftrace. * Una se llama en __purge_vmap_area_lazy(). * Las demás se llaman mediante purge_vmap_node->kasan_release_vmalloc. purge_vmap_node() libera iterativamente las asignaciones de vmalloc de kasan y vacía la TLB para cada vmap_area. - [Cálculo aproximado] Cada flush_tlb_kernel_range() se ejecuta alrededor de 7,5 ms. -- 2804 * 7,5 ms = 21,03 segundos. -- Por eso se activa un bloqueo suave. 2. Extender el tiempo de bloqueo suave puede solucionar el problema (por ejemplo, # echo ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slab: Se corrige una comprobación de alineación demasiado estricta en create_cache() En m68k, donde la alineación mínima de unsigned long es de 2 bytes: Pánico del kernel: no se sincroniza: __kmem_cache_create_args: No se pudo crear slab 'io_kiocb'. Error -22 CPU: 0 UID: 0 PID: 1 Comm: swapper No contaminado 6.12.0-atari-03776-g7eaa1f99261a #1783 Pila de 0102fe5c: 0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b 0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044 0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007 01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4 00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004 00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88 Seguimiento de llamadas: [<00425e78>] dump_stack+0xc/0x10 [<0041eb74>] panic+0xd8/0x26c [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8 [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8 [<0041e5f0>] memset+0x0/0x8c [<005f67c0>] io_uring_init+0x54/0xd2 La alineación mínima de un tipo integral puede diferir de su tamaño, por lo tanto, no es seguro asumir que un freeptr_t arbitrario (que es básicamente un unsigned long) siempre está alineado a 4 u 8 bytes. Como nada parece requerir una alineación adicional, es seguro solucionar esto relajando la verificación a la alineación mínima real de freeptr_t.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy() pci_epc_destroy() invoca pci_bus_release_domain_nr() para liberar el ID de dominio PCI, pero hay dos problemas: - 'epc->dev' se pasa a pci_bus_release_domain_nr() que ya fue liberado por device_unregister(), lo que genera un problema de use-after-free. - El ID de dominio corresponde al dispositivo EPC principal, por lo que pasar 'epc->dev' también es incorrecto. Solucione estos problemas pasando 'epc->dev.parent' a pci_bus_release_domain_nr() y también hágalo antes de device_unregister(). [mani: asunto y descripción reformulados]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ad7923: Se corrige el desbordamiento de búfer para tx_buf y ring_xfer El AD7923 se actualizó para soportar dispositivos con 8 canales, pero el tamaño de tx_buf y ring_xfer no se incrementó en consecuencia, lo que provocó un posible desbordamiento de búfer en ad7923_update_scan_mode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: asegúrese de que exp esté activo antes de svc_export_show La función `e_show` se llamó con protección de RCU. Esto solo garantiza que `exp` no se liberará. Por lo tanto, el recuento de referencia para `exp` puede caer a cero, lo que activará una advertencia de use-after-free de refcount cuando se llame a `exp_get`. Para resolver este problema, use `cache_get_rcu` para asegurarse de que `exp` permanezca activo. ------------[ cortar aquí ]------------ refcount_t: adición en 0; use-after-free. ADVERTENCIA: CPU: 3 PID: 819 en lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat No contaminado 6.12.0-rc3+ #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 ... Seguimiento de llamadas: e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 hacer_syscall_64+0x5f/0x170 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/stacktrace: Utilizar break en lugar de la declaración return arch_stack_walk_user_common() contiene una declaración return en lugar de una declaración break en caso de que store_ip() falle al intentar almacenar una entrada de cadena de llamadas de un proceso de espacio de usuario. Esto puede provocar que falte una llamada pagefault_enable(). Si esto sucede, el controlador de fallas de página no resolverá ninguna falla de página posterior del proceso y esto, a su vez, provocará que se elimine el proceso. Utilice una declaración break en lugar de una declaración return para solucionar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc_submit: corrige la ejecución alrededor de suspend_pending Actualmente en algunos casos de prueba podemos activar: xe 0000:03:00.0: [drm] ¡La afirmación `exec_queue_destroyed(q)` falló! .... ADVERTENCIA: CPU: 18 PID: 2640 en drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Estado de motor inesperado 0x00a1, guc_id=57 Si observamos un fragmento de ftrace correspondiente a este id de GuC, podemos ver: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, código de operación=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 Parece que intentamos suspender la cola (opcode=3), configurando suspend_pending y activando un disable_scheduling. Luego, el usuario cierra la cola. Sin embargo, el cierre también señalará con fuerza la valla de suspensión después de matar la cola, más tarde, cuando la respuesta G2H para deshabilitar_programación regrese, ahora hemos borrado suspend_pending al señalar la valla de suspensión, por lo que deshabilitar_programación ahora intenta incorrectamente también anular el registro de la cola. Esto genera advertencias ya que la cola aún no se ha marcado para su destrucción. También parece que desencadenamos errores más tarde al intentar anular el registro dos veces de la misma cola. Para solucionar esto, modifique el orden al gestionar la respuesta para garantizar que no compitamos con un deshabilitar_programación que en realidad no tenía la intención de realizar una anulación del registro. La ruta de destrucción ahora también debería esperar correctamente cualquier pendiente_deshabilitar antes de marcar como destruida. (seleccionado de el commit f161809b362f027b6d72bd998e47f8f0bad60a2e)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrección de slab de use-after-free [ +0.000021] ERROR: KASAN: slab-use-after-free en drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Lectura de tamaño 8 en la dirección ffff8881b8605f88 por la tarea amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug No contaminado 6.10.0+ #1 [ +0.000016] Nombre del hardware: Nombre del producto del sistema ASUS/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Rastreo de llamadas: [ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Código: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007ffffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007ffffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffffffffe5c8 [ +0.000013] R13: 0000555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] [ +0.000016] Asignado por la tarea 383 en la CPU 7 en 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_p ---truncado---