- 01 Nov, 2017 15 commits
-
-
Sabrina Dubroca authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 62b982ee ] If we try to delete the same tunnel twice, the first delete operation does a lookup (l2tp_tunnel_get), finds the tunnel, calls l2tp_tunnel_delete, which queues it for deletion by l2tp_tunnel_del_work. The second delete operation also finds the tunnel and calls l2tp_tunnel_delete. If the workqueue has already fired and started running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the same tunnel a second time, and try to free the socket again. Add a dead flag to prevent firing the workqueue twice. Then we can remove the check of queue_work's result that was meant to prevent that race but doesn't. Reproducer: ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 local 192.168.0.2 remote 192.168.0.1 encap udp udp_sport 5000 udp_dport 6000 ip l2tp add session name l2tp1 tunnel_id 3000 session_id 1000 peer_session_id 2000 ip link set l2tp1 up ip l2tp del tunnel tunnel_id 3000 ip l2tp del tunnel tunnel_id 3000 Fixes: f8ccac0e ("l2tp: put tunnel socket release on a workqueue") Reported-by:
Jianlin Shi <jishi@redhat.com> Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Acked-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ridge Kennedy authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 12d656af ] While destroying a network namespace that contains a L2TP tunnel a "BUG: scheduling while atomic" can be observed. Enabling lockdep shows that this is happening because l2tp_exit_net() is calling l2tp_tunnel_closeall() (via l2tp_tunnel_delete()) from within an RCU critical section. l2tp_exit_net() takes rcu_read_lock_bh() << list_for_each_entry_rcu() >> l2tp_tunnel_delete() l2tp_tunnel_closeall() __l2tp_session_unhash() synchronize_rcu() << Illegal inside RCU critical section >> BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, pid: 86, name: kworker/u16:2 INFO: lockdep is turned off. CPU: 2 PID: 86 Comm: kworker/u16:2 Tainted: G W O 4.4.6-at1 #2 Hardware name: Xen HVM domU, BIOS 4.6.1-xs125300 05/09/2016 Workqueue: netns cleanup_net 0000000000000000 ffff880202417b90 ffffffff812b0013 ffff880202410ac0 ffffffff81870de8 ffff880202417bb8 ffffffff8107aee8 ffffffff81870de8 0000000000000c51 0000000000000000 ffff880202417be0 ffffffff8107b024 Call Trace: [<ffffffff812b0013>] dump_stack+0x85/0xc2 [<ffffffff8107aee8>] ___might_sleep+0x148/0x240 [<ffffffff8107b024>] __might_sleep+0x44/0x80 [<ffffffff810b21bd>] synchronize_sched+0x2d/0xe0 [<ffffffff8109be6d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8105c7bb>] ? __local_bh_enable_ip+0x6b/0xc0 [<ffffffff816a1b00>] ? _raw_spin_unlock_bh+0x30/0x40 [<ffffffff81667482>] __l2tp_session_unhash+0x172/0x220 [<ffffffff81667397>] ? __l2tp_session_unhash+0x87/0x220 [<ffffffff8166888b>] l2tp_tunnel_closeall+0x9b/0x140 [<ffffffff81668c74>] l2tp_tunnel_delete+0x14/0x60 [<ffffffff81668dd0>] l2tp_exit_net+0x110/0x270 [<ffffffff81668d5c>] ? l2tp_exit_net+0x9c/0x270 [<ffffffff815001c3>] ops_exit_list.isra.6+0x33/0x60 [<ffffffff81501166>] cleanup_net+0x1b6/0x280 ... This bug can easily be reproduced with a few steps: $ sudo unshare -n bash # Create a shell in a new namespace # ip link set lo up # ip addr add 127.0.0.1 dev lo # ip l2tp add tunnel remote 127.0.0.1 local 127.0.0.1 tunnel_id 1 \ peer_tunnel_id 1 udp_sport 50000 udp_dport 50000 # ip l2tp add session name foo tunnel_id 1 session_id 1 \ peer_session_id 1 # ip link set foo up # exit # Exit the shell, in turn exiting the namespace $ dmesg ... [942121.089216] BUG: scheduling while atomic: kworker/u16:3/13872/0x00000200 ... To fix this, move the call to l2tp_tunnel_closeall() out of the RCU critical section, and instead call it from l2tp_tunnel_del_work(), which is running from the l2tp_wq workqueue. Fixes: 2b551c6e ("l2tp: close sessions before initiating tunnel delete") Signed-off-by:
Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz> Acked-by:
-
Alexey Kodanev authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 36f6ee22 ] When running LTP IPsec tests, KASan might report: BUG: KASAN: use-after-free in vti_tunnel_xmit+0xeee/0xff0 [ip_vti] Read of size 4 at addr ffff880dc6ad1980 by task swapper/0/0 ... Call Trace: <IRQ> dump_stack+0x63/0x89 print_address_description+0x7c/0x290 kasan_report+0x28d/0x370 ? vti_tunnel_xmit+0xeee/0xff0 [ip_vti] __asan_report_load4_noabort+0x19/0x20 vti_tunnel_xmit+0xeee/0xff0 [ip_vti] ? vti_init_net+0x190/0x190 [ip_vti] ? save_stack_trace+0x1b/0x20 ? save_stack+0x46/0xd0 dev_hard_start_xmit+0x147/0x510 ? icmp_echo.part.24+0x1f0/0x210 __dev_queue_xmit+0x1394/0x1c60 ... Freed by task 0: save_stack_trace+0x1b/0x20 save_stack+0x46/0xd0 kasan_slab_free+0x70/0xc0 kmem_cache_free+0x81/0x1e0 kfree_skbmem+0xb1/0xe0 kfree_skb+0x75/0x170 kfree_skb_list+0x3e/0x60 __dev_queue_xmit+0x1298/0x1c60 dev_queue_xmit+0x10/0x20 neigh_resolve_output+0x3a8/0x740 ip_finish_output2+0x5c0/0xe70 ip_finish_output+0x4ba/0x680 ip_output+0x1c1/0x3a0 xfrm_output_resume+0xc65/0x13d0 xfrm_output+0x1e4/0x380 xfrm4_output_finish+0x5c/0x70 Can be fixed if we get skb->len before dst_output(). Fixes: b9959fd3 ("vti: switch to new ip tunnel code") Fixes: 22e1b23d ("vti6: Support inter address family tunneling.") Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
-
Meng Xu authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 02388bf8 ] In isdn_ppp_write(), the header (i.e., protobuf) of the buffer is fetched twice from userspace. The first fetch is used to peek at the protocol of the message and reset the huptimer if necessary; while the second fetch copies in the whole buffer. However, given that buf resides in userspace memory, a user process can race to change its memory content across fetches. By doing so, we can either avoid resetting the huptimer for any type of packets (by first setting proto to PPP_LCP and later change to the actual type) or force resetting the huptimer for LCP packets. This patch changes this double-fetch behavior into two single fetches decided by condition (lp->isdn_device < 0 || lp->isdn_channel <0). A more detailed discussion can be found at https://marc.info/?l=linux-kernel&m=150586376926123&w=2Signed-off-by:
Meng Xu <mengxu.gatech@gmail.com> Signed-off-by:
-
Yonghong Song authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit ec9dd352 ] This patch fixes a bug exhibited by the following scenario: 1. fd1 = perf_event_open with attr.config = ID1 2. attach bpf program prog1 to fd1 3. fd2 = perf_event_open with attr.config = ID1 <this will be successful> 4. user program closes fd2 and prog1 is detached from the tracepoint. 5. user program with fd1 does not work properly as tracepoint no output any more. The issue happens at step 4. Multiple perf_event_open can be called successfully, but only one bpf prog pointer in the tp_event. In the current logic, any fd release for the same tp_event will free the tp_event->prog. The fix is to free tp_event->prog only when the closing fd corresponds to the one which registered the program. Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Willem de Bruijn authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 008ba2a1 ] Packet socket bind operations must hold the po->bind_lock. This keeps po->running consistent with whether the socket is actually on a ptype list to receive packets. fanout_add unbinds a socket and its packet_rcv/tpacket_rcv call, then binds the fanout object to receive through packet_rcv_fanout. Make it hold the po->bind_lock when testing po->running and rebinding. Else, it can race with other rebind operations, such as that in packet_set_ring from packet_rcv to tpacket_rcv. Concurrent updates can result in a socket being added to a fanout group twice, causing use-after-free KASAN bug reports, among others. Reported independently by both trinity and syzkaller. Verified that the syzkaller reproducer passes after this patch. Fixes: dc99f600 ("packet: Add fanout support.") Reported-by:
nixioaming <nixiaoming@huawei.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Christian Lamparter authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit f5595606 ] This patch is pretty much a carbon copy of commit 3079c652 ("caif: Fix napi poll list corruption") with "caif" replaced by "emac". The commit d75b1ade ("net: less interrupt masking in NAPI") breaks emac. It is now required that if the entire budget is consumed when poll returns, the napi poll_list must remain empty. However, like some other drivers emac tries to do a last-ditch check and if there is more work it will call napi_reschedule and then immediately process some of this new work. Should the entire budget be consumed while processing such new work then we will violate the new caller contract. This patch fixes this by not touching any work when we reschedule in emac. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Xin Long authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 76cc0d32 ] Now in ip6gre_header before packing the ipv6 header, it skb_push t->hlen which only includes encap_hlen + tun_hlen. It means greh and inner header would be over written by ipv6 stuff and ipv6h might have no chance to set up. Jianlin found this issue when using remote any on ip6_gre, the packets he captured on gre dev are truncated: 22:50:26.210866 Out ethertype IPv6 (0x86dd), length 120: truncated-ip6 -\ 8128 bytes missing!(flowlabel 0x92f40, hlim 0, next-header Options (0) \ payload length: 8192) ::1:2000:0 > ::1:0:86dd: HBH [trunc] ip-proto-128 \ 8184 It should also skb_push ipv6hdr so that ipv6h points to the right position to set ipv6 stuff up. This patch is to skb_push hlen + sizeof(*ipv6h) and also fix some indents in ip6gre_header. Fixes: c12b395a ("gre: Support GRE over IPv6") Reported-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Subash Abhinov Kasiviswanathan authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit 63ecc3d9 ] While trying an ESP transport mode encryption for UDPv6 packets of datagram size 1436 with MTU 1500, checksum error was observed in the secondary fragment. This error occurs due to the UDP payload checksum being missed out when computing the full checksum for these packets in udp6_hwcsum_outgoing(). Fixes: d39d938c ("ipv6: Introduce udpv6_send_skb()") Signed-off-by:
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by:
-
Edward Cree authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit e67b8a68 ] Neither ___bpf_prog_run nor the JITs accept it. Also adds a new test case. Fixes: 17a52670 ("bpf: verifier (add verifier core)") Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1729105 [ Upstream commit fa5f7b51 ] This code causes a static checker warning because Smatch doesn't trust anything that comes from skb->data. I've reviewed this code and I do think skb->data can be controlled by the user here. The sctp_event_subscribe struct has 13 __u8 fields and we want to see if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range. We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read either before the start of the struct or after the end. This is a very old bug and it's surprising that it would go undetected for so long but my theory is that it just doesn't have a big impact so it would be hard to notice. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Matt Redfearn authored
BugLink: http://bugs.launchpad.net/bugs/1729105 commit 5fdc66e0 upstream. Commit db8466c5 ("MIPS: IRQ Stack: Unwind IRQ stack onto task stack") erroneously set the initial stack pointer of the IRQ stack to a value with a 4 byte alignment. The MIPS32 ABI requires that the minimum stack alignment is 8 byte, and the MIPS64 ABIs(n32/n64) require 16 byte minimum alignment. Fix IRQ_STACK_START such that it leaves space for the dummy stack frame (containing interrupted task kernel stack pointer) while also meeting minimum alignment requirements. Fixes: db8466c5 ("MIPS: IRQ Stack: Unwind IRQ stack onto task stack") Reported-by:
Darius Ivanauskas <dasilt@yahoo.com> Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Aaron Tomlin <atomlin@redhat.com> Cc: Jason A. Donenfeld <jason@zx2c4.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/16760/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Harry Wentland authored
BugLink: http://bugs.launchpad.net/bugs/1729105 commit 6cecdf7a upstream. This makes it possibly for drivers to find the associated mst_port by looking at the payload allocation table. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449514552-10236-3-git-send-email-harry.wentland@amd.comSigned-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Mark Rutland authored
BugLink: http://bugs.launchpad.net/bugs/1729105 commit e88d62cd upstream. As raw_cpu_generic_read() is a plain read from a raw_cpu_ptr() address, it's possible (albeit unlikely) that the compiler will split the access across multiple instructions. In this_cpu_generic_read() we disable preemption but not interrupts before calling raw_cpu_generic_read(). Thus, an interrupt could be taken in the middle of the split load instructions. If a this_cpu_write() or RMW this_cpu_*() op is made to the same variable in the interrupt handling path, this_cpu_read() will return a torn value. For native word types, we can avoid tearing using READ_ONCE(), but this won't work in all cases (e.g. 64-bit types on most 32-bit platforms). This patch reworks this_cpu_generic_read() to use READ_ONCE() where possible, otherwise falling back to disabling interrupts. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Lameter <cl@linux.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Pranith Kumar <bobby.prani@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Signed-off-by:
Tejun Heo <tj@kernel.org> [Mark: backport to v4.4.y] Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 31 Oct, 2017 2 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1721538 Update config after "UBUNTU: SAUCE: remove hv_network_direct driver". Signed-off-by:
-
- 30 Oct, 2017 23 commits
-
-
Marcelo Henrique Cerri authored
BugLink: http://bugs.launchpad.net/bugs/1721538 hv_network_direct is an RDMA driver specific for Azure. Supporting it requires multiple versions of the driver that are selected via userspace. Currently that's only supported in the linux-azure kernel and keeping a single version in the xenial kernel might cause issues when it doesn't match the host OS version. Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> [kleber: adjusted for new abi files path] Signed-off-by:
-
Kai-Heng Feng authored
Like other Plantronics devices, C310 and C520-M do not support sample rate reading. Add them to the sample rate quirk accordingly. BugLink: https://bugs.launchpad.net/bugs/1708499 BugLink: https://bugs.launchpad.net/bugs/1709282Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit 0dcd020b) Signed-off-by:
-
Markus Pargmann authored
BugLink: http://bugs.launchpad.net/bugs/696435 The userspace needs to know when nbd devices are ready for use. Currently no events are created for the userspace which doesn't work for systemd. See the discussion here: https://github.com/systemd/systemd/pull/358 This patch uses a central point to setup the nbd-internal sizes. A ioctl to set a size does not lead to a visible size change. The size of the block device will be kept at 0 until nbd is connected. As soon as it connects, the size will be changed to the real value and a uevent is created. When disconnecting, the blockdevice is set to 0 size and another uevent is generated. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> (cherry picked from commit 37091fdd) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Marcelo Henrique Cerri authored
Ignore: yes Commit "UBUNTU: d/s/m/insert-ubuntu-changes: use full version numbers" wrongly change the behaviour of the "<stop at>" parameter. Change the script to not include the <stop at> version into the target changelog. Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Colin Ian King authored
BugLink: https://launchpad.net/bugs/1718388 io.dev is used as an index into the _devices array and currently the user may pass any unsigned int value into io.dev which can create an out-of-bounds error. Fix this by sanity checking io.dev and returning -EINVAL for out-of-bounds values of io.dev Detected by CoverityScan CID#1456895 ("Untrusted array index read") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Acked-by:
-
Colin Ian King authored
BugLink: https://launchpad.net/bugs/1718388 dev->name is a char array and hence can never be null and so the null checks on dev->name are redundant. Remove them. Detected by CoverityScan CID#1456897, CID#145690 ("Array compared against 0") Signed-off-by:
-
Colin Ian King authored
BugLink: https://launchpad.net/bugs/1718388 sinfo can potentially be null, so add a null check to avoid a null pointer deference on sinfo->info_id. Detected by CoverityScan CID#1456902 ("Dereference before null check") Signed-off-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1722719 This reverts commit fcaa4a07. As noted by Masaki [1], 0x120A + trackpoint will not be used in mass production machines, so remove the ID accordingly. [1] http://www.spinics.net/lists/linux-input/msg53222.htmlSigned-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 66dcdafe) Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-By:
Shrirang Bagul <shrirang.bagul@canonical.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1724836Signed-off-by:
-
Mathias Krause authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 6b32c126 upstream. The alt_max_short() macro in asm/alternative.h does not work as intended, leading to nasty bugs. E.g. alt_max_short("1", "3") evaluates to 3, but alt_max_short("3", "1") evaluates to 1 -- not exactly the maximum of 1 and 3. In fact, I had to learn it the hard way by crashing my kernel in not so funny ways by attempting to make use of the ALTENATIVE_2 macro with alternatives where the first one was larger than the second one. According to [1] and commit dbe4058a ("x86/alternatives: Fix ALTERNATIVE_2 padding generation properly") the right handed side should read "-(-(a < b))" not "-(-(a - b))". Fix that, to make the macro work as intended. While at it, fix up the comments regarding the additional "-", too. It's not about gas' usage of s32 but brain dead logic of having a "true" value of -1 for the < operator ... *sigh* Btw., the one in asm/alternative-asm.h is correct. And, apparently, all current users of ALTERNATIVE_2() pass same sized alternatives, avoiding to hit the bug. [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMaxReviewed-and-tested-by:
Borislav Petkov <bp@suse.de> Fixes: dbe4058a ("x86/alternatives: Fix ALTERNATIVE_2 padding generation properly") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/1507228213-13095-1-git-send-email-minipli@googlemail.comSigned-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 299d7572 upstream. Make sure to reset the USB-console port pointer when console setup fails in order to avoid having the struct usb_serial be prematurely freed by the console code when the device is later disconnected. Fixes: 73e487fd ("[PATCH] USB console: fix disconnection issues") Acked-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit f5d9644c upstream. Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74 series which will by default boot with vid 0x413c and pid's 0x81cf, 0x81d0, 0x81d1, 0x81d2. Signed-off-by:
-
Stefan Bader authored
This reverts commit 66a7f616 in favour of the upstream stable commit. BugLink: https://bugs.launchpad.net/bugs/1724836Signed-off-by:
-
Henryk Heisig authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 837ddc47 upstream. This commit adds support for TP-Link LTE mPCIe module is used in in TP-Link MR200v1, MR6400v1 and v2 routers. Signed-off-by:
Henryk Heisig <hyniu@o2.pl> Signed-off-by:
-
Andreas Engel authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit c496ad83 upstream. Add the USB device id for the ELV TFD500 data logger. Signed-off-by:
Andreas Engel <anen-nospam@gmx.net> Signed-off-by:
-
Jeffrey Chu authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit a6c215e2 upstream. Add CYPRESS_VID vid and CYPRESS_WICED_BT_USB and CYPRESS_WICED_WL_USB device IDs to ftdi_sio driver. Signed-off-by:
Jeffrey Chu <jeffrey.chu@cypress.com> Signed-off-by:
-
Vitaly Mayatskikh authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 95d78c28 upstream. bio_map_user_iov and bio_unmap_user do unbalanced pages refcounting if IO vector has small consecutive buffers belonging to the same page. bio_add_pc_page merges them into one, but the page reference is never dropped. Signed-off-by:
Vitaly Mayatskikh <v.mayatskih@gmail.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Andreas Gruenbacher authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 899f0429 upstream. In the code added to function submit_page_section by commit b1058b98, sdio->bio can currently be NULL when calling dio_bio_submit. This then leads to a NULL pointer access in dio_bio_submit, so check for a NULL bio in submit_page_section before trying to submit it instead. Fixes xfstest generic/250 on gfs2. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Andrew Gabbasov authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit aec17e1e upstream. KASAN enabled configuration reports an error BUG: KASAN: use-after-free in usb_composite_overwrite_options+... [libcomposite] at addr ... Read of size 1 by task ... when some driver is un-bound and then bound again. For example, this happens with FunctionFS driver when "ffs-test" test application is run several times in a row. If the driver has empty manufacturer ID string in initial static data, it is then replaced with generated string. After driver unbinding the generated string is freed, but the driver data still keep that pointer. And if the driver is then bound again, that pointer is re-used for string emptiness check. The fix is to clean up the driver string data upon its unbinding to drop the pointer to freed memory. Fixes: cc2683c3 ("usb: gadget: Provide a default implementation of default manufacturer string") Signed-off-by:
Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit c95072b3 upstream. While line6_probe() may kick off URB for a control MIDI endpoint, the function doesn't clean up it properly at its error path. This results in a leftover URB action that is eventually triggered later and causes an Oops like: general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 0 Comm: swapper/1 Not tainted RIP: 0010:usb_fill_bulk_urb ./include/linux/usb.h:1619 RIP: 0010:line6_start_listen+0x3fe/0x9e0 sound/usb/line6/driver.c:76 Call Trace: <IRQ> line6_data_received+0x1f7/0x470 sound/usb/line6/driver.c:326 __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779 usb_hcd_giveback_urb+0x337/0x420 drivers/usb/core/hcd.c:1845 dummy_timer+0xba9/0x39f0 drivers/usb/gadget/udc/dummy_hcd.c:1965 call_timer_fn+0x2a2/0x940 kernel/time/timer.c:1281 .... Since the whole clean-up procedure is done in line6_disconnect() callback, we can simply call it in the error path instead of open-coding the whole again. It'll fix such an issue automagically. The bug was spotted by syzkaller. Fixes: eedd0e95 ("ALSA: line6: Don't forget to call driver's destructor at error path") Reported-by:
Andrey Konovalov <andreyknvl@google.com> Tested-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 99fee508 upstream. caiaq driver doesn't kill the URB properly at its error path during the probe, which may lead to a use-after-free error later. This patch addresses it. Reported-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 5803b023 upstream. The event handler in the virmidi sequencer code takes a read-lock for the linked list traverse, while it's calling snd_seq_dump_var_event() in the loop. The latter function may expand the user-space data depending on the event type. It eventually invokes copy_from_user(), which might be a potential dead-lock. The sequencer core guarantees that the user-space data is passed only with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it and always takes read-lock(). For avoiding the problem above, this patch introduces rwsem for non-atomic case, while keeping rwlock for atomic case. Also while we're at it: the superfluous irq flags is dropped in snd_virmidi_input_open(). Reported-by:
Jia-Ju Bai <baijiaju1990@163.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1724836 commit 71105998 upstream. There is a potential race window opened at creating and deleting a port via ioctl, as spotted by fuzzing. snd_seq_create_port() creates a port object and returns its pointer, but it doesn't take the refcount, thus it can be deleted immediately by another thread. Meanwhile, snd_seq_ioctl_create_port() still calls the function snd_seq_system_client_ev_port_start() with the created port object that is being deleted, and this triggers use-after-free like: BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1 ============================================================================= BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511 ___slab_alloc+0x425/0x460 __slab_alloc+0x20/0x40 kmem_cache_alloc_trace+0x150/0x190 snd_seq_create_port+0x94/0x9b0 [snd_seq] snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] snd_seq_ioctl+0x40/0x80 [snd_seq] do_vfs_ioctl+0x54b/0xda0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x16/0x75 INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717 __slab_free+0x204/0x310 kfree+0x15f/0x180 port_delete+0x136/0x1a0 [snd_seq] snd_seq_delete_port+0x235/0x350 [snd_seq] snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] snd_seq_ioctl+0x40/0x80 [snd_seq] do_vfs_ioctl+0x54b/0xda0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x16/0x75 Call Trace: [<ffffffff81b03781>] dump_stack+0x63/0x82 [<ffffffff81531b3b>] print_trailer+0xfb/0x160 [<ffffffff81536db4>] object_err+0x34/0x40 [<ffffffff815392d3>] kasan_report.part.2+0x223/0x520 [<ffffffffa07aadf4>] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] [<ffffffff815395fe>] __asan_report_load1_noabort+0x2e/0x30 [<ffffffffa07aadf4>] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] [<ffffffffa07aa8f0>] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq] [<ffffffff8136be50>] ? taskstats_exit+0xbc0/0xbc0 [<ffffffffa07abc5c>] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] [<ffffffffa07abd10>] snd_seq_ioctl+0x40/0x80 [snd_seq] [<ffffffff8136d433>] ? acct_account_cputime+0x63/0x80 [<ffffffff815b515b>] do_vfs_ioctl+0x54b/0xda0 ..... We may fix this in a few different ways, and in this patch, it's fixed simply by taking the refcount properly at snd_seq_create_port() and letting the caller unref the object after use. Also, there is another potential use-after-free by sprintf() call in snd_seq_create_port(), and this is moved inside the lock. This fix covers CVE-2017-15265. Reported-and-tested-by:
Michael23 Yu <ycqzsy@gmail.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
