Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: elimina el soporte de tcp ulp setsockopt TCP_ULP setsockopt no se puede usar para mptcp porque ya se usa internamente para conectar sockets de subflujo (tcp) a la capa mptcp. syzbot logró desencadenar un bloqueo para las conexiones mptcp que están en modo alternativo: KASAN: null-ptr-deref en el rango [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2- syzkaller #0 RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [en línea] [..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [en línea] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c: 160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638 Elimina la compatibilidad con TCP_ULP setsockopt.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: corrija la eliminación de flores tc para la dirección Rx con prioridad de VLAN Para replicar el problema: - 1) Agregue 1 filtro de flores para la dirección de cuadros basada en prioridad de VLAN: - $ IFDEVNAME=eth0 $ tc qdisc agregar dev $IFDEVNAME ingreso $ tc qdisc agregar dev $IFDEVNAME raíz mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 \ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc filter add dev $IFDEVNAME parent ffff: protocolo 802.1Q \ flower vlan_prio 0 hw_tc 0 2) Obtener el id 'pref' $ tc filter show dev $IFDEVNAME ingress 3 ) Eliminar un registro de flor tc específico (digamos pref 49151) $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 Desde dmesg, observaremos el puntero NULL del kernel ooops [ 197.170464] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000000 [ 197.171367] #PF: acceso de lectura de supervisor en modo kernel [ 197.171367] #PF: error_code(0x0000) - página no presente [ 197.171367] PGD 0 P4D 0 [ 197.171367] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac] [ 197.171367] Seguimiento de llamadas: [ 197.171367] [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac] [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac] [ 197.171367] tc_setup_cb_destroy+0xb3/0x180 [ 197.171367] destroy_filter+0x94/0xc0 [cls_flower] El problema anterior se debe a una implementación anterior incorrecta de tc_del_vlan_flow( ), que se muestra a continuación, que usa flow_cls_offload_flow_rule() para obtener la estructura flow_rule *rule que ya no es válida para la operación de eliminación del filtro tc. estructura flow_rule *regla = flow_cls_offload_flow_rule(cls); estructura flow_dissector *dissector = regla->match.dissector; Por lo tanto, para garantizar que tc_del_vlan_flow() elimine el registro VLAN cls correcto para la cola RX configurada anteriormente (configurada por hw_tc) en tc_add_vlan_flow(), este parche introduce stmmac_rfs_entry como registro flow_cls_offload del lado del controlador para la flor tc 'Dirección de trama RX', actualmente utilizada para Prioridad de VLAN. La implementación ha tenido en cuenta una futura ampliación para incluir otro tipo de dirección de bastidor RX, como la basada en EtherType. v2: - Limpiar el rastreo demasiado extenso y reescribir el mensaje de git para explicar mejor el problema del puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: borrar el indicador 'kern' de los sockets de reserva La extensión mptcp ULP depende de que sk->sk_sock_kern esté configurado correctamente: impide que setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); de funcionar para sockets tcp simples (cualquier socket expuesto al espacio de usuario). Pero en caso de respaldo, aceptar() puede devolver un sk tcp simple. En tal caso, sk todavía está etiquetado como 'kernel' y setsockopt funcionará. Esto bloqueará el kernel. La extensión de subflujo tiene un socket NULL ctx->conn mptcp: ERROR: KASAN: null-ptr-deref en subflow_data_ready+0x181/0x2b0 Seguimiento de llamadas: tcp_data_ready+0xf8/0x370 [..]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: nunca permitir que el PM cierre un subflujo de escucha Actualmente, al eliminar un endpoint, el PM de netlink atraviesa todos los sockets MPTCP locales, independientemente de su estado. Si un socket de escucha MPTCP está vinculado a la IP que coincide con el endpoint de eliminación, el socket TCP de escucha se cerrará. Esto es inesperado, el PM solo debería afectar los subflujos de datos. Además, syzbot pudo activar una desreferencia de ptr NULL debido a lo anterior: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000018-0x0000000000000001f] CPU: 1 PID: 6550 Comm: syz-executor122 No contaminado 5.16.0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897 Código: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016 RAX: 00 RBX: 0000000000000018 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000000 a R12: 0000000000000000 R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0 Seguimiento de llamadas: lock_acquire kernel/locking/lockdep.c:5637 [en línea] +0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 Finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [en línea] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket. c:1864 [en línea] __se_sys_accept net/socket.c:1861 [en línea] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f177cd8b8e9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX : ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f177 ce13400 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c R13: cde1004 R14: 6d705f706374706d R15: 0000000000022000 Arreglar el problema al omitir explícitamente el socket MPTCP en el estado TCP_LISTEN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/console: protege hvc_xen contra tormentas de canales de eventos El controlador de la consola Xen aún es vulnerable a un ataque a través de un número excesivo de eventos enviados por el backend. Solucione eso usando un canal de eventos lateeoi. Para la consola inicial domU normal, esto requiere la introducción de bind_evtchn_to_irq_lateeoi() ya que no hay ningún dispositivo xenbus disponible en el momento en que el canal de eventos está vinculado al irq. Como la decisión de si una interrupción fue espuria o no requiere probar que los bytes se hayan leído desde el backend, mueva el envío del evento a la declaración if, ya que enviar un evento sin haber encontrado ningún byte para leer no tiene ningún sentido. Esto es parte de XSA-391 --- V2: - adaptar ligeramente la detección de irq espurias (Jan Beulich) V3: - corregir la detección de irq espurias (Jan Beulich)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: Verifique la longitud del descriptor del bloque en resp_mode_select() En resp_mode_select(), verifique la longitud del descriptor del bloque para evitar UAF. ERROR: KASAN: use-after-free en resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 Lectura del tamaño 1 en la dirección ffff888026670f50 por tarea scsicmd/15032 CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0 -01d0625 #15 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), seguimiento de llamadas del BIOS: dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107 print_address_description.constprop.9+0x28/0x160 mm/kasan/ report.c:257 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c: 2509 Schedule_resp+0x4af/0x1a10 controladores/scsi/scsi_debug.c:5483 scsi_debug_queuecommand+0x8c9/0x1e70 controladores/scsi/scsi_debug.c:7537 scsi_queue_rq+0x16b4/0x2d10 controladores/scsi/scsi_lib.c:1521 blk_mq_dispatch_rq_list+0xb9b/0x2700 bloque/ blk-mq.c:1640 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/ 0x150 cuadra/blk-mq. c:1762 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 ched.c:474 blk_execute_rq_nowait+0x16b /0x1c0 block/blk-exec.c:63 sg_common_write.isra.18+0xeb3/0x2000 controladores/scsi/sg.c:837 sg_new_write.isra.19+0x570/0x8c0 controladores/scsi/sg.c:775 sg_ioctl_common+0x14d6 /0x2710 controladores/scsi/sg.c:941 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1166 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52 do_syscall_64+0x3a/0x80 arch/x86/entry/common. c:50 entrada_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io-wq: comprueba la salida de wq después de agregar un nuevo trabajador task_work Comprobamos IO_WQ_BIT_EXIT antes de intentar crear un nuevo trabajador, y wq exit cancela el trabajo pendiente si tenemos alguno. Pero es posible tener una carrera entre los dos, donde las comprobaciones de creación salen y descubren que no está configurado, pero estamos en el proceso de salir. El lado de salida cancelará la creación pendiente task_work, pero hay un espacio en el que agregamos task_work después de haber cancelado las creaciones existentes en el momento de la salida. Solucione este problema marcando la publicación del bit EXIT agregando la tarea de creación_trabajo. Si está configurado, ejecute la misma cancelación que realiza la salida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: no llamar a kcalloc() si el tamaño arg es cero. Si el tamaño arg de kcalloc() es cero, devuelve ZERO_SIZE_PTR. Por eso, para que una siguiente verificación de puntero NULL funcione en el puntero devuelto, no se debe llamar a kcalloc() con el tamaño arg igual a cero. Regrese temprano sin errores antes de la llamada a kcalloc() si el tamaño arg es cero. ERROR: KASAN: null-ptr-deref en memcpy include/linux/fortify-string.h:191 [en línea] ERROR: KASAN: null-ptr-deref en sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 Escritura de tamaño 4 en la dirección 0000000000000010 por tarea syz-executor.1/22789 CPU: 1 PID: 22789 Comm: syz-executor.1 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0-2 Seguimiento de llamadas : __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 __kasan_report mm/kasan/report.c:446 [en línea] kasan_report.cold.14+0x112/0x117 mm/kasan/ report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x3b/0x60 mm/kasan/shadow.c:66 memcpy include/linux /fortify-string.h:191 [en línea] sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 controladores do_dout_fetch/scsi/scsi_debug.c:2954 [en línea] controladores do_dout_fetch/scsi/scsi_debug.c:2946 [en línea] resp_verify +0x49e/0x930 controladores/scsi/scsi_debug.c:4276 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi /scsi_lib.c: 1520 [en línea] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 lk-mq-sched.c:325 blk_mq_sched_dispatch_requests+ 0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 cola+0x18d/0x350 bloque/negro -mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 blk_execute_rq+0xdb/0x360 block/blk-exec.c:102 sg_scsi_ioctl controladores/scsi/scsi_ioctl.c:621 [en línea] scsi_ioctl+0x8bb/0x15c0 controladores/scsi/scsi_ioctl.c:930 sg_ioctl_common+0x172d/0x2710 controladores/scsi/sg.c:1112 sg_ioctl+0xa2/0 controladores x180/scsi/ SG.C: 1165 VFS_IOCTL FS/IOCTL.C: 51 [INLINE] __DO_SYS_IOCTL FS/IOCTL.C: 874 [INLINE] __SE_SYS_IOCTL FS/IOCTL.C: 860 [Inline] __X64_SY 60 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: corregir advertencia en ovl_create_real() Syzbot activó la siguiente advertencia en ovl_workdir_create() -> ovl_create_real(): if (!err && WARN_ON(!newdentry->d_inode)) { La razón es que el sistema de archivos cgroup2 regresa desde mkdir sin crear una instancia del nuevo dentry. Los sistemas de archivos extraños como este serán rechazados por overlayfs en una etapa posterior durante la instalación, pero para evitar dicha advertencia, llame a ovl_mkdir_real() directamente desde ovl_workdir_create() y rechace este caso anticipadamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: scsi_debug: corrige el tipo min_t para evitar la pila OOB. Cambie min_t() para usar el tipo "u32" en lugar de "int" para evitar la pila fuera de los límites. Con min_t() escriba "int", los valores se extienden y el valor mayor se usa provocando que la pila esté fuera de los límites. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:191 [en línea] ERROR: KASAN: pila fuera de los límites en sg_copy_buffer+0x1de/0x240 lib/scatterlist.c: 976 Lectura del tamaño 127 en la dirección ffff888072607128 mediante la tarea syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0 -2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan /report.c:442 [en línea] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x1a3/0x210 mm/kasan/generic .c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [en línea] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 controladores/scsi/scsi_debug.c:1162 fill_from_dev_buffer controladores/scsi/scsi_debug.c:1888 [en línea] resp_readcap16+0x365/0x3b0 controladores/scsi/scsi_debug.c :1887 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi/scsi_lib.c:1520 [en línea] Controladores 0x16b0/0x2d40/ scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x10 5/0x190 cuadra/blk-mq-programado. c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 :1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570 /0x8c0 controladores/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 controladores/scsi/sg.c:939 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] llamada al sistema_64 +0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

Motivo del rechazo: este ID CVE ha sido rechazado o retirado por su autoridad de numeración CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: Hacer que do_proc_control() y do_proc_bulk() se puedan eliminar. Los ioctls USBDEVFS_CONTROL y USBDEVFS_BULK invocan usb_start_wait_urb(), que contiene una espera ininterrumpida con un valor de tiempo de espera especificado por el usuario. Si el valor del tiempo de espera es muy grande y el dispositivo al que se accede no responde en un período de tiempo razonable, el kernel se quejará de "Tarea X bloqueada durante más de N segundos", como se encontró en las pruebas realizadas por syzbot: INFORMACIÓN: tarea syz-executor .0:8700 bloqueado durante más de 143 segundos. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-executor.0 estado:D pila:23192 pid: 8700 ppid: 8455 banderas:0x00004004 Seguimiento de llamadas: context_switch kernel/sched/core.c:4681 [en línea] __schedule+0xc07/0x11f0 kernel/sched/core.c :5938 programación+0x14b/0x210 kernel/sched/core.c:6017 Schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion .c:106 [en línea] wait_for_common kernel/sched/completion.c:117 [en línea] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 controladores/usb/core/devio.c:1236 controladores proc_bulk/usb/core/devio.c:1273 [en línea] usbdev_do_ioctl controladores/usb/core/devio.c:2547 [en línea] usbdev_ioctl+0x3441/ 0x6b10 drivers/usb/core/devio.c:2713 ... Para solucionar este problema, este parche reemplaza las llamadas de usbfs a usb_control_msg() y usb_bulk_msg() con código de propósito especial que hace esencialmente lo mismo (como se recomienda en el comentario para usb_start_wait_urb()), excepto que siempre usa una espera eliminable y usa GFP_KERNEL en lugar de GFP_NOIO.