Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/io-wq: use set_bit() y test_bit() en trabajador->flags Utilice set_bit() y test_bit() en trabajador->flags dentro de io_uring/io-wq para abordar posibles ejecucións de datos. Se puede acceder a la estructura io_worker->flags a través de varias rutas de datos, lo que genera problemas de concurrencia. Cuando KCSAN está habilitado, revela ejecucións de datos que ocurren en las funciones io_worker_handle_work y io_wq_activate_free_worker. ERROR: KCSAN: ejecución de datos en io_worker_handle_work/io_wq_activate_free_worker escribe en 0xffff8885c4246404 de 4 bytes por tarea 49071 en la CPU 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) (io_durante/io -wq.c:?) leer en 0xffff8885c4246404 de 4 bytes por tarea 49024 en la CPU 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io- wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) Números de línea contra El commit 18daea77cca6 ("Etiqueta de combinación 'para -linus' de git://git.kernel.org/pub/scm/virt/kvm/kvm"). Estas ejecuciones implican escrituras y lecturas en la misma ubicación de memoria mediante diferentes tareas que se ejecutan en diferentes CPU. Para mitigar esto, refactorice el código para usar operaciones atómicas como set_bit(), test_bit() y clear_bit() en lugar de operaciones básicas "y" y "o". Esto garantiza una manipulación segura para subprocesos de los indicadores de los trabajadores. Además, mueva `create_index` para evitar agujeros en la estructura.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ionic: corrige el pánico del kernel en la acción XDP_TX En la ruta XDP_TX, el controlador ionic envía un paquete a la ruta TX con la página rx y la dirección dma correspondiente. Una vez finalizada la transmisión, ionic_tx_clean() libera esa página. Pero el búfer de anillo RX no se restablece a NULL. Por lo tanto, utiliza una página liberada, lo que provoca pánico en el kernel. ERROR: no se puede manejar el error de página para la dirección: ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Ups: Ups: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comunicaciones: ksoftirqd/1 No contaminado 6.9. 0+ #11 Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 01/11/2021 RIP: 0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Código: 00 53 41 55 41 56 41 57 b8 01 0 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX: 0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09 : ffffed1027a04a23 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 0001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Seguimiento de llamadas: ? __morir+0x20/0x70 ? page_fault_oops+0x254/0x790? __pfx_page_fault_oops+0x10/0x10? __pfx_is_prefetch.constprop.0+0x10/0x10 ? search_bpf_extables+0x165/0x260? fixup_exception+0x4a/0x970? exc_page_fault+0xcb/0xe0? asm_exc_page_fault+0x22/0x30? 0xffffffffc0051f64? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? ionic_tx_clean+0x29b/0xc60 [iónico 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] x_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ? __pfx_net_rx_action+0x10/0x10

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hns3: soluciona el problema de falla del kernel en un escenario concurrente Cuando el estado del enlace cambia, el controlador nic debe notificar al controlador roce para manejar este evento, pero en este momento, el controlador roce puede desiniciar y luego causar un fallo del kernel. Para solucionar el problema, cuando cambia el estado del enlace, es necesario verificar si el roce se registró y, cuando se desinstala, es necesario esperar a que finalice la actualización del enlace.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: núcleo: eliminar WARN_ON() innecesario en implementar() Syzkaller recibió una advertencia [1] en una llamada a implementar() al intentar escribir un valor en un campo de tamaño más pequeño. tamaño en un informe de salida. Dado que implement() ya tiene un mensaje de advertencia impreso con la ayuda de hid_warn() y el valor en cuestión se recorta con: ... value &= m; ... WARN_ON puede considerarse superfluo. Elimínelo para suprimir futuros desencadenantes de syzkaller. [1] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid/hid-core.c:1451 implementar drivers/hid/hid-core.c:1451 [en línea] ADVERTENCIA: CPU: 0 PID: 5084 en drivers/hid /hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Módulos vinculados en: CPU: 0 PID: 5084 Comm: syz-executor424 No contaminado 6.9.0-rc7-syzkaller-00183 -gcf87f46fd34d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [en línea] RIP: 0010:hid_output_report+0x548/ 0x760 drivers/hid/hid-core.c:1863... Seguimiento de llamadas: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [en línea] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid -core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs /ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f...

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read() Obtuvimos el siguiente problema en una prueba de ejecución aleatoria del comando de restauración: ======== ==================================================== ======== ERROR: KASAN: slab-use-after-free en cachefiles_ondemand_daemon_read+0xb41/0xb60 Lectura de tamaño 8 en la dirección ffff888122e84088 por tarea ondemand-04-dae/963 CPU: 13 PID: 963 Comm: ondemand -04-dae Not tainted 6.8.0-dirty #564 Seguimiento de llamadas: kasan_report+0x93/0xc0 cachefiles_ondemand_daemon_read+0xb41/0xb60 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Asignado por tarea 116: kmem_cache_alloc+0x14 0/0x3a0 cachefiles_lookup_cookie+0x140/ 0xcd0 fscache_cookie_state_machine+0x43c/0x1230 [...] Liberado por la tarea 792: kmem_cache_free+0xfe/0x390 cachefiles_put_object+0x241/0x480 fscache_cookie_state_machine+0x5c8/0x1230 [...] =============== ==================================================== == El siguiente es el proceso que desencadena el problema: montar | daemon_thread1 | daemon_thread2 ------------------------------------------------- ----------- cachefiles_withdraw_cookie cachefiles_ondemand_clean_object(object) cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req- >object_id = solicitud->objeto ->ondemand->ondemand_id ------ restaurar ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req er, mensaje, n) xa_erase(&cache ->reqs, id) complete(&REQ_A->done) ------ close(fd) ------ cachefiles_ondemand_fd_release cachefiles_put_object cachefiles_put_object kmem_cache_free(cachefiles_object_jar, object) REQ_A->object->ondemand->ondemand_id // objeto UAF !!! Cuando vemos la solicitud dentro de xa_lock, req->object no debe haberse liberado aún, así que tome el recuento de referencia del objeto antes de xa_unlock para evitar el problema anterior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd() Obtuvimos el siguiente problema en una prueba de ejecución aleatoria del comando de restauración: ======== ==================================================== ======== ERROR: KASAN: slab-use-after-free en cachefiles_ondemand_daemon_read+0x609/0xab0 Escritura de tamaño 4 en la dirección ffff888109164a80 por tarea ondemand-04-dae/4962 CPU: 11 PID: 4962 Comm: ondemand -04-dae No contaminado 6.8.0-rc7-dirty #542 Seguimiento de llamadas: kasan_report+0x94/0xc0 cachefiles_ondemand_daemon_read+0x609/0xab0 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Asignado por tarea 626: /0x4b0 archivos de caché_ondemand_send_req+ 0x24d/0x690 cachefiles_create_tmpfile+0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] Liberado por tarea 626: kfree+0xf1/0x2c0 cachefiles_ondemand_send_req+0x568/0x690 cachefiles_create_tmpfile+ 0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] ======================= ============================================= El siguiente es el proceso que desencadena el problema: montar | daemon_thread1 | daemon_thread2 ------------------------------------------------- ----------- cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req cachefiles_ondemand_get_fd usuario(_buffer, msg, n) proceso_open_req(REQ_A) ------ restaurar ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW); cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req write(devfd, ("copen %u,%llu", msg->msg_id, tamaño)); cachefiles_ondemand_copen xa_erase(&cache->reqs, id) complete(&REQ_A->done) kfree(REQ_A) cachefiles_ondemand_get_fd(REQ_A) fd = get_unused_fd_flags file = anon_inode_getfile fd_install(fd, file) load = (void *)REQ_A->msg.data; cargar->fd = fd; // carga UAF !!! Este problema se debe a la emisión de un comando de restauración cuando el daemon todavía está activo, lo que da como resultado que una solicitud se procese varias veces y, por lo tanto, se active una UAF. Entonces, para evitar este problema, agregue un recuento de referencia adicional a cachefiles_req, que se mantiene mientras se espera y se lee, y luego se libera cuando finaliza la espera y la lectura. Tenga en cuenta que, dado que solo hay un recuento de referencias para esperar, debemos evitar que la misma solicitud se complete varias veces, por lo que solo podemos completar la solicitud si se elimina con éxito del xarray.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: elimina solicitudes de xarray durante las solicitudes de vaciado Incluso con CACHEFILES_DEAD configurado, aún podemos leer las solicitudes, por lo que en la siguiente concurrencia la solicitud se puede usar después de que se haya liberado: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------- --------- Cachefiles_ondemand_init_object Cachefiles_ondemand_send_req req_a = kzalloc (sizeof (*req) + data_len) Wait_for_completion (& req_a-> ded) gratis (req_a ) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // ¡¡¡requiere use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Por lo tanto, elimine las solicitudes de cache->reqs cuando las vacíe para evitar acceder a las solicitudes liberadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Evite que test/set_bit() opere en memoria no asignada. Existe un posible acceso fuera de los límites cuando se usa test_bit() en una sola palabra. Las funciones test_bit() y set_bit() operan con valores largos y, al probar o configurar una sola palabra, pueden exceder el límite de la palabra. KASAN detecta este problema y produce un volcado: ERROR: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/ bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Escritura de tamaño 8 en la dirección ffff8881d26e3c60 mediante tarea kworker/u1536:2/2965 Para obtener el registro completo, consulte [1]. Realice la asignación al menos del tamaño de sizeof(unsigned long) para que set_bit() y test_bit() tengan suficiente espacio para operaciones de lectura/escritura sin sobrescribir la memoria no asignada. [1] Enlace: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: arreglar el caso de use-after-free en tcpm_register_source_caps Podría haber un posible caso de use-after-free en tcpm_register_source_caps(). Esto podría suceder cuando: * se anuncian límites de fuente nuevos (por ejemplo, no válidos) * los límites de fuente existentes no están registrados * tcpm_register_source_caps() devuelve un error ya que usb_power_delivery_register_capabilities() falla Esto hace que port->partner_source_caps conserve los límites de fuente ahora liberados. Restablezca el valor de puerto->partner_source_caps a NULL después de cancelar el registro de los límites de origen existentes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: clase: cdc-wdm: soluciona el bloqueo de la CPU causado por mensajes de registro excesivos. El syzbot fuzzer descubrió que la devolución de llamada de finalización de interrupción-URB en el controlador cdc-wdm estaba tardando demasiado y el reenvío inmediato por parte del controlador de las URB de interrupción con estado -EPROTO combinado con la emulación ficticia-hcd para provocar un bloqueo de la CPU: cdc_wdm 1-1:1.0: estado de urb distinto de cero recibido: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes perro guardián: ERROR: bloqueo suave - ¡CPU#0 bloqueada durante 26 segundos! [syz-executor782:6625] CPU#0 Utilización cada 4 segundos durante el bloqueo: #1: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #2: 98% sistema, 0% softirq, 3% hardirq, 0 % inactivo #3: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #4: 98% sistema, 0% softirq, 3% hardirq, 0% inactivo #5: 98% sistema, 1% softirq, 3 % hardirq, 0% inactivo Módulos vinculados en: irq event stamp: 73096 hardirqs habilitado por última vez en (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs habilitado por última vez en (73095): [ ] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs deshabilitado por última vez en (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [en línea] hardirqs último deshabilitado en (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs habilitado por última vez en (73048): [] softirq_handle_end kernel/softirq.c:400 [en línea] softirqs habilitados por última vez en (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs deshabilitados por última vez en (73043): [] __do_softirq+0x14/0x20 kernel/softirq. c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Contaminado: GW 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Las pruebas mostraron que el problema no se produjo si se eliminaron los dos mensajes de error (las dos primeras líneas anteriores); aparentemente agregar material al registro del kernel lleva una cantidad de tiempo sorprendentemente grande. En cualquier caso, el mejor enfoque para prevenir estos bloqueos y evitar enviar spam al registro con miles de mensajes de error por segundo es limitar la velocidad de las dos llamadas dev_err(). Por eso los reemplazamos con dev_err_ratelimited().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: corrige posible ejecución en __fib6_drop_pcpu_from() syzbot encontró una ejecución en __fib6_drop_pcpu_from() [1] Si el compilador lee más de una vez (*ppcpu_rt), la segunda lectura podría leer NULL, si otra CPU borra el valor en rt6_get_pcpu_route(). Agregue un READ_ONCE() para evitar esta ejecución. Agregue también rcu_read_lock()/rcu_read_unlock() porque confiamos en la protección de RCU al eliminar la referencia a pcpu_rt. [1] Ups: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: trabajador/ u8:17 No contaminado 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Cola de trabajo: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0 +0x10a/0x370 net/ipv6/ip6_fib.c:984 Código: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 X: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: ffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(00 00) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001B32C26000 CR3: 000000005D56E000 CR4: 00000000003526F0 DR0: 00000000000000000000000000000000000000000000000000000000SET 0000000000FFFE0FF0 DR7: 000000000000000400 TRACE DE LLAMADA: __fib6_drop_pcpu_from net/ipv6/ip6_fib .c:966 [en línea] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [en línea] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [en línea] fib6_del+0xa70 /0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 /ip6_fib. c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [en línea] /0xa00 neto /ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c :93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [en línea] call_netdevice_notifiers net/core/dev.c:2044 [en línea] dev_close_many+0x333/0x6a0 net/core /dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [en línea] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x 128 /0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 Process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Process_scheduled_works kernel/workqueue.c:3312 [en línea] work_thread+ 0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64 .S:244