Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: Se corrige el use-after-free del socket del kernel en cleanup_bearer(). syzkaller informó un use-after-free del socket del kernel UDP en cleanup_bearer() sin reproducción. [0][1] Cuando bearer_disable() llama a tipc_udp_disable(), la desinfección del socket del kernel UDP se pospone mediante el trabajo que llama a cleanup_bearer(). tipc_net_stop() espera a que finalicen dichos trabajos comprobando tipc_net(net)->wq_count. Sin embargo, el trabajo disminuye el recuento demasiado pronto antes de liberar el socket del kernel, desbloqueando cleanup_net() y dando como resultado un use-after-free. Muevamos la disminución después de liberar el socket en cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf tiene 1/1 usuarios en sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: ERROR: KMSAN: use-after-free en udp_hashslot include/net/udp.h:85 [en línea] ERROR: KMSAN: use-after-free en udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [en línea] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [en línea] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 proceso_one_work kernel/workqueue.c:3229 [en línea] proceso_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit se creó en: slab_free_hook mm/slub.c:2269 [en línea] slab_free mm/slub.c:4580 [en línea] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [en línea] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [en línea] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 No contaminado 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 01/04/2014 Cola de trabajo: eventos cleanup_bearer

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: corrige la fuga de memoria cuando falla la creación de un nuevo control Ahora, aunque falla la creación de un nuevo control, no hemos liberado el conjunto de etiquetas ocupado por admin_q, aquí intentamos solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: dev: can_set_termination(): permitir GPIO inactivos En el commit 6e86a1543c37 ("can: dev: proporcionar soporte de terminación basado en GPIO opcional") se agregó soporte de terminación basado en GPIO. Sin ninguna razón en particular, ese parche usa gpiod_set_value() para configurar el GPIO. Esto lleva a la siguiente advertencia, si el sistema usa un GPIO inactivo, es decir, detrás de un expansor de puerto I2C: | ADVERTENCIA: CPU: 0 PID: 379 en /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip No contaminado 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c Reemplace gpiod_set_value() por gpiod_set_value_cansleep() para permitir el uso de GPIO inactivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la escritura fuera de los límites en ksmbd_vfs_stream_write. Un desplazamiento del cliente podría ser un valor negativo, lo que podría permitir escribir datos fuera de los límites del búfer asignado. Tenga en cuenta que este problema se produce al configurar 'vfs objects = streams_xattr parameter' en ksmbd.conf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se ha corregido la lectura fuera de los límites en ksmbd_vfs_stream_read. Un desplazamiento del cliente podría ser un valor negativo, lo que podría provocar una lectura fuera de los límites desde stream_buf. Tenga en cuenta que este problema se produce al configurar 'vfs objects = streams_xattr parameter' en ksmbd.conf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Agregar huge_pte_clear() específico de la arquitectura. Al ejecutar las pruebas automáticas mm run_vmtests.sh, aparece el siguiente error: BUG: Bad page state in process uffd-unit-tests pfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 página volcada porque: PAGE_FLAGS_CHECK_AT_FREE indicador(es) establecido(s) Módulos vinculados en: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests No contaminado 6.12.0 #184 Nombre del hardware: QEMU Máquina virtual QEMU, BIOS desconocido 2/2/2022 Pila: 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 000000000000001 000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000ffffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 000000000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 000000000000000 0000000000071c1d ... Seguimiento de llamadas: [<9000000000223a94>] show_stack+0x5c/0x180 [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0 [<900000000056aa08>] página_incorrecta+0x1a0/0x1f0 [<9000000000574978>] folios_sin_referencia_gratis+0xbf0/0xd20 [<90000000004e65cc>] folios_colocar_referencias+0x1a4/0x2b8 [<9000000000599a0c>] páginas_y_caché_de_intercambio_gratis+0x164/0x260 [<9000000000547698>] vaciado_de_páginas_por_lotes_tlb+0xa8/0x1c0 [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218 [<9000000000543cb8>] salida_mmap+0x1a0/0x360 [<9000000000247658>] __mmput+0x78/0x200 [<900000000025583c>] hacer_salir+0x43c/0xde8 [<9000000000256490>] hacer_grupo_salir+0x68/0x110 [<9000000000256554>] grupo_salir_sistema+0x1c/0x20 [<9000000001c413b4>] hacer_llamada_sistema+0x94/0x130 [<90000000002216d8>] handle_syscall+0xb8/0x158 Deshabilitando la depuración de bloqueo debido a una contaminación del kernel ERROR: pgtables_bytes distintos de cero al liberar mm: -16384 En el sistema LoongArch, una entrada pte enorme no válida debe ser invalid_pte_table o un solo bit _PAGE_HUGE en lugar de un valor cero. Y debería ser lo mismo con una entrada pmd no válida, ya que pmd_none() es llamada por la función free_pgd_range() y pmd_none() devuelve 0 por huge_pte_clear(). Por lo tanto, un solo bit _PAGE_HUGE también se trata como una tabla pte válida y free_pte_range() se llamará en free_pmd_range(). free_pmd_range() pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); if (pmd_none_or_clear_bad(pmd)) continue; free_pte_range(tlb, pmd, addr); } while (pmd++, addr = next, addr != end); Aquí invalid_pte_table se utiliza tanto para entradas pte enormes no válidas como para entradas pmd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: wacom: solución cuando se obtiene el nombre del producto, puede haber un puntero nulo. Debido a que ciertos dispositivos informan incorrectamente dev->product, se producen desreferencias de puntero nulo cuando dev->product está vacío, lo que provoca posibles fallas del sistema. Este problema se encontró en el dispositivo EXCELSIOR DL37-D05 con placa base Loongson-LS3A6000-7A2000-DL37. Registros del núcleo: [56.470885] usb 4-3: nuevo dispositivo USB de velocidad completa número 4 que utiliza ohci-pci [56.671638] usb 4-3: error de lectura del descriptor de cadena 0: -22 [56.671644] usb 4-3: nuevo dispositivo USB encontrado, idVendor=056a, idProduct=0374, bcdDevice= 1.07 [56.671647] usb 4-3: nuevas cadenas de dispositivos USB: Mfr=1, Product=2, SerialNumber=3 [56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: dispositivo USB HID v1.10 [HID 056a:0374] activado usb-0000:00:05.0-3/input0 [ 56.697719] CPU 2 No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80 [ 56.697732] Oops[#1]: [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015 [ 56.697737] Nombre del hardware: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 11/10/2024 [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0 [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000 [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000 [ 56.697745] t0 ffff800004818b2d t1 00000000000000000 t2 0000000000000003 t3 0000000000000005 [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 00000000000000000 t7 00000000000000000 [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028 [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000 [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000 [ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom] [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120 [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE) [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 56.697835] BADV: 0000000000000000 [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 56.697838] Módulos vinculados en: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore leds de entrada mousedev clase led joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs tablas ip tablas x superposición amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit [ 56.697887] Proceso (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3) [ 56.697890] Pila: 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000 [ 56.697896] 000000000000000 0000011fffffffd 000000000000000 000000000000000 [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0 [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c [ 56.697911] 9000001000ba000 ffff800004f9ce58 000000000000000 ffff800005470440 [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0 [ 56.697921] 000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 000000000000000 [ 56.697931] 90000001000bb8d0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: inodo libre cuando ocfs2_get_init_inode() falla syzbot informa inodos ocupados después del desmontaje, para el commit 9c89fe0af826 ("ocfs2: Error de gestión de dquot_initialize()") olvidó llamar a iput() cuando new_inode() tuvo éxito y dquot_initialize() falló.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp_bpf: Arreglar la lógica sk_mem_uncharge en tcp_bpf_sendmsg La lógica actual de contabilidad de memoria sk en __SK_REDIRECT está pre-descargando bytes tosend, que es msg->sg.size o un valor menor apply_bytes. Los problemas potenciales con esta estrategia son los siguientes: - Si los bytes enviados reales son más pequeños que tosend, necesitamos cargar algunos bytes de vuelta, como en la línea 487, lo cual está bien pero no parece limpio. - Cuando tosend está configurado en apply_bytes, como en la línea 417, y (ret < 0), podemos perder la descarga de (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 si (psock->aplicar_bytes && psock->aplicar_bytes < para enviar) 417 para enviar = psock->aplicar_bytes; [...] 443 sk_msg_return(sk, msg, para enviar); 444 release_sock(sk); 446 tamaño original = msg->sg.tamaño; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, para enviar, indicadores); 449 enviado = tamaño original - msg->sg.tamaño; [...] 454 bloqueo_sock(sk); 455 si (improbable(ret < 0)) { 456 int libre = sk_msg_libre_sincarga(sk, msg); 458 si (!corcho) 459 *copiado -= libre; 460 } [...] 487 si (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - enviado); [...] Al ejecutar la prueba automática test_txmsg_redir_wait_sndmem con txmsg_apply, se informará la siguiente advertencia: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 6 PID: 57 en net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Módulos vinculados: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 No contaminado 6.12.0-rc1.bm.1-amd64+ #43 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Cola de trabajo: eventos sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: muerto000000000100 FS: 000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 proceso_trabajos_programados+0xa3/0x3e0 subproceso_trabajador+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_de_bifurcación+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ fin del seguimiento 000000000000000 ]--- En __SK_REDIRECT, una forma más concisa es retrasar la descarga después de que se finalizan los bytes enviados y descargar este valor. Cuando (ret < 0), invocaremos sk_msg_free. Lo mismo sucede en el caso __SK_DROP, cuando tosend se establece en apply_bytes, podemos perder la descarga de (msg->sg.size - apply_bytes) bytes. La misma advertencia se informará en la autoprueba. [...] 468 caso __SK_DROP: 469 predeterminado: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] Entonces, en lugar de sk_msg_free_partial, podemos hacer sk_msg_free aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: corrige la fuga de memoria cuando falla la creación de un nuevo control Ahora, aunque falla la creación de un nuevo control, no hemos liberado el conjunto de etiquetas ocupado por admin_q, aquí intentamos solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cacheinfo: Asignar memoria durante la conexión en caliente de la CPU si no se hace desde la CPU principal. el commit 5944ce092b97 ("arch_topology: Generar cacheinfo desde la CPU principal") añade una funcionalidad que las arquitecturas pueden utilizar para asignar y generar opcionalmente cacheinfo de forma temprana durante el arranque. el commit 6539cffa9495 ("cacheinfo: Añadir inicializador de nivel temprano específico de la arquitectura") permite que las CPU secundarias corrijan (y reasignen memoria) los datos de cacheinfo si es necesario. Si no se utiliza la funcionalidad de generación temprana y cacheinfo no necesita corrección, nunca se asigna memoria para cacheinfo. x86 no utiliza la funcionalidad de generación temprana. En consecuencia, durante la devolución de llamada hotplug de CPU de cacheinfo, last_level_cache_is_valid() intenta desreferenciar un puntero NULL: BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a Asigne memoria para cacheinfo durante la devolución de llamada hotplug de CPU de cacheinfo si no se hizo antes. Además, antes de determinar la validez de la información de caché de último nivel, asegúrese de que se haya asignado. No basta con comprobar si hay cache_leaves() distintos de cero, ya que algunas arquitecturas (por ejemplo, los procesadores Intel) tienen cache_leaves() distintos de cero antes de la asignación. La anulación de referencias a cacheinfo NULL puede ocurrir en update_per_cpu_data_slice_size(). Esta función itera sobre todas las CPU en línea. Sin embargo, es posible que una CPU se haya conectado recientemente, pero que su cacheinfo aún no se haya asignado. Mientras esté aquí, elimine una sangría innecesaria en allocate_cache_info(). [ bp: Masaje. ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx: gpcv2: Ajuste del retraso después del protocolo de enlace de encendido El udelay(5) no es suficiente, a veces el pánico del kernel aún se puede activar: [ 4.012973] Pánico del kernel: no sincroniza: Interrupción de error asincrónica [ 4.012976] CPU: 2 UID: 0 PID: 186 Comm: (udev-worker) No contaminado 6.12.0-rc2-0.0.0-devel-00004-g8b1b79e88956 #1 [ 4.012982] Nombre del hardware: Toradex Verdin iMX8M Plus WB en placa Dahlia (DT) [ 4.012985] Rastreo de llamadas: [...] [ 4.013029] arm64_serror_panic+0x64/0x70 [ 4.013034] do_serror+0x3c/0x70 [ 4.013039] el1h_64_error_handler+0x30/0x54 [ 4.013046] el1h_64_error+0x64/0x68 [ 4.013050] clk_imx8mp_audiomix_runtime_resume+0x38/0x48 [ 4.013059] __genpd_runtime_resume+0x30/0x80 [ 4.013066] genpd_runtime_resume+0x114/0x29c [ 4.013073] __rpm_callback+0x48/0x1e0 [ 4.013079] rpm_callback+0x68/0x80 [ 4.013084] rpm_resume+0x3bc/0x6a0 [ 4.013089] __pm_runtime_resume+0x50/0x9c [ 4.013095] pm_runtime_get_suppliers+0x60/0x8c [ 4.013101] __driver_probe_device+0x4c/0x14c [ 4.013108] driver_probe_device+0x3c/0x120 [ 4.013114] __driver_attach+0xc4/0x200 [ 4.013119] bus_for_each_dev+0x7c/0xe0 [ 4.013125] driver_attach+0x24/0x30 [ 4.013130] bus_add_driver+0x110/0x240 [ 4.013135] driver_register+0x68/0x124 [ 4.013142] __platform_driver_register+0x24/0x30 [ 4.013149] sdma_driver_init+0x20/0x1000 [imx_sdma] [ 4.013163] do_one_initcall+0x60/0x1e0 [ 4.013168] do_init_module+0x5c/0x21c [ 4.013175] load_module+0x1a98/0x205c [ 4.013181] init_module_from_file+0x88/0xd4 [ 4.013187] __arm64_sys_finit_module+0x258/0x350 [ 4.013194] anybody_syscall.constprop.0+0x50/0xe0 [ 4.013202] anyone_syscall.constprop.0+0x50/0xe0 [ 4.013202] anyone_syscall.constprop.0+0x50/0xe0 [ 4.013208] anyone_syscall.constprop.0+0x3c/0x140 [ 4.013215] anyone_sysvc+0x120/0x12c [ 4.013222] anyone_sysvc+0x3c/0x140 [ 4.013215] anyone_sysvc+0x120/0x12c [ 4.013222] anyone_sys_sync+0x190/0x194 [ 4.013228] SMP: deteniendo CPUs secundarias La forma correcta es esperar el protocolo de enlace, pero necesita que el reloj BUS de BLK-CTL esté habilitado, lo cual está en un controlador separado. Entonces, el retraso es la única opción aquí. Udelay(10) es un dato obtenido mediante experimento.