Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: remove tcp ulp setsockopt support<br /> <br /> TCP_ULP setsockopt cannot be used for mptcp because its already<br /> used internally to plumb subflow (tcp) sockets to the mptcp layer.<br /> <br /> syzbot managed to trigger a crash for mptcp connections that are<br /> in fallback mode:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]<br /> CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0<br /> RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline]<br /> [..]<br /> __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]<br /> tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160<br /> do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391<br /> mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638<br /> <br /> Remove support for TCP_ULP setsockopt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix tc flower deletion for VLAN priority Rx steering<br /> <br /> To replicate the issue:-<br /> <br /> 1) Add 1 flower filter for VLAN Priority based frame steering:-<br /> $ IFDEVNAME=eth0<br /> $ tc qdisc add dev $IFDEVNAME ingress<br /> $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \<br /> map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \<br /> queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0<br /> $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \<br /> flower vlan_prio 0 hw_tc 0<br /> <br /> 2) Get the &amp;#39;pref&amp;#39; id<br /> $ tc filter show dev $IFDEVNAME ingress<br /> <br /> 3) Delete a specific tc flower record (say pref 49151)<br /> $ tc filter del dev $IFDEVNAME parent ffff: pref 49151<br /> <br /> From dmesg, we will observe kernel NULL pointer ooops<br /> <br /> [ 197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 197.171367] #PF: supervisor read access in kernel mode<br /> [ 197.171367] #PF: error_code(0x0000) - not-present page<br /> [ 197.171367] PGD 0 P4D 0<br /> [ 197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> <br /> <br /> <br /> [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac]<br /> <br /> <br /> <br /> [ 197.171367] Call Trace:<br /> [ 197.171367] <br /> [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac]<br /> [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac]<br /> [ 197.171367] tc_setup_cb_destroy+0xb3/0x180<br /> [ 197.171367] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]<br /> <br /> The above issue is due to previous incorrect implementation of<br /> tc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule()<br /> to get struct flow_rule *rule which is no longer valid for tc filter<br /> delete operation.<br /> <br /> struct flow_rule *rule = flow_cls_offload_flow_rule(cls);<br /> struct flow_dissector *dissector = rule-&gt;match.dissector;<br /> <br /> So, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for<br /> earlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(),<br /> this patch introduces stmmac_rfs_entry as driver-side flow_cls_offload<br /> record for &amp;#39;RX frame steering&amp;#39; tc flower, currently used for VLAN<br /> priority. The implementation has taken consideration for future extension<br /> to include other type RX frame steering such as EtherType based.<br /> <br /> v2:<br /> - Clean up overly extensive backtrace and rewrite git message to better<br /> explain the kernel NULL pointer issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: clear &amp;#39;kern&amp;#39; flag from fallback sockets<br /> <br /> The mptcp ULP extension relies on sk-&gt;sk_sock_kern being set correctly:<br /> It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); from<br /> working for plain tcp sockets (any userspace-exposed socket).<br /> <br /> But in case of fallback, accept() can return a plain tcp sk.<br /> In such case, sk is still tagged as &amp;#39;kernel&amp;#39; and setsockopt will work.<br /> <br /> This will crash the kernel, The subflow extension has a NULL ctx-&gt;conn<br /> mptcp socket:<br /> <br /> BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0<br /> Call Trace:<br /> tcp_data_ready+0xf8/0x370<br /> [..]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: never allow the PM to close a listener subflow<br /> <br /> Currently, when deleting an endpoint the netlink PM treverses<br /> all the local MPTCP sockets, regardless of their status.<br /> <br /> If an MPTCP listener socket is bound to the IP matching the<br /> delete endpoint, the listener TCP socket will be closed.<br /> That is unexpected, the PM should only affect data subflows.<br /> <br /> Additionally, syzbot was able to trigger a NULL ptr dereference<br /> due to the above:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897<br /> Code: 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 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff<br /> RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016<br /> RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000<br /> RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001<br /> R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000<br /> R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001<br /> FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> lock_acquire kernel/locking/lockdep.c:5637 [inline]<br /> lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162<br /> finish_wait+0xc0/0x270 kernel/sched/wait.c:400<br /> inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]<br /> inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497<br /> mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865<br /> inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739<br /> mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345<br /> do_accept+0x382/0x510 net/socket.c:1773<br /> __sys_accept4_file+0x7e/0xe0 net/socket.c:1816<br /> __sys_accept4+0xb0/0x100 net/socket.c:1846<br /> __do_sys_accept net/socket.c:1864 [inline]<br /> __se_sys_accept net/socket.c:1861 [inline]<br /> __x64_sys_accept+0x71/0xb0 net/socket.c:1861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f177cd8b8e9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b<br /> RAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c<br /> R13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000<br /> <br /> <br /> Fix the issue explicitly skipping MPTCP socket in TCP_LISTEN<br /> status.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()<br /> <br /> In resp_mode_select() sanity check the block descriptor len to avoid UAF.<br /> <br /> BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509<br /> Read of size 1 at addr ffff888026670f50 by task scsicmd/15032<br /> <br /> CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107<br /> print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257<br /> kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443<br /> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306<br /> resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509<br /> schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483<br /> scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537<br /> scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63<br /> sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837<br /> sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775<br /> sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: check for wq exit after adding new worker task_work<br /> <br /> We check IO_WQ_BIT_EXIT before attempting to create a new worker, and<br /> wq exit cancels pending work if we have any. But it&amp;#39;s possible to have<br /> a race between the two, where creation checks exit finding it not set,<br /> but we&amp;#39;re in the process of exiting. The exit side will cancel pending<br /> creation task_work, but there&amp;#39;s a gap where we add task_work after we&amp;#39;ve<br /> canceled existing creations at exit time.<br /> <br /> Fix this by checking the EXIT bit post adding the creation task_work.<br /> If it&amp;#39;s set, run the same cancelation that exit does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Don&amp;#39;t call kcalloc() if size arg is zero<br /> <br /> If the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of<br /> that, for a following NULL pointer check to work on the returned pointer,<br /> kcalloc() must not be called with the size arg equal to zero. Return early<br /> without error before the kcalloc() call if size arg is zero.<br /> <br /> BUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]<br /> BUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974<br /> Write of size 4 at addr 0000000000000010 by task syz-executor.1/22789<br /> <br /> CPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106<br /> __kasan_report mm/kasan/report.c:446 [inline]<br /> kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189<br /> memcpy+0x3b/0x60 mm/kasan/shadow.c:66<br /> memcpy include/linux/fortify-string.h:191 [inline]<br /> sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974<br /> do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]<br /> do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]<br /> resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276<br /> schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478<br /> scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533<br /> scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]<br /> scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62<br /> blk_execute_rq+0xdb/0x360 block/blk-exec.c:102<br /> sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]<br /> scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930<br /> sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix warning in ovl_create_real()<br /> <br /> Syzbot triggered the following warning in ovl_workdir_create() -&gt;<br /> ovl_create_real():<br /> <br /> if (!err &amp;&amp; WARN_ON(!newdentry-&gt;d_inode)) {<br /> <br /> The reason is that the cgroup2 filesystem returns from mkdir without<br /> instantiating the new dentry.<br /> <br /> Weird filesystems such as this will be rejected by overlayfs at a later<br /> stage during setup, but to prevent such a warning, call ovl_mkdir_real()<br /> directly from ovl_workdir_create() and reject this case early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Fix type in min_t to avoid stack OOB<br /> <br /> Change min_t() to use type "u32" instead of type "int" to avoid stack out<br /> of bounds. With min_t() type "int" the values get sign extended and the<br /> larger value gets used causing stack out of bounds.<br /> <br /> BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]<br /> BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976<br /> Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707<br /> <br /> CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106<br /> print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189<br /> memcpy+0x23/0x60 mm/kasan/shadow.c:65<br /> memcpy include/linux/fortify-string.h:191 [inline]<br /> sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976<br /> sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000<br /> fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162<br /> fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]<br /> resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887<br /> schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478<br /> scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533<br /> scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]<br /> scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62<br /> sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836<br /> sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774<br /> sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Make do_proc_control() and do_proc_bulk() killable<br /> <br /> The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke<br /> usb_start_wait_urb(), which contains an uninterruptible wait with a<br /> user-specified timeout value. If timeout value is very large and the<br /> device being accessed does not respond in a reasonable amount of time,<br /> the kernel will complain about "Task X blocked for more than N<br /> seconds", as found in testing by syzbot:<br /> <br /> INFO: task syz-executor.0:8700 blocked for more than 143 seconds.<br /> Not tainted 5.14.0-rc7-syzkaller #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004<br /> Call Trace:<br /> context_switch kernel/sched/core.c:4681 [inline]<br /> __schedule+0xc07/0x11f0 kernel/sched/core.c:5938<br /> schedule+0x14b/0x210 kernel/sched/core.c:6017<br /> schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857<br /> do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85<br /> __wait_for_common kernel/sched/completion.c:106 [inline]<br /> wait_for_common kernel/sched/completion.c:117 [inline]<br /> wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157<br /> usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63<br /> do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236<br /> proc_bulk drivers/usb/core/devio.c:1273 [inline]<br /> usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]<br /> usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713<br /> ...<br /> <br /> To fix this problem, this patch replaces usbfs&amp;#39;s calls to<br /> usb_control_msg() and usb_bulk_msg() with special-purpose code that<br /> does essentially the same thing (as recommended in the comment for<br /> usb_start_wait_urb()), except that it always uses a killable wait and<br /> it uses GFP_KERNEL rather than GFP_NOIO.