Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: Corrección del error de lectura slab-use-after-free en rxe_queue_cleanup Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En la función rxe_create_cq, cuando rxe_cq_from_init falla, se llamará a la función rxe_cleanup para gestionar los recursos asignados. De hecho, ya se han liberado algunos recursos de memoria en la función rxe_cq_from_init. Por lo tanto, se producirá este problema. La solución es dejar que rxe_cleanup haga todo el trabajo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: fallo en el manejo de nfs_get_lock_context en la ruta de desbloqueo. Cuando la memoria es insuficiente, la asignación de nfs_lock_context en nfs_get_lock_context() falla y devuelve -ENOMEM. Si por error tratamos una estructura nfs4_unlockdata (cuyo miembro l_ctx se ha establecido en -ENOMEM) como válida y procedemos a ejecutar rpc_run_task(), se activará una desreferencia de puntero NULL en nfs4_locku_prepare. Por ejemplo: ERROR: desreferencia de puntero NULL del núcleo, dirección: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: CR2: 000000000000000c [ fin de seguimiento 0000000000000000 ]--- Libera el nfs4_unlockdata asignado cuando nfs_get_lock_context() falla y devuelve NULL para finalizar la rpc_run_task posterior, lo que evita la desreferencia del puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: max20086: corrige acceso de memoria no válido max20086_parse_regulators_dt() llama a of_regulator_match() utilizando una matriz de struct of_regulator_match asignada en la pila para el argumento matches. of_regulator_match() llama a devm_of_regulator_put_matches(), que llama a devres_alloc() para asignar un struct devm_of_regulator_matches que se desasignará utilizando devm_of_regulator_put_matches(). struct devm_of_regulator_matches se rellena con la matriz matches asignada a la pila. Si el dispositivo no realiza el sondeo, se llamará a devm_of_regulator_put_matches() e intentará llamar a of_node_put() en ese puntero de pila, lo que generará las siguientes entradas dmesg: max20086 6-0028: Failed to read DEVICE_ID reg: -121 kobject: '\xc0$\xa5\x03' (000000002cebcb7a): no se ha inicializado, pero se está llamando a kobject_put(). Seguido de un seguimiento de la pila que coincide con el flujo de llamada descrito anteriormente. Cambie a la asignación de la matriz de coincidencias mediante devm_kcalloc() para evitar acceder al puntero de pila mucho después de que esté fuera del alcance. Esto también tiene la ventaja de permitir que varios max20086 realicen el sondeo sin sobrescribir los datos almacenados dentro del global of_regulator_match.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige la comprobación nula de pipe_ctx->plane_state para update_dchubp_dpp. Similar a el commit 6a057072ddd1 ("drm/amd/display: Se corrige la comprobación nula de pipe_ctx->plane_state en dcn20_program_pipe"), que soluciona una desreferencia de puntero nulo en dcn20_update_dchubp_dpp. Esta es la misma función asociada a update_dchubp_dpp en dcn401, con el mismo problema. También se corrige una posible desreferencia de puntero nulo en dcn401_program_pipe. (Seleccionado de el commit d8d47f739752227957d8efc0cb894761bfe1d879)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: spectrum_router: Se corrige el use-after-free al eliminar dispositivos de red GRE. El controlador solo descarga a los vecinos que se construyen sobre dispositivos de red registrados por él o sus superiores (que son todos Ethernet). El dispositivo admite la encapsulación y desencapsulación GRE del tráfico reenviado, pero el controlador no descargará vecinos ficticios construidos sobre dispositivos de red GRE ya que no son superiores a sus dispositivos de red: # ip link add name gre1 up type gre tos heritage local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP (Tenga en cuenta que el vecino no está marcado con 'offload') Cuando se vuelve a cargar el controlador y se reproduce la configuración existente, el controlador no realiza la misma comprobación con respecto a los vecinos existentes y descarga el agregado previamente: # devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP Si el vecino se elimina más tarde, el controlador ignorará la notificación (dado que el dispositivo de red GRE no es su superior) y, por lo tanto, seguirá haciendo referencia a la memoria liberada, lo que dará como resultado un use-after-free [1] cuando se elimine el dispositivo de red: # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1 Se soluciona omitiendo la reproducción del vecino si el dispositivo de red para el que se realiza la reproducción no es nuestro superior. [1] ERROR: KASAN: slab-use-after-free en mlxsw_sp_neigh_entry_update+0x1ea/0x200 Lectura de tamaño 8 en la dirección ffff888155b0e420 por la tarea ip/2282 [...] Rastreo de llamadas: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/eventpoll: corrige un bucle ocupado sin fin después de que expira el tiempo de espera Después de el commit 0a65bc27bd64 ("eventpoll: establece el tiempo de espera de epoll si es en el futuro"), el siguiente programa ingresaría inmediatamente en un bucle ocupado en el kernel: ``` int main() { int e = epoll_create1(0); struct epoll_event event = {.events = EPOLLIN}; epoll_ctl(e, EPOLL_CTL_ADD, 0, &event); const struct timespec timeout = {.tv_nsec = 1}; epoll_pwait2(e, &event, 1, &timeout, 0); } ``` Esto sucede porque el tiempo de espera dado (distinto de cero) de 1 nanosegundo generalmente expira antes de que se ingrese ep_poll() y luego ep_schedule_timeout() devuelve falso, pero `timed_out` nunca se establece porque se omite la línea de código que lo establece. Esto rápidamente se convierte en un bloqueo suave, RCU se bloquea y se bloquea, lo que inflige graves dolores de cabeza a todo el sistema. Cuando el tiempo de espera ha expirado, no necesitamos programar un hrtimer, pero debemos establecer la variable `timed_out`. Por lo tanto, sugiero mover la comprobación de ep_schedule_timeout() a la expresión `timed_out` en lugar de omitirla. brauner: Tenga en cuenta que hubo una corrección anterior por Joe Damato en respuesta a mi informe de error en [1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: bpf: abortar envío si dispositivo destruido La implementación actual de HID bpf asume que no pasará por ella ningún informe/solicitud de salida después de que se haya llamado a hid_bpf_destroy_device(). Esto lleva a un error que al desconectar ciertos tipos de dispositivos HID hace que se acceda a una SRCU limpiada. El error era anteriormente un fallo oculto hasta que un cambio reciente de x86 por CPU [1] hizo que accediera a páginas no presentes. El error se activará si se cumplen las siguientes condiciones: A) un dispositivo bajo el controlador tiene algunos LED encendidos B) hid_ll_driver->request() no está implementado (por ejemplo, logitech-djreceiver) Si se cumple la condición A, hidinput_led_worker() siempre se programa *después* de hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] Esto funciona correctamente cuando no se cumple la condición B, en cuyo caso hidinput_led_worker() invoca hid_ll_driver->request(). Este es el caso de la mayoría de los controladores HID, que lo implementan o utilizan el genérico de usbhid. El propio controlador o uno subyacente abortará el procesamiento de la solicitud. De lo contrario, hidinput_led_worker() intenta hid_hw_output_report() y genera el error. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) El error existe desde la introducción [2] de dispatch_hid_bpf_output_report(). Sin embargo, el mismo error también existe en dispatch_hid_bpf_raw_requests(), y he reproducido (sin efecto visible debido a la falta de [1], pero confirmado bpf.destroyed == 1) el error contra el commit (es decir, las correcciones:) que introduce la función. Esto se debe a que hidinput_led_worker() recurre a hid_hw_raw_request() cuando hid_ll_driver->output_report() no está implementado (p. ej., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Corrija el problema retornando antes en las dos funciones mencionadas si hid_bpf se marcó como destruido. Aunque dispatch_hid_bpf_device_event() maneja eventos de entrada y no hay evidencia de que pueda llamarse después de la destrucción, también se le agrega la misma verificación, como red de seguridad, para mantener la consistencia entre todas las funciones de despacho. El impacto del error en otras arquitecturas no está claro. Incluso si se trata de un fallo oculto, sigue siendo peligroso, ya que corrompe la dirección calculada por SRCU. Por lo tanto, se copia la lista estable. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Usar desplazamientos relativos por CPU") [2]: commit 9286675a2aed ("HID: bpf: añadir enlaces HID-BPF para hid_hw_output_report")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Deshabilitar la descarga de MACsec para el perfil de representante de enlace ascendente. La descarga de MACsec no es compatible con el modo switchdev para los representantes de enlace ascendente. Al cambiar al perfil de representante de enlace ascendente, se debe desactivar la función de descarga de MACsec de las características del dispositivo de red. Si se deja activada, los intentos de agregar descargas resultan en una desreferencia de puntero nulo, ya que el representante de enlace ascendente no admite la descarga de MACsec, aunque el bit de característica permanezca activado. Desactive NETIF_F_HW_MACSEC en mlx5e_fix_uplink_rep_features(). Registro del núcleo: Ups: fallo de protección general, probablemente para dirección no canónica 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip No contaminado 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Código: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 000000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: fffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000000000 R12: 00000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Rastreo de llamadas: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrección del pánico del kernel cuando alloc_page falla. No se puede establecer frag_list como un puntero nulo cuando alloc_page falla. Se usará en tls_strp_check_queue_ok la próxima vez que se invoque tls_strp_read_sock. Esto se debe a que no se restablece full_len en tls_strp_flush_anchor_copy(), por lo que la ruta de recepción intentará continuar gestionando el registro parcial en la siguiente llamada, pero se ha desvinculado el rcvq de la lista de fragmentos. Una solución alternativa sería restablecer full_len. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000028 Rastreo de llamadas: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: se corrige una fuga de memoria en la ruta de gestión de errores de idxd_alloc. La memoria asignada a idxd no se libera si se produce un error durante idxd_alloc(). Para solucionarlo, libere la memoria asignada en orden inverso a la asignación antes de salir de la función en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: Solución del problema "KASAN: slab-use-after-free Read in ib_register_device" Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Este problema es Similar al problema corregido en el commit 1d6a9e7449e2 ("RDMA/core: Corrección del problema de use-after-free al cambiar el nombre del dispositivo"). La causa principal es que la función ib_device_rename() cambia el nombre con bloqueo. Sin embargo, en la función kobject_uevent(), se accede a este nombre sin protección de bloqueo. La solución es añadir la protección de bloqueo al acceder a este nombre en la función kobject_uevent().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Refactorizar la llamada de eliminación con el asistente idxd_cleanup(). Este asistente limpia el monitor de rendimiento, las interrupciones, los componentes internos, etc. Refactorizar la llamada de eliminación con el asistente idxd_cleanup() para evitar la duplicación de código. Cabe destacar que esto también corrige la función put_device() que faltaba para los grupos, motores y máquinas virtuales idxd.