Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: acpi: nfit: vmalloc-out-of-bounds Lectura en acpi_nfit_ctl Se soluciona un problema detectado por syzbot con KASAN: ERROR: KASAN: vmalloc-out-of-bounds en cmd_to_func drivers/acpi/nfit/ core.c:416 [en línea] ERROR: KASAN: vmalloc-out-of-bounds en acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 El problema ocurre en cmd_to_func cuando se accede a la matriz call_pkg->nd_reserved2 sin verificar que call_pkg apunte a un búfer que tenga el tamaño adecuado como una estructura nd_cmd_pkg. Esto puede provocar un acceso fuera de los límites y un comportamiento indefinido si el búfer no tiene suficiente espacio. Para solucionar este problema, se agregó una verificación en acpi_nfit_ctl() para garantizar que buf no sea NULL y que buf_len sea menor que sizeof(*call_pkg) antes de acceder a él. Esto garantiza un acceso seguro a los miembros de call_pkg, incluida la matriz nd_reserved2.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: corrección del error NL80211_ATTR_MLO_LINK_ID en uno Dado que la validación del rango del atributo netlink proporciona una verificación inclusiva, el *máximo* del atributo NL80211_ATTR_MLO_LINK_ID debe ser IEEE80211_MLD_MAX_NUM_LINKS - 1, lo que de lo contrario provocaría un error de uno. Una pila de fallos para demostración: ==================================================================== ERROR: KASAN: acceso a memoria salvaje en ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 Lectura de tamaño 6 en la dirección 001102080000000c por la tarea fuzzer.386/9508 CPU: 1 PID: 9508 Comm: syz.1.386 No contaminado 6.1.70 #2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_report+0xe0/0x750 mm/kasan/report.c:398 kasan_report+0x139/0x170 mm/kasan/report.c:495 kasan_check_range+0x287/0x290 mm/kasan/generic.c:189 memcpy+0x25/0x60 mm/kasan/shadow.c:65 ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 rdev_tx_control_port net/wireless/rdev-ops.h:761 [en línea] nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453 genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756 genl_family_rcv_msg net/netlink/genetlink.c:833 [en línea] genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [en línea] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [en línea] __sock_sendmsg net/socket.c:728 [en línea] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [en línea] __do_sys_sendmsg net/socket.c:2591 [en línea] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd Actualice la política para garantizar una validación correcta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la competencia entre el reemplazo de elementos y close(). El reemplazo de elementos (con un socket diferente del almacenado) puede competir con el enlace de close() del socket, haciendo estallar y desvinculando el enlace. __sock_map_delete() anula la referencia incondicional del elemento (incorrecto): // establece map[0] = s0 map_update_elem(map, 0, s0) // elimina fd de s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // reemplaza map[0] con s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) si (conteo_de_referencias_y_pruebas(&psock)) sk_psock_drop(sk, psock) desbloqueo_spin(&stab->bloqueo) desbloqueo_sock(sk) __sock_map_delete bloqueo_spin(&stab->bloqueo) sk = *psk // s1 reemplazó a s0; sk == s1 si (!sk_prueba || sk_prueba == sk) // sk_prueba (s0) != sk (s1); sin rama sk = xchg(psk, NULL) si (sk) sock_map_unref(sk, psk) // desreferenciar s1; sks[idx] dejará colgado psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Luego close(map) pone en cola bpf_map_free_deferred, que finalmente llama a sock_map_free(). Esto da como resultado algunas advertencias refcount_t junto con un splat KASAN [1]. Corrija __sock_map_delete(), no permita sock_map_unref() en elementos que pueden haber sido reemplazados. [1]: ERROR: KASAN: slab-use-after-free en sock_map_free+0x10e/0x330 Escritura de tamaño 4 en la dirección ffff88811f5b9100 por la tarea kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 No contaminado 6.12.0+ #125 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Cola de trabajo: events_unbound bpf_map_free_deferred Rastreo de llamadas: dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 Asignado por la tarea 1202: pila de guardado kasan+0x1e/0x40 seguimiento de guardado kasan+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 La librería ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf,perf: Se corrige el acceso no válido a prog_array en perf_event_detach_bpf_prog Syzbot informó [1] un fallo que ocurre en el siguiente escenario de seguimiento: - crear un evento perf de tracepoint con attr.inherit=1, adjuntarlo al proceso y establecerle el programa bpf - el proceso adjunto se bifurca -> chid crea un evento heredado el nuevo evento secundario comparte el programa bpf del padre y tp_event (de ahí prog_array) que es global para tracepoint - salir tanto del proceso como de su hijo -> liberar ambos eventos - la primera llamada perf_event_detach_bpf_prog liberará tp_event->prog_array y la segunda perf_event_detach_bpf_prog se bloqueará, porque tp_event->prog_array es NULL La corrección asegura que las comprobaciones perf_event_detach_bpf_prog prog_array es válido antes de intentar eliminar el programa bpf de él. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_serial: soluciona el problema por el cual gs_start_io se bloqueaba debido al acceso a un puntero nulo. Teniendo en cuenta que en algunos casos extremos, cuando varios subprocesos acceden al controlador u_serial, el subproceso A ejecuta la operación de apertura y llama a gs_open, el subproceso B ejecuta la operación de desconexión y llama a la función gserial_disconnect, el puntero port->port_usb se establecerá en NULL. P. ej. Hilo A Hilo B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Bloqueo Esto hace que el hilo A acceda a un puntero nulo (port->port_usb es nulo) al llamar a la función gs_free_requests, lo que provoca un bloqueo. Si port_usb es NULL, se omitirá la solicitud de liberación, ya que la realizará gserial_disconnect. Por lo tanto, agregue una verificación de puntero nulo a gs_start_io antes de intentar acceder al valor del puntero port->port_usb. Rastreo de llamadas: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invocar_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/reg_sr: Eliminar el grupo de registros Esa implementación del grupo no funciona realmente: si el krealloc mueve la memoria y devuelve otra dirección, las entradas en el xarray dejan de ser válidas, lo que lleva a un use-after-free más adelante: ERROR: KASAN: slab-use-after-free en xe_reg_sr_apply_mmio+0x570/0x760 [xe] Lectura de tamaño 4 en la dirección ffff8881244b2590 por la tarea modprobe/2753 Asignado por la tarea 2753: kasan_save_stack+0x39/0x70 kasan_save_track+0x14/0x40 kasan_save_alloc_info+0x37/0x60 __kasan_kmalloc+0xc3/0xd0 __kmalloc_node_track_caller_noprof+0x200/0x6d0 krealloc_noprof+0x229/0x380 Simplifique el código para corregir el error. Es posible que se agregue una mejor estrategia de agrupamiento más adelante si es necesario. (seleccionada de el commit e5283bd4dfecbd3335f43b62a68e24dae23f59e4)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btmtk: evitar UAF en btmtk_process_coredump hci_devcd_append puede provocar la liberación del skb, por lo que no se puede acceder a él una vez que se llama. ===================================================================== ERROR: KASAN: slab-use-after-free en btmtk_process_coredump+0x2a7/0x2d0 [btmtk] Lectura de tamaño 4 en la dirección ffff888033cfabb0 por la tarea kworker/0:3/82 CPU: 0 PID: 82 Comm: kworker/0:3 Contaminado: GU 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c Nombre del hardware: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 07/05/2024 Cola de trabajo: eventos btusb_rx_work [btusb] Seguimiento de llamadas: dump_stack_lvl+0xfd/0x150 print_report+0x131/0x780 kasan_report+0x177/0x1c0 btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01] btusb_recv_acl_mtk+0x11c/0x1a0 [btusb Asignado por la tarea 82: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 __kasan_slab_alloc+0x4e/0x60 kmem_cache_alloc+0x19f/0x360 skb_clone+0x132/0xf70 btusb_recv_acl_mtk+0x104/0x1a0 [btusb] btusb_rx_work+0x9e/0xe0 [btusb] subproceso de trabajo+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 Liberado por la tarea 1733: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 kasan_save_free_info+0x28/0xb0 ____kasan_slab_free+0xfd/0x170 kmem_cache_free+0x183/0x3f0 hci_devcd_rx+0x91a/0x2060 [bluetooth] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 La dirección con errores pertenece al objeto en ffff888033cfab40 que pertenece al caché skbuff_head_cache de tamaño 232 La dirección con errores se encuentra 112 bytes dentro de la región liberada de 232 bytes [ffff888033cfab40, ffff888033cfac28) La dirección con errores pertenece a la página física: page:00000000a174ba93 refcount:1 mapcount:0 mapeo:0000000000000000 índice:0x0 pfn:0x33cfa encabezado:00000000a174ba93 orden:1 recuento_de_mapas_entero:0 nr_páginas_asignadas:0 recuento_de_pins:0 anon banderas: 0x4000000000000840(slab|head|zone=1) tipo_de_página: 0xffffffff() sin procesar: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001 sin procesar: 000000000000000 000000000080190019 00000001ffffffff 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto Estado de la memoria alrededor de la dirección con errores: ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_event: Se solucionó el uso de rcu_read_(un)lock durante la iteración El uso de rcu_read_(un)lock mientras se está dentro de list_for_each_entry_rcu no es seguro ya que en la mayor parte de los casos las entradas obtenidas de esta manera se tratarán como rcu_dereference: Tenga en cuenta que el valor devuelto por rcu_dereference() solo es válido dentro de la sección crítica del lado de lectura de RCU [1]_. Por ejemplo, lo siguiente **no** es legal:: rcu_read_lock(); p = rcu_dereference(head.next); rcu_read_unlock(); x = p->address; /* ¡ERROR! */ rcu_read_lock(); y = p->data; /* ¡ERROR! */ rcu_read_unlock();

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no aplazar la destrucción de la regla mediante call_rcu nf_tables_chain_destroy puede dormir, no se puede utilizar desde las devoluciones de llamadas call_rcu. Además, nf_tables_rule_release() solo es seguro para desenrollar errores, mientras se mantiene el mutex de transacción y la regla a destruir no se expuso ni al plano de datos ni a los volcados, ya que desactiva + libera sin elsynchronous_rcu() requerido en el medio. Las devoluciones de llamadas nft_rule_expr_deactivate() cambiarán ->use contadores de otras cadenas/conjuntos, consulte, por ejemplo, la devolución de llamada nft_lookup .deactivate, que se deben serializar mediante el mutex de transacción. Agregue también algunas afirmaciones lockdep para que esto sea más explícito. Llamar asynchronous_rcu() no es ideal, pero solucionar esto sin él es difícil y mucho más intrusivo. Tal como está, podemos obtener: ADVERTENCIA: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Cola de trabajo: eventos nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Rastreo de llamadas: nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 En caso de que elsynchronous_rcu se convierta en un problema, podemos explorar alternativas. Una forma sería asignar objetos nft_trans_rule + un objeto nft_trans_chain, desactivar las reglas + la cadena y luego diferir la liberación a la cola de trabajo de destrucción de nft. Aún así, necesitaríamos mantener la ruta synchronization_rcu como respaldo para gestionar casos especiales de -ENOMEM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Arreglar la máscara de ID de agregación para evitar errores en los chips 5760X La interfaz HW GRO/LRO del chip 5760X (P7) es muy similar a la de la generación anterior (5750X o P5). Sin embargo, los campos de ID de agregación en las estructuras de finalización en P7 se han redefinido de 16 bits a 12 bits. Los 4 bits liberados se redefinen para parte de los metadatos, como el ID de VLAN. La máscara de ID de agregación no se modificó al agregar soporte para chips P7. Incluir los 4 bits adicionales para el ID de agregación puede hacer que el controlador almacene o busque el encabezado del paquete de paquetes GRO/LRO en el búfer TPA incorrecto. Puede alcanzar la condición BUG() en __skb_pull() porque el SKB no contiene un encabezado de paquete válido: ¡ERROR del kernel en include/linux/skbuff.h:2766! Ups: código de operación no válido: 0000 1 PREEMPT SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: cargado Contaminado: G OE 6.12.0-rc2+ #7 Contaminado: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 27/12/2022 RIP: 0010:eth_type_trans+0xda/0x140 Código: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a y siguientes 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 y siguientes 74 eb 31 f6 b9 02 00 00 00 48 RSP: 0018:ff615003803fcc28 EFLAGS: 00010283 RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040 RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001 R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0 R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000 FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Rastreo de llamadas: ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? eth_type_trans+0xda/0x140 ? do_error_trap+0x65/0x80 ? eth_type_trans+0xda/0x140 ? exc_invalid_op+0x4e/0x70 ? eth_type_trans+0xda/0x140 ? asm_exc_invalid_op+0x16/0x20 ? eth_type_trans+0xda/0x140 bnxt_tpa_end+0x10b/0x6b0 [bnxt_en] ? bnxt_tpa_start+0x195/0x320 [bnxt_es] bnxt_rx_pkt+0x902/0xd90 [bnxt_es] ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_es] ? kmem_cache_free+0x343/0x440 ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_es] __bnxt_poll_work+0x193/0x370 [bnxt_es] bnxt_poll_p5+0x9a/0x300 [bnxt_es] ? try_to_wake_up+0x209/0x670 __napi_poll+0x29/0x1b0 Solucione el problema redefiniendo la máscara de ID de agregación para los chips P5_PLUS para que sea de 12 bits. Esto funcionará porque la ID de agregación máxima es menor que 4096 en todos los chips P5_PLUS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: control: Evitar WARN() para errores de enlaces simbólicos El uso de WARN() para mostrar el error de creación de enlaces simbólicos no proporciona más información que la de indicar que algo va mal, ya que la ruta de código habitual es una devolución de llamada lregister desde cada creación de elemento de control. Lo que es peor, el uso de WARN() confunde bastante a fuzzer como si se tratara de problemas graves. Este parche degrada los mensajes de advertencia para utilizar el dev_err() normal en lugar de WARN(). Para que quede más claro, añade también el nombre de la función al prefijo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: defer final 'struct net' free en netns dismantle Ilya informó de un slab-use-after-free en dst_destroy [1] El problema está en xfrm6_net_init() y xfrm4_net_init(): copian xfrm[46]_dst_ops_template en net->xfrm.xfrm[46]_dst_ops. Pero la estructura net podría liberarse antes de que se llamen todas las devoluciones de llamadas dst. Entonces, cuando dst_destroy() llama más tarde: if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops apunta al antiguo net->xfrm.xfrm[46]_dst_ops, que ha sido liberado. Consulte un problema relevante corregido en: ac888d58869b ("net: no demore dst_entries_add() en dst_release()") Una solución es poner en cola la 'struct net' para que se libere después de otra ronda cleanup_net() (y rcu_barrier() existente) [1] ERROR: KASAN: slab-use-after-free en dst_destroy (net/core/dst.c:112) Lectura de tamaño 8 en la dirección ffff8882137ccab0 por la tarea swapper/37/0 03 de diciembre 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: cargado No contaminado 6.12.0 #67 Nombre del hardware: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:124) imprimir_dirección_descripción.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) imprimir_informe (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Código: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 00000000000000000 R08: 0000000000000001 R09: fffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminador 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? ¿__pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) 03 de diciembre 05:46:18 kernel: Asignado por la tarea 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) crear_nuevos_espacios_de_nombres ---truncado---