Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: asignar EBADMSG a nfserr_io para evitar advertencias Ext4 arrojará -EBADMSG a través de ext4_readdir cuando se produzca un error de suma de comprobación, lo que dará como resultado la siguiente ADVERTENCIA. Solucione el problema asignando EBADMSG a nfserr_io. nfsd_buffered_readdir iterar_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify advertir_sin_espacio_para_csum __ advertir_sin_espacio_para_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // ADVERTENCIA [ 161.115610] ------------[ cortar aquí ]------------ [ 161.116465] nfsd: no estándar errno: -74 [ 161.117315] ADVERTENCIA: CPU: 1 PID: 780 en fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Módulos vinculados en: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd No contaminado 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Código: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 fffff52000 1c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 00000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ [161.142076] Rastreo de llamadas: [161.142575] ? __warn+0x9b/0x140 [161.143229] ? nfserrno+0x9d/0xd0 [161.143872] ? report_bug+0x125/0x150 [161.144595] ? handle_bug+0x41/0x90 [161.145284] ? exc_invalid_op+0x14/0x70 [161.146009] ? asm_exc_invalid_op+0x12/0x20 [161.146816] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? esperar_escrituras_concurrentes+0x170/0x170 [ 161.151004] ? tamaño_de_archivo_genérico_llseek+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? escritura_bytes_en_xdr_buf+0x97/0xe0 [ 161.157598] ? __escritura_bytes_en_xdr_buf+0xd0/0xd0 [ 161.158494] ? bloqueo_downgrade+0x90/0x90 [ 161.159232] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige una posible desreferencia de puntero nulo en ocfs2_set_buffer_uptodate. Al realizar una limpieza, si hay indicadores sin OCFS2_BH_READAHEAD, puede provocar una desreferencia de puntero NULL en el siguiente ocfs2_set_buffer_uptodate() si bh es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: recurso: corregir region_intersects() frente a add_memory_driver_managed() En un sistema con memoria CXL, el árbol de recursos (/proc/iomem) relacionado con la memoria CXL puede parecerse a lo siguiente. 490000000-50fffffff: CXL Window 0 490000000-50fffffff: region0 490000000-50fffffff: dax0.0 490000000-50fffffff: RAM del sistema (kmem) Debido a que drivers/dax/kmem.c llama a add_memory_driver_managed() durante la conexión en línea de la memoria CXL, lo que hace que "System RAM (kmem)" sea un descendiente de "CXL Window X". Esto confunde a region_intersects(), que espera que todos los recursos de "RAM del sistema" estén en el nivel superior de iomem_resource. Esto puede provocar errores. Por ejemplo, cuando se ejecuta la siguiente línea de comando para escribir algo de memoria en el rango de memoria CXL a través de /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copies, 0.0283507 s, 0.0 kB/s el comando falla como se esperaba. Sin embargo, el código de error es incorrecto. Debería ser "Operación no permitida" en lugar de "Dirección incorrecta". Más grave aún, la comprobación de permisos de /dev/mem en devmem_is_allowed() pasa incorrectamente. Aunque el acceso se impide más tarde porque ioremap() no tiene permiso para mapear la RAM del sistema, es un problema de seguridad potencial. Durante la ejecución del comando, se informa la siguiente advertencia en el registro del núcleo por llamar a ioremap() en la RAM del sistema. ioremap en RAM en 0x0000000490000000 - 0x0000000490000fff ADVERTENCIA: CPU: 2 PID: 416 en arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Rastreo de llamadas: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 Los detalles del proceso de ejecución del comando son los siguientes. En el árbol de recursos anterior, "System RAM" es un descendiente de "CXL Window 0" en lugar de un recurso de nivel superior. Por lo tanto, region_intersects() no informará de forma incorrecta ningún recurso de System RAM en la región de memoria CXL, porque solo comprueba los recursos de nivel superior. En consecuencia, devmem_is_allowed() devolverá 1 (permitirá el acceso a través de /dev/mem) para la región de memoria CXL de forma incorrecta. Afortunadamente, ioremap() no permite mapear System RAM y rechazar el acceso. Por lo tanto, es necesario corregir region_intersects() para que funcione correctamente con el árbol de recursos con "System RAM" no en el nivel superior como se indica anteriormente. Para corregirlo, si encontramos un recurso no coincidente en el nivel superior, continuaremos buscando recursos coincidentes en sus recursos descendientes. Por lo tanto, ya no nos perderemos ningún recurso coincidente en el árbol de recursos. En la nueva implementación, un árbol de recursos de ejemplo |------------- "CXL Window 0" ------------| |-- "System RAM" --| se comportará de manera similar al siguiente árbol de recursos falso para region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "RAM del sistema" --||-- "Ventana CXL 0a" --| Donde "Ventana CXL 0a" es parte de la "Ventana CXL 0" original que no está cubierta por la "RAM del sistema".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: send: corrige la detección de desbordamiento de búfer al copiar la ruta a la entrada de caché A partir de el commit c0247d289e73 ("btrfs: send: annotate struct name_cache_entry with __counted_by()"), anotamos la matriz de longitud variable "name" de la estructura name_cache_entry con __counted_by() para mejorar la detección de desbordamiento. Sin embargo, eso solo no era correcto, porque la longitud de esa matriz no coincide con el campo "name_len" - coincide con eso más 1 para incluir el terminador de cadena NUL, por lo que hace que un kernel fortificado piense que hay un desbordamiento e informe un splat como este: strcpy: desbordamiento de búfer detectado: escritura de 20 bytes de tamaño de búfer 19 ADVERTENCIA: CPU: 3 PID: 3310 en __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs No contaminado 6.11.0-prnet #1 Nombre del hardware: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 15/03/2018 RIP: 0010:__fortify_report+0x45/0x50 Código: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 000000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Seguimiento de llamadas: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent_+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Código: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 000000000000003 R14: 000055c499fab2e0 R15: 000000000000004 Solucione esto al no almacenar el terminador de cadena NUL ya que en realidad no lo necesitamos para las entradas de caché de nombres, de esta manera "name_len" corresponde al tamaño real de la matriz "name". Esto requiere marcar el campo de matriz "nombre" con __nonstring y usar memcpy() en lugar de strcpy() como lo recomiendan las pautas en: https://github.com/KSPP/linux/issues/90

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: corregir pánico en ejecución de asignación de memfd_pin_folios Si memfd_pin_folios intenta crear una página hugetlb, pero alguien más ya lo hizo, entonces folio obtiene el valor -EEXIST aquí: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; luego en el siguiente viaje a través del bucle "while start_idx" entramos en pánico aquí: if (folio) { folio_put(folio); Para corregirlo, configure folio en NULL en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/filemap: corrección de la serie de parches de pánico de THP filemap_get_folios_contig "memfd-pin huge page fixes". Corrige varios errores que ocurren al usar memfd_pin_folios con páginas hugetlb y THP. Los errores de hugetlb solo afectan cuando la página aún no tiene errores cuando se llama a memfd_pin_folios. El error de THP afecta cuando el desplazamiento inicial pasado a memfd_pin_folios no está alineado con la página enorme. Consulte los mensajes de confirmación para obtener más detalles. Este parche (de 5): memfd_pin_folios en la memoria respaldada por THP entra en pánico si el desplazamiento de inicio solicitado no está alineado con una página enorme: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 El error ocurre aquí porque xas_load devuelve un folio con el valor 2: filemap_get_folios_contig() para (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM "2" es una entrada hermana de xarray. Lo obtenemos porque memfd_pin_folios no redondea los índices pasados a filemap_get_folios_contig a los límites de páginas enormes para THP, por lo que cargamos desde el medio de un rango de páginas enormes para ver un hermano. (Sí redondea para hugetlbfs, en la prueba is_file_hugepages). Para solucionarlo, si el folio es un hermano, entonces devuelva el siguiente índice como punto de inicio para la siguiente llamada a filemap_get_folios_contig.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: master: svc: Se corrige la vulnerabilidad de use after free en el controlador svc_i3c_master debido a la condición de ejecución En la función svc_i3c_master_probe, &master->hj_work está vinculado con svc_i3c_master_hj_work, &master->ibi_work está vinculado con svc_i3c_master_ibi_work. Y svc_i3c_master_ibi_work puede iniciar hj_work, svc_i3c_master_irq_handler puede iniciar ibi_work. Si eliminamos el módulo que llamará a svc_i3c_master_remove para realizar la limpieza, liberará master->base a través de i3c_master_unregister mientras que el trabajo mencionado anteriormente se utilizará. La secuencia de operaciones que pueden provocar un error de UAF es la siguiente: CPU0 CPU1 | Solucione el problema asegurándose de que el trabajo se cancele antes de continuar con la limpieza en svc_i3c_master_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: se corrige la pérdida de dentry en cachefiles_open_file(). Una pérdida de dentry puede producirse cuando una cookie de búsqueda y un cull son concurrentes: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // obtener dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Devuelve un error pero no coloca dentry Después de eso, se activará la siguiente ADVERTENCIA cuando se desmonte la carpeta del backend: ===================================================================== ERROR: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} todavía en uso (1) [desmontaje de ext4 sda] ADVERTENCIA: CPU: 4 PID: 359261 en fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount No contaminado 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Rastreo de llamadas: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ==================================================================== Independientemente de si cachefiles_open_file() devuelve verdadero o falso, el recuento de referencias obtenido por lookup_positive_unlocked() en cachefiles_look_up_object() debe liberarse. Por lo tanto, libere ese recuento de referencias en cachefiles_look_up_object() para solucionar el problema anterior y simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: adp5589-keys - corrección de la desreferencia de puntero NULL Registramos una acción devm para llamar a adp5589_clear_config() y luego pasamos el cliente i2c como argumento para que podamos llamar a i2c_get_clientdata() para obtener nuestro objeto de dispositivo. Sin embargo, i2c_set_clientdata() solo se establece al final de la función de sondeo, lo que significa que obtendremos una desreferencia de puntero NULL en caso de que la función de sondeo falle antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Corrige una ejecución entre la configuración del socket y la creación del hilo de E/S En rxrpc_open_socket(), configura el socket y luego configura el hilo de E/S que lo manejará. Sin embargo, esto es un problema, ya que hay una brecha entre las dos fases en las que un paquete puede llegar a rxrpc_encap_rcv() desde el paquete UDP, pero fallo al intentar despertar el hilo de E/S aún no creado. Como solución rápida, simplemente haga que rxrpc_encap_rcv() descarte el paquete si aún no hay un hilo de E/S. Una solución mejor, pero más intrusiva, tal vez sería reorganizar las cosas de modo que la creación del socket la realice el hilo de E/S.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vm: mover xa_alloc para evitar UAF Un usuario malintencionado puede adivinar el siguiente id de la máquina virtual antes de que se complete el ioctl y luego llamar a vm destroy ioctl para activar el UAF, ya que create ioctl sigue haciendo referencia a la misma máquina virtual. Mueva xa_alloc hasta el final para evitar esto. v2: - Rebase (seleccionado de el commit dcfd3971327f3ee92765154baebbaece833d3ca9)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: esperar a los trabajadores de reparación antes de detener el kthread del limpiador durante el desmontaje Durante el desmontaje, en close_ctree(), tenemos los siguientes pasos en este orden: 1) Aparcar el kthread del limpiador - esto no destruye el kthread, básicamente detiene su ejecución (las reactivaciones contra él funcionan pero no hacen nada); 2) Detenemos el kthread del limpiador - esto da como resultado la liberación de la estructura respectiva task_struct; 3) Llamamos a btrfs_stop_all_workers() que espera a que se ejecuten trabajos en todas las colas de trabajo y luego libera las colas de trabajo. Syzbot informó de un caso en el que un trabajador de reparación provocó un bloqueo al realizar una entrada retrasada en su inodo mientras intentaba despertar al limpiador en btrfs_add_delayed_iput(), porque la estructura task_struct del kthread del limpiador ya estaba liberada. Esto puede suceder durante el desmontaje porque no esperamos a que haya ningún trabajador de reparación que aún esté en ejecución antes de llamar a kthread_stop() contra el kthread de limpieza, que se detiene y libera todos sus recursos. Solucione esto esperando a que haya algún trabajador de reparación en close_ctree() antes de llamar a kthread_stop() contra el kthread de limpieza y ejecutarlo en espera de entradas retrasadas. Los seguimientos de pila informados por syzbot fueron los siguientes: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Lectura de tamaño 8 en la dirección ffff8880272a8a18 por la tarea kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 No contaminado 6.12.0-rc1-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: btrfs-fixup btrfs_work_helper Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 imprimir_dirección_descripción mm/kasan/report.c:377 [en línea] imprimir_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave incluir/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 constructor de guardado de irq de clase_sin procesar spinlock include/linux/spinlock.h:551 [en línea] intento_de_activación+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 proceso_un_trabajo kernel/workqueue.c:3229 [en línea] proceso_trabajos_programados+0xa63/0x1850 kernel/workqueue.c:3310 subproceso_trabajador+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Asignado por la tarea 2: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [en línea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [en línea] slab_post_alloc_hook mm/slub.c:4086 [en línea] slab_alloc_node mm/slub.c:4135 [en línea] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [en línea] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [en línea] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Liberado por la tarea 61: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/k---truncado---