- 17 Jan, 2020 16 commits
-
-
Tyler Hicks authored
This patch is a simplified fix to address a use-after-free in 4.14.x and 4.19.x stable kernels. The flaw is already fixed upstream, starting in 5.2, by commit 7dc40713 ("drm/i915: Introduce a mutex for file_priv->context_idr") as part of a more complex patch series that isn't appropriate for backporting to stable kernels. Expand mutex coverage, while destroying the GEM context, to include the GEM context lookup step. This fixes a use-after-free detected by KASAN: ================================================================== BUG: KASAN: use-after-free in i915_ppgtt_close+0x2ca/0x2f0 Write of size 1 at addr ffff8881368a8368 by task i915-poc/3124 CPU: 0 PID: 3124 Comm: i915-poc Not tainted 4.14.164 #1 Hardware name: HP HP Elite x2 1012 G1 /80FC, BIOS N85 Ver. 01.20 04/05/2017 Call Trace: dump_stack+0xcd/0x12e ? _atomic_dec_and_lock+0x1b2/0x1b2 ? i915_ppgtt_close+0x2ca/0x2f0 ? printk+0x8f/0xab ? show_regs_print_info+0x53/0x53 ? i915_ppgtt_close+0x2ca/0x2f0 print_address_description+0x65/0x270 ? i915_ppgtt_close+0x2ca/0x2f0 kasan_report+0x251/0x340 i915_ppgtt_close+0x2ca/0x2f0 ? __radix_tree_insert+0x3f0/0x3f0 ? i915_ppgtt_init_hw+0x7c0/0x7c0 context_close+0x42e/0x680 ? i915_gem_context_release+0x230/0x230 ? kasan_kmalloc+0xa0/0xd0 ? radix_tree_delete_item+0x1d4/0x250 ? radix_tree_lookup+0x10/0x10 ? inet_recvmsg+0x4b0/0x4b0 ? kasan_slab_free+0x88/0xc0 i915_gem_context_destroy_ioctl+0x236/0x300 ? i915_gem_context_create_ioctl+0x360/0x360 ? drm_dev_printk+0x1d0/0x1d0 ? memcpy+0x34/0x50 ? i915_gem_context_create_ioctl+0x360/0x360 drm_ioctl_kernel+0x1b0/0x2b0 ? drm_ioctl_permit+0x2a0/0x2a0 ? avc_ss_reset+0xd0/0xd0 drm_ioctl+0x6fe/0xa20 ? i915_gem_context_create_ioctl+0x360/0x360 ? drm_getstats+0x20/0x20 ? put_unused_fd+0x260/0x260 do_vfs_ioctl+0x189/0x12d0 ? ioctl_preallocate+0x280/0x280 ? selinux_file_ioctl+0x3a7/0x680 ? selinux_bprm_set_creds+0xe30/0xe30 ? security_file_ioctl+0x69/0xa0 ? selinux_bprm_set_creds+0xe30/0xe30 SyS_ioctl+0x6f/0x80 ? __sys_sendmmsg+0x4a0/0x4a0 ? do_vfs_ioctl+0x12d0/0x12d0 do_syscall_64+0x214/0x5f0 ? __switch_to_asm+0x31/0x60 ? __switch_to_asm+0x25/0x60 ? __switch_to_asm+0x31/0x60 ? syscall_return_slowpath+0x2c0/0x2c0 ? copy_overflow+0x20/0x20 ? __switch_to_asm+0x25/0x60 ? syscall_return_via_sysret+0x2a/0x7a ? prepare_exit_to_usermode+0x200/0x200 ? __switch_to_asm+0x31/0x60 ? __switch_to_asm+0x31/0x60 ? __switch_to_asm+0x25/0x60 ? __switch_to_asm+0x25/0x60 ? __switch_to_asm+0x31/0x60 ? __switch_to_asm+0x25/0x60 ? __switch_to_asm+0x31/0x60 ? __switch_to_asm+0x31/0x60 ? __switch_to_asm+0x25/0x60 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7f7fda5115d7 RSP: 002b:00007f7eec317ec8 EFLAGS: 00000286 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7fda5115d7 RDX: 000055b306db9188 RSI: 000000004008646e RDI: 0000000000000003 RBP: 00007f7eec317ef0 R08: 00007f7eec318700 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007f7eec317fc0 R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffd8007ade0 Allocated by task 2898: save_stack+0x32/0xb0 kasan_kmalloc+0xa0/0xd0 kmem_cache_alloc_trace+0x5e/0x180 i915_ppgtt_create+0xab/0x2510 i915_gem_create_context+0x981/0xf90 i915_gem_context_create_ioctl+0x1d7/0x360 drm_ioctl_kernel+0x1b0/0x2b0 drm_ioctl+0x6fe/0xa20 do_vfs_ioctl+0x189/0x12d0 SyS_ioctl+0x6f/0x80 do_syscall_64+0x214/0x5f0 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Freed by task 104: save_stack+0x32/0xb0 kasan_slab_free+0x72/0xc0 kfree+0x88/0x190 i915_ppgtt_release+0x24e/0x460 i915_gem_context_free+0x90/0x480 contexts_free_worker+0x54/0x80 process_one_work+0x876/0x14e0 worker_thread+0x1b8/0xfd0 kthread+0x2f8/0x3c0 ret_from_fork+0x35/0x40 The buggy address belongs to the object at ffff8881368a8000 which belongs to the cache kmalloc-8192 of size 8192 The buggy address is located 872 bytes inside of 8192-byte region [ffff8881368a8000, ffff8881368aa000) The buggy address belongs to the page: page:ffffea0004da2a00 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x200000000008100(slab|head) raw: 0200000000008100 0000000000000000 0000000000000000 0000000100030003 raw: dead000000000100 dead000000000200 ffff88822a002280 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881368a8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881368a8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881368a8300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881368a8380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881368a8400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 1acfc104 ("drm/i915: Enable rcu-only context lookups") Reported-by:
罗权 <luoquan@qianxin.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: stable@vger.kernel.org # 4.14.x Cc: stable@vger.kernel.org # 4.19.x Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
YueHaibing authored
commit 1d3ff095 upstream. If dccp_feat_push_change fails, we forget free the mem which is alloced by kmemdup in dccp_feat_clone_sp_val. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: e8ef967a ("dccp: Registration routines for changing feature values") Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Navid Emamdoost authored
commit 4a9d46a9 upstream. In bnxt_re_create_srq(), when ib_copy_to_udata() fails allocated memory should be released by goto fail. Fixes: 37cb11ac ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Link: https://lore.kernel.org/r/20190910222120.16517-1-navid.emamdoost@gmail.comSigned-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Navid Emamdoost authored
commit 0f4f1994 upstream. In iwl_pcie_ctxt_info_gen3_init there are cases that the allocated dma memory is leaked in case of error. DMA memories prph_scratch, prph_info, and ctxt_info_gen3 are allocated and initialized to be later assigned to trans_pcie. But in any error case before such assignment the allocated memories should be released. First of such error cases happens when iwl_pcie_init_fw_sec fails. Current implementation correctly releases prph_scratch. But in two sunsequent error cases where dma_alloc_coherent may fail, such releases are missing. This commit adds release for prph_scratch when allocation for prph_info fails, and adds releases for prph_scratch and prph_info when allocation for ctxt_info_gen3 fails. Fixes: 2ee82402 ("iwlwifi: pcie: support context information for 22560 devices") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Navid Emamdoost authored
commit b4b814fe upstream. In alloc_sgtable if alloc_page fails, the alocated table should be released. Signed-off-by:
-
Vandana BN authored
commit 5d2e73a5 upstream. SyzKaller hit the null pointer deref while reading from uninitialized udev->product in zr364xx_vidioc_querycap(). ================================================================== BUG: KASAN: null-ptr-deref in read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 Read of size 1 at addr 0000000000000000 by task v4l_id/5287 CPU: 1 PID: 5287 Comm: v4l_id Not tainted 5.1.0-rc3-319004-g43151d6 #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 kasan_report.cold+0x5/0x3c mm/kasan/report.c:321 read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 strscpy+0x8a/0x280 lib/string.c:207 zr364xx_vidioc_querycap+0xb5/0x210 drivers/media/usb/zr364xx/zr364xx.c:706 v4l_querycap+0x12b/0x340 drivers/media/v4l2-core/v4l2-ioctl.c:1062 __video_do_ioctl+0x5bb/0xb40 drivers/media/v4l2-core/v4l2-ioctl.c:2874 video_usercopy+0x44e/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3056 v4l2_ioctl+0x14e/0x1a0 drivers/media/v4l2-core/v4l2-dev.c:364 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xced/0x12f0 fs/ioctl.c:696 ksys_ioctl+0xa0/0xc0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:718 do_syscall_64+0xcf/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f3b56d8b347 Code: 90 90 90 48 8b 05 f1 fa 2a 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 90 90 90 90 90 90 90 90 90 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 fa 2a 00 31 d2 48 29 c2 64 RSP: 002b:00007ffe005d5d68 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f3b56d8b347 RDX: 00007ffe005d5d70 RSI: 0000000080685600 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000400884 R13: 00007ffe005d5ec0 R14: 0000000000000000 R15: 0000000000000000 ================================================================== For this device udev->product is not initialized and accessing it causes a NULL pointer deref. The fix is to check for NULL before strscpy() and copy empty string, if product is NULL Reported-by: syzbot+66010012fd4c531a1a96@syzkaller.appspotmail.com Signed-off-by:
Vandana BN <bnvandana@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> [bwh: Backported to 4.19: This function uses strlcpy() instead of strscpy()] Signed-off-by:
-
Sheng Yong authored
commit 720db068 upstream. Dentry bitmap is not enough to detect incorrect dentries. So this patch also checks the namelen value of a dentry. Signed-off-by:
Gong Chen <gongchen4@huawei.com> Signed-off-by:
Sheng Yong <shengyong1@huawei.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Jaegeuk Kim authored
commit 4e240d1b upstream. If namelen is corrupted to have very long value, fill_dentries can copy wrong memory area. Reviewed-by:
-
Ben Hutchings authored
This is preparation for the following backported fixes. It was done upstream as part of commit e1293bdf "f2fs: plug readahead IO in readdir()", the rest of which does not seem suitable for stable. Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Chao Yu <yuchao0@huawei.com> Signed-off-by:
-
Jouni Malinen authored
commit 3e493173 upstream. The Layer 2 Update frame is used to update bridges when a station roams to another AP even if that STA does not transmit any frames after the reassociation. This behavior was described in IEEE Std 802.11F-2003 as something that would happen based on MLME-ASSOCIATE.indication, i.e., before completing 4-way handshake. However, this IEEE trial-use recommended practice document was published before RSN (IEEE Std 802.11i-2004) and as such, did not consider RSN use cases. Furthermore, IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been maintained amd should not be used anymore. Sending out the Layer 2 Update frame immediately after association is fine for open networks (and also when using SAE, FT protocol, or FILS authentication when the station is actually authenticated by the time association completes). However, it is not appropriate for cases where RSN is used with PSK or EAP authentication since the station is actually fully authenticated only once the 4-way handshake completes after authentication and attackers might be able to use the unauthenticated triggering of Layer 2 Update frame transmission to disrupt bridge behavior. Fix this by postponing transmission of the Layer 2 Update frame from station entry addition to the point when the station entry is marked authorized. Similarly, send out the VLAN binding update only if the STA entry has already been authorized. Signed-off-by:
Jouni Malinen <jouni@codeaurora.org> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Dedy Lansky authored
commit 30ca1aa5 upstream. Make ieee80211_send_layer2_update() a common function so other drivers can re-use it. Signed-off-by:
Dedy Lansky <dlansky@codeaurora.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 4.19 as dependency of commit 3e493173 "mac80211: Do not send Layer 2 Update frame before authorization"] Signed-off-by:
-
Arnd Bergmann authored
commit ad312f95 upstream. The select() implementation is carefully tuned to put a sensible amount of data on the stack for holding a copy of the user space fd_set, but not too large to risk overflowing the kernel stack. When building a 32-bit kernel with clang, we need a little more space than with gcc, which often triggers a warning: fs/select.c:619:5: error: stack frame size of 1048 bytes in function 'core_sys_select' [-Werror,-Wframe-larger-than=] int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp, I experimentally found that for 32-bit ARM, reducing the maximum stack usage by 64 bytes keeps us reliably under the warning limit again. Link: http://lkml.kernel.org/r/20190307090146.1874906-1-arnd@arndb.deSigned-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Andi Kleen <ak@linux.intel.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Eric Dumazet <edumazet@google.com> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Miles Chen <miles.chen@mediatek.com> Signed-off-by:
-
Arnd Bergmann authored
commit 3499e87e upstream. clang inlines the dev_ethtool() more aggressively than gcc does, leading to a larger amount of used stack space: net/core/ethtool.c:2536:24: error: stack frame size of 1216 bytes in function 'dev_ethtool' [-Werror,-Wframe-larger-than=] Marking the sub-functions that require the most stack space as noinline_for_stack gives us reasonable behavior on all compilers. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Jiri Kosina authored
[ Upstream commit 9e635c28 ] hidraw and uhid device nodes are always available for writing so we should always report EPOLLOUT and EPOLLWRNORM bits, not only in the cases when there is nothing to read. Reported-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marcel Holtmann authored
[ Upstream commit 9f3b61dc ] When polling a connected /dev/hidrawX device, it is useful to get the EPOLLOUT when writing is possible. Since writing is possible as soon as the device is connected, always return it. Right now EPOLLOUT is only returned when there are also input reports are available. This works if devices start sending reports when connected, but some HID devices might need an output report first before sending any input reports. This change will allow using EPOLLOUT here as well. Fixes: 378b8037 ("hidraw: Return EPOLLOUT from hidraw_poll") Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Fabian Henneke authored
[ Upstream commit 378b8037 ] Always return EPOLLOUT from hidraw_poll when a device is connected. This is safe since writes are always possible (but will always block). hidraw does not support non-blocking writes and instead always calls blocking backend functions on write requests. Hence, so far, a call to poll never returned EPOLLOUT, which confuses tools like socat. Signed-off-by:
Fabian Henneke <fabian.henneke@gmail.com> In-reply-to: <CA+hv5qkyis03CgYTWeWX9cr0my-d2Oe+aZo+mjmWRXgjrGqyrw@mail.gmail.com> Signed-off-by:
-
- 14 Jan, 2020 24 commits
-
-
Greg Kroah-Hartman authored
-
Akeem G Abodunrin authored
commit bc8a76a1 upstream. Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Intel GPU Hardware prior to Gen11 does not clear EU state during a context switch. This can result in information leakage between contexts. For Gen8 and Gen9, hardware provides a mechanism for fast cleardown of the EU state, by issuing a PIPE_CONTROL with bit 27 set. We can use this in a context batch buffer to explicitly cleardown the state on every context switch. As this workaround is already in place for gen8, we can borrow the code verbatim for Gen9. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Kumar Valsan Prathap <prathap.kumar.valsan@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Balestrieri Francesco <francesco.balestrieri@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Cc: Dutt Sudeep <sudeep.dutt@intel.com> Signed-off-by:
-
Florian Westphal authored
commit 22dad713 upstream. The set uadt functions assume lineno is never NULL, but it is in case of ip_set_utest(). syzkaller managed to generate a netlink message that calls this with LINENO attr present: general protection fault: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:hash_mac4_uadt+0x1bc/0x470 net/netfilter/ipset/ip_set_hash_mac.c:104 Call Trace: ip_set_utest+0x55b/0x890 net/netfilter/ipset/ip_set_core.c:1867 nfnetlink_rcv_msg+0xcf2/0xfb0 net/netfilter/nfnetlink.c:229 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 nfnetlink_rcv+0x1ba/0x460 net/netfilter/nfnetlink.c:563 pass a dummy lineno storage, its easier than patching all set implementations. This seems to be a day-0 bug. Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Reported-by: syzbot+34bd2369d38707f3f4a7@syzkaller.appspotmail.com Fixes: a7b4f989 ("netfilter: ipset: IP set core support") Signed-off-by:
Florian Westphal <fw@strlen.de> Acked-by:
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Florian Westphal authored
commit 1d9a7acd upstream. The timeout pointer can be NULL which means we should modify the per-nets timeout instead. All do this, except sctp and dccp which instead give: general protection fault: 0000 [#1] PREEMPT SMP KASAN net/netfilter/nf_conntrack_proto_dccp.c:682 ctnl_timeout_parse_policy+0x150/0x1d0 net/netfilter/nfnetlink_cttimeout.c:67 cttimeout_default_set+0x150/0x1c0 net/netfilter/nfnetlink_cttimeout.c:368 nfnetlink_rcv_msg+0xcf2/0xfb0 net/netfilter/nfnetlink.c:229 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 Reported-by: syzbot+46a4ad33f345d1dd346e@syzkaller.appspotmail.com Fixes: c779e849 ("netfilter: conntrack: remove get_timeout() indirection") Signed-off-by:
-
Florian Westphal authored
commit 1b789577 upstream. We get crash when the targets checkentry function tries to make use of the network namespace pointer for arptables. When the net pointer got added back in 2010, only ip/ip6/ebtables were changed to initialize it, so arptables has this set to NULL. This isn't a problem for normal arptables because no existing arptables target has a checkentry function that makes use of par->net. However, direct users of the setsockopt interface can provide any target they want as long as its registered for ARP or UNPSEC protocols. syzkaller managed to send a semi-valid arptables rule for RATEEST target which is enough to trigger NULL deref: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN RIP: xt_rateest_tg_checkentry+0x11d/0xb40 net/netfilter/xt_RATEEST.c:109 [..] xt_check_target+0x283/0x690 net/netfilter/x_tables.c:1019 check_target net/ipv4/netfilter/arp_tables.c:399 [inline] find_check_entry net/ipv4/netfilter/arp_tables.c:422 [inline] translate_table+0x1005/0x1d70 net/ipv4/netfilter/arp_tables.c:572 do_replace net/ipv4/netfilter/arp_tables.c:977 [inline] do_arpt_set_ctl+0x310/0x640 net/ipv4/netfilter/arp_tables.c:1456 Fixes: add67461 ("netfilter: add struct net * to target parameters") Reported-by: syzbot+d7358a458d8a81aee898@syzkaller.appspotmail.com Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Tony Lindgren authored
commit 049226b9 upstream. We must let the USB host idle things properly before we switch to debug UART mode. Otherwise the USB host may never idle after disconnecting devices, and that causes the next enumeration to be flakey. Cc: Jacopo Mondi <jacopo@jmondi.org> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by:
Pavel Machek <pavel@ucw.cz> Fixes: 6d6ce40f ("phy: cpcap-usb: Add CPCAP PMIC USB support") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Tony Lindgren authored
commit 4acb0200 upstream. If musb_mailbox() returns an error, we must still continue to finish configuring the phy. Otherwise the phy state may end up only half initialized, and this can cause the debug serial console to stop working. And this will happen if the usb driver musb controller is not loaded. Let's fix the issue by adding helper for cpcap_usb_try_musb_mailbox(). Fixes: 6d6ce40f ("phy: cpcap-usb: Add CPCAP PMIC USB support") Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Alan Stern authored
commit 2548288b upstream. It turns out that even though endpoints with a maxpacket length of 0 aren't useful for data transfer, the descriptors do serve other purposes. In particular, skipping them will also skip over other class-specific descriptors for classes such as UVC. This unexpected side effect has caused some UVC cameras to stop working. In addition, the USB spec requires that when isochronous endpoint descriptors are present in an interface's altsetting 0 (which is true on some devices), the maxpacket size _must_ be set to 0. Warning about such things seems like a bad idea. This patch updates an earlier commit which would log a warning and skip these endpoint descriptors. Now we only log a warning, and we don't even do that for isochronous endpoints in altsetting 0. We don't need to worry about preventing endpoints with maxpacket = 0 from ever being used for data transfers; usb_submit_urb() already checks for this. Reported-and-tested-by:
Roger Whittaker <Roger.Whittaker@suse.com> Fixes: d482c7bb ("USB: Skip endpoints with 0 maxpacket length") Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2 Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001061040270.1514-100000@iolanthe.rowland.orgSigned-off-by:
-
Dmitry Torokhov authored
commit 18a1b06e upstream. The open method of hiddev handler fails to bring the device out of autosuspend state as was promised in 0361a28d, as it actually has 2 blocks that try to start the transport (call hid_hw_open()) with both being guarded by the "open" counter, so the 2nd block is never executed as the first block increments the counter so it is never at 0 when we check it for the second block. Additionally hiddev_open() was leaving counter incremented on errors, causing the device to never be reopened properly if there was ever an error. Let's fix all of this by factoring out code that creates client structure and powers up the device into a separate function that is being called from usbhid_open() with the "existancelock" being held. Fixes: 0361a28d ("HID: autosuspend support for USB HID") Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Navid Emamdoost authored
commit b8d17e7d upstream. In ath10k_usb_hif_tx_sg the allocated urb should be released if usb_submit_urb fails. Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Navid Emamdoost authored
commit a2cdd074 upstream. In rtl8xxxu_submit_int_urb if usb_submit_urb fails the allocated urb should be released. Signed-off-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
-
Navid Emamdoost authored
commit 0e62395d upstream. In bfad_im_get_stats if bfa_port_get_stats fails, allocated memory needs to be released. Link: https://lore.kernel.org/r/20190910234417.22151-1-navid.emamdoost@gmail.comSigned-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Navid Emamdoost authored
commit db8fd2cd upstream. In mwifiex_pcie_alloc_cmdrsp_buf, a new skb is allocated which should be released if mwifiex_map_pci_memory() fails. The release is added. Fixes: fc331460 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe") Signed-off-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
-
Ganapathi Bhat authored
commit 3d94a4a8 upstream. mwifiex_process_country_ie() function parse elements of bss descriptor in beacon packet. When processing WLAN_EID_COUNTRY element, there is no upper limit check for country_ie_len before calling memcpy. The destination buffer domain_info->triplet is an array of length MWIFIEX_MAX_TRIPLET_802_11D(83). The remote attacker can build a fake AP with the same ssid as real AP, and send malicous beacon packet with long WLAN_EID_COUNTRY elemen (country_ie_len > 83). Attacker can force STA connect to fake AP on a different channel. When the victim STA connects to fake AP, will trigger the heap buffer overflow. Fix this by checking for length and if found invalid, don not connect to the AP. This fix addresses CVE-2019-14895. Reported-by:
huangwen <huangwenabc@gmail.com> Signed-off-by:
-
Sudip Mukherjee authored
commit 273f6329 upstream. If the serial device is disconnected and reconnected, it re-enumerates properly but does not link it. fwiw, linking means just saving the port index, so allow it always as there is no harm in saving the same value again even if it tries to relink with the same port. Fixes: fb2b9001 ("tty: link tty and port before configuring it as console") Reported-by:
Kenneth R. Crudup <kenny@panix.com> Signed-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191227174434.12057-1-sudipm.mukherjee@gmail.comSigned-off-by:
-
Sudip Mukherjee authored
commit fb2b9001 upstream. There seems to be a race condition in tty drivers and I could see on many boot cycles a NULL pointer dereference as tty_init_dev() tries to do 'tty->port->itty = tty' even though tty->port is NULL. 'tty->port' will be set by the driver and if the driver has not yet done it before we open the tty device we can get to this situation. By adding some extra debug prints, I noticed that: 6.650130: uart_add_one_port 6.663849: register_console 6.664846: tty_open 6.674391: tty_init_dev 6.675456: tty_port_link_device uart_add_one_port() registers the console, as soon as it registers, the userspace tries to use it and that leads to tty_open() but uart_add_one_port() has not yet done tty_port_link_device() and so tty->port is not yet configured when control reaches tty_init_dev(). Further look into the code and tty_port_link_device() is done by uart_add_one_port(). After registering the console uart_add_one_port() will call tty_port_register_device_attr_serdev() and tty_port_link_device() is called from this. Call add tty_port_link_device() before uart_configure_port() is done and add a check in tty_port_link_device() so that it only links the port if it has not been done yet. Suggested-by:
Jiri Slaby <jslaby@suse.com> Signed-off-by:
-
Punit Agrawal authored
commit c5ee0b31 upstream. Serdev sub-system claims all ACPI serial devices that are not already initialised. As a result, no device node is created for serial ports on certain boards such as the Apollo Lake based UP2. This has the unintended consequence of not being able to raise the login prompt via serial connection. Introduce a blacklist to reject ACPI serial devices that should not be claimed by serdev sub-system. Add the peripheral ids for Intel HS UART to the blacklist to bring back serial port on SoCs carrying them. Cc: stable@vger.kernel.org Signed-off-by:
Punit Agrawal <punit1.agrawal@toshiba.co.jp> Acked-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Johan Hovold <johan@kernel.org> Cc: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191219100345.911093-1-punit1.agrawal@toshiba.co.jpSigned-off-by:
-
Michael Straube authored
commit 58dcc5bf upstream. This device was added to the stand-alone driver on github. Add it to the staging driver as well. Link: https://github.com/lwfinger/rtl8188eu/commit/b9b537aa25a8Signed-off-by:
Michael Straube <straube.linux@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191228143725.24455-1-straube.linux@gmail.comSigned-off-by:
-
Ian Abbott authored
commit a9d3a9ce upstream. The Advantech PCI-1713 has 32 analog input channels, but an incorrect bit-mask in the definition of the `PCI171X_MUX_CHANH(x)` and PCI171X_MUX_CHANL(x)` macros is causing channels 16 to 31 to be aliases of channels 0 to 15. Change the bit-mask value from 0xf to 0xff to fix it. Note that the channel numbers will have been range checked already, so the bit-mask isn't really needed. Fixes: 92c65e55 ("staging: comedi: adv_pci1710: define the mux control register bits") Reported-by:
Dmytro Fil <monkdaf@gmail.com> Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20191227170054.32051-1-abbotti@mev.co.ukSigned-off-by:
-
Paul Cercueil authored
commit c80d0f44 upstream. The IRQ handler was passed a pointer to a struct dma_controller, but the argument was then casted to a pointer to a struct musb_dma_controller. Fixes: 427c4f33 ("usb: struct device - replace bus_id with dev_name(), dev_set_name()") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Cc: stable@vger.kernel.org Signed-off-by:
Bin Liu <b-liu@ti.com> Link: https://lore.kernel.org/r/20191216161844.772-2-b-liu@ti.comSigned-off-by:
-
Paul Cercueil authored
commit 96a0c128 upstream. The pullup may be already enabled before the driver is initialized. This happens for instance on JZ4740. It has to be disabled at init time, as we cannot guarantee that a gadget driver will be bound to the UDC. Signed-off-by:
-
Tony Lindgren authored
commit 5fbf7a25 upstream. When disconnected as USB B-device, suspend interrupt should come before diconnect interrupt, because the DP/DM pins are shorter than the VBUS/GND pins on the USB connectors. But we sometimes get a suspend interrupt after disconnect interrupt. In that case we have devctl set to 99 with VBUS still valid and musb_pm_runtime_check_session() wrongly thinks we have an active session. We have no other interrupts after disconnect coming in this case at least with the omap2430 glue. Let's fix the issue by checking the interrupt status again with delayed work for the devctl 99 case. In the suspend after disconnect case the devctl session bit has cleared by then and musb can idle. For a typical USB B-device connect case we just continue with normal interrupts. Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core") Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Daniele Palmas authored
commit 2438c3a1 upstream. Telit FN980 flashing device 0x1bc7/0x9010 requires zero packet to be sent if out data size is is equal to the endpoint max size. Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> [ johan: switch operands in conditional ] Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Malcolm Priestley authored
commit c0bcf9f3 upstream. intfdata will contain stale pointer when the device is detached after failed initialization when referenced in vt6656_disconnect Provide driver access to it here and NULL it. Cc: stable <stable@vger.kernel.org> Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Link: https://lore.kernel.org/r/6de448d7-d833-ef2e-dd7b-3ef9992fee0e@gmail.comSigned-off-by:
-
