Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar posible desreferencia NULL en rt6_uncached_list_flush_dev() el commit culpable eliminó accidentalmente una comprobación para que rt->rt6i_idev fuera NULL, como lo detectó syzbot: Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor No contaminado 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [en línea] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Código: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notificador_cadena_llamada+0x19f/0x3e0 kernel/notifier.c:93 llamar_notificadores_dispositivo_red_extack net/core/dev.c:2032 [en línea] llamar_notificadores_dispositivo_red_net/core/dev.c:2046 [en línea] anular_registro_de_varios_dispositivos_red_notificar+0xd81/0x1c40 net/core/dev.c:11352 anular_registro_de_varios_dispositivos_red_net/core/dev.c:11414 [en línea] anular_registro_de_cola_de_dispositivos_red_+0x303/0x370 net/core/dev.c:11289 anular_registro_de_dispositivo_red include/linux/netdevice.h:3129 [en línea] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [en línea] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [en línea] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [en línea] __se_sys_exit_group kernel/exit.c:1040 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f DESCARGA: 0033:0x7f1acc77def9 Código: No se puede acceder a los bytes del código de operación en 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 00000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Módulos vinculados en: ---[ fin del seguimiento 000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [en línea] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Código: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: bcm: Borrar bo->bcm_proc_read después de remove_proc_entry(). syzbot informó una advertencia en bcm_release(). [0] El cambio en cuestión corrigió otra advertencia que se activa cuando se vuelve a emitir connect() para un socket cuyo dispositivo conectado se ha anulado el registro. Sin embargo, si el socket simplemente se cierra sin el segundo connect(), el bo->bcm_proc_read restante activa un remove_proc_entry() innecesario en bcm_release(). Borremos bo->bcm_proc_read después de remove_proc_entry() en bcm_notify(). [0] nombre '4986' ADVERTENCIA: CPU: 0 PID: 5234 en fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Módulos vinculados en: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 No contaminado 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Código: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 0 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 00000000000000000 RSI: 0000000000000000 RDI: 00000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [en línea] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [en línea] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [en línea] __se_sys_exit_group kernel/exit.c:1040 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Código: No se puede acceder a los bytes del código de operación en 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sock_map: Agregar un cond_resched() en sock_hash_free() Varios informes de bloqueo suave de syzbot tienen en común sock_hash_free(). Si se destruye un mapa con una gran cantidad de depósitos, debemos ceder la CPU cuando sea necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: usar recuperación skb de dos fases en ieee80211_do_stop() Dado que '__dev_queue_xmit()' se debe llamar con las interrupciones habilitadas, se realiza el siguiente seguimiento: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() con IRQS deshabilitado ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) emite la advertencia (según lo informado por el reproductor syzbot): ADVERTENCIA: CPU: 2 PID: 5128 en kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Solucione esto implementando una recuperación de skb de dos fases en 'ieee80211_do_stop()', donde el trabajo real se realiza fuera de una sección con las interrupciones deshabilitadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Corregir limpieza de pd de UMR en flujo de error de inicialización del controlador el commit citada mueve la asignación de pd de la función mlx5r_umr_resource_cleanup() a una nueva función mlx5r_umr_cleanup(). Por lo tanto, la corrección en el commit [1] no funciona. En el flujo de error, se activará el pánico [2]. Corríjalo comprobando el puntero pd para evitar el pánico si es NULL; [1] RDMA/mlx5: Se corrige la limpieza de UMR en el flujo de error del inicio del controlador [2] [ 347.567063] infiniband mlx5_0: No se pudo registrar el dispositivo con el modelo del controlador [ 347.591382] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000020 [ 347.593438] #PF: acceso de lectura del supervisor en modo kernel [ 347.595176] #PF: error_code(0x0000) - página no presente [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 000000000000000 RDI: 000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Seguimiento de llamadas: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? kernfs_add_one+0x107/0x150 [347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] sonda_de_bus_auxiliar+0x3e/0x90 [ 347.620448] sonda_realmente+0xc5/0x3a0 [ 347.620857] __dispositivo_de_sonda_del_controlador+0x80/0x160 [ 347.621325] dispositivo_de_sonda_del_controlador+0x1e/0x90 [ 347.621770] __dispositivo_de_sonda_del_controlador+0xec/0x1c0 [ 347.622213] ? __controlador_de_conexión_de_dispositivo+0x100/0x100 [ 347.622724] bus_para_cada_dispositivo+0x71/0xc0 [ 347.623151] bus_agregar_controlador+0xed/0x240 [ 347.623570] registro_del_controlador+0x58/0x100 [ 347.623998] __registro_del_controlador_auxiliar+0x6a/0xc0 [ 347.624499] ? registro_del_controlador+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] hacer_una_llamada_inicia+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] hacer_init_module+0x8a/0x260 [ 347.627126] iniciar_módulo_desde_archivo+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] hacer_syscall_64+0x4c/0x100

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: comprobar la compatibilidad del tamaño de la franja al volver a montar también Deshabilitamos el tamaño de la franja en __ext4_fill_super si no es un múltiplo de la relación del clúster; sin embargo, esta comprobación se omite al intentar volver a montar. Esto puede dejarnos con casos en los que stripe < cluster_ratio después de remount:set, lo que hace que EXT4_B2C(sbi->s_stripe) se convierta en 0, lo que puede causar algunos errores imprevistos como dividir por 0. Solucione eso agregando la comprobación en la ruta de montaje también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Error en la verificación de la extensión de signo del paquete data/data_end/data_meta syzbot informó de un fallo del kernel debido a el commit 1f1e864b6555 ("bpf: Manejar los accesos a miembros ctx de la extensión de signo"). La razón se debe a la extensión de signo de la carga de 32 bits para el campo uapi del paquete data/data_end/data_meta. El código original se ve así: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Tenga en cuenta que la carga de __sk_buff->data tiene una extensión de signo de 32 bits. Después de la verificación y convert_ctx_accesses(), el código asm final se ve así: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Tenga en cuenta que 'r2 = (s32)r2' puede hacer que la dirección __sk_buff->data del núcleo sea inválida, lo que puede causar un error en tiempo de ejecución. Actualmente, en el código C, normalmente tenemos void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... y generará r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 Si permitimos la extensión de signo, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... el código generado se ve así r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 y esto causará un error de verificación ya que "r2 <<= 32" no está permitido ya que "r2" es un puntero de paquete. Para solucionar este problema en el caso r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */, este parche agregó una verificación adicional en la función de devolución de llamada is_valid_access() para el acceso a los paquetes data/data_end/data_meta. Si esos accesos son con la extensión sign-extenstion, la verificación fallará. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, lsm: Agregar comprobación para el valor de retorno de BPF LSM Un programa bpf que devuelve un número positivo adjunto al gancho file_alloc_security hace que el kernel entre en pánico. Esto sucede porque el sistema de archivos no puede filtrar el número positivo devuelto por el programa LSM usando IS_ERR y malinterpreta este número positivo como un puntero de archivo. Dado que el gancho file_alloc_security nunca devolvió un número positivo antes de la introducción de BPF LSM, y otros ganchos BPF LSM pueden encontrar problemas similares, este parche agrega la comprobación del valor de retorno de LSM en el verificador, para garantizar que no se devuelva ningún valor inesperado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/core: Arreglar la limpieza del flujo de error ib_cache_setup_one Cuando ib_cache_update devuelve un error, salimos de ib_cache_setup_one instantáneamente sin una limpieza adecuada, aunque antes de esto ya habíamos realizado con éxito gid_table_setup_one, que da como resultado la siguiente ADVERTENCIA del kernel. Realice una limpieza adecuada utilizando gid_table_cleanup_one antes de devolver el error para solucionar el problema. ADVERTENCIA: CPU: 4 PID: 922 en drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Módulos vinculados: CPU: 4 UID: 0 PID: 922 Comm: c_repro No contaminado 6.11.0-rc1+ #3 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Código: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? Obtener tarea pid+0xb0/0xd0 ? error_proc_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 hacer_syscall_64+0x50/0x110 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs-clt: Restablecer cid a con_num - 1 para permanecer dentro de los límites En la función init_conns(), después del bucle for create_con() y create_cm() si algo falla. En el bucle for de limpieza después de la etiqueta destroy, accedemos a memoria fuera de los límites porque cid está configurado en clt_path->s.con_num. Esta confirmación restablece el cid a clt_path->s.con_num - 1, para permanecer dentro de los límites en el bucle de limpieza más tarde.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: media: dvb-frontends/rtl2832: corrige un error de escritura fuera de los límites Asegúrate de que el índice en rtl2832_pid_filter no supere 31 para evitar el acceso fuera de los límites. dev->filters es un valor de 32 bits, por lo que las funciones set_bit y clear_bit solo deben funcionar en índices de 0 a 31. Si el índice es 32, intentará acceder a un bit 33 inexistente, lo que provocará un acceso fuera de los límites. Cambia la comprobación de límites de índice > 32 a índice >= 32 para resolver este problema. [hverkuil: se agregó la etiqueta de correcciones, rtl2830_pid_filter -> rtl2832_pid_filter en logmsg]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency En el commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), se invoca la función flush_workqueue para vaciar la cola de trabajo iwcm_wq. Pero en ese momento, la cola de trabajo iwcm_wq se creó a través de la función alloc_ordered_workqueue sin el indicador WQ_MEM_RECLAIM. Debido a que el proceso actual está intentando vaciar todo iwcm_wq, si iwcm_wq no tiene el indicador WQ_MEM_RECLAIM, verifique que el proceso actual no esté recuperando memoria o ejecutándose en una cola de trabajo que no tenga el indicador WQ_MEM_RECLAIM, ya que eso puede romper la garantía de progreso hacia adelante y provocar un bloqueo. El seguimiento de la llamada es el siguiente: [ 125.350876][ T1430] Seguimiento de la llamada: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminador 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminador 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminador 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (núcleo/bloqueo/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (controladores/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (controladores/nvme/host/rdma.c:656 controladores/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (controladores/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] proceso_uno_trabajo (kernel/workqueue.c:3231) [ 125.515122][ T1430] subproceso_de_trabajo (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_subproceso_de_trabajo (kernel/workqueue.c:3339) [ 125.531837][ T1430] subproceso_de_trabajo (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ fin de seguimiento 000000000000000 ]---