1. 04 May, 2016 10 commits
  2. 20 Apr, 2016 30 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.14.67 · 2ba48045
      Greg Kroah-Hartman authored
      2ba48045
    • Greg Kroah-Hartman's avatar
      Revert "usb: hub: do not clear BOS field during reset device" · 5d2be8b0
      Greg Kroah-Hartman authored
      commit e5bdfd50 upstream.
      
      This reverts commit d8f00cd6.
      
      Tony writes:
      
      This upstream commit is causing an oops:
      d8f00cd6 ("usb: hub: do not clear BOS field during reset device")
      
      This patch has already been included in several -stable kernels.  Here
      are the affected kernels:
      4.5.0-rc4 (current git)
      4.4.2
      4.3.6 (currently in review)
      4.1.18
      3.18.27
      3.14.61
      
      How to reproduce the problem:
      Boot kernel with slub debugging enabled (otherwise memory corruption
      will cause random oopses later instead of immediately)
      Plug in USB 3.0 disk to xhci USB 3.0 port
      dd if=/dev/sdc of=/dev/null bs=65536
      (where /dev/sdc is the USB 3.0 disk)
      Unplug USB cable while dd is still going
      Oops is immediate:
      Reported-by: default avatarTony Battersby <tonyb@cybernetics.com>
      Cc: Du, Changbin <changbin.du@intel.com>
      Cc: Roger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d2be8b0
    • Vladis Dronov's avatar
      usbvision: fix crash on detecting device with invalid configuration · 5cdf1343
      Vladis Dronov authored
      commit fa52bd50 upstream.
      
      The usbvision driver crashes when a specially crafted usb device with invalid
      number of interfaces or endpoints is detected. This fix adds checks that the
      device has proper configuration expected by the driver.
      Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5cdf1343
    • Alexey Khoroshilov's avatar
      usbvision: fix leak of usb_dev on failure paths in usbvision_probe() · 6b89cc72
      Alexey Khoroshilov authored
      commit afd270d1 upstream.
      
      There is no usb_put_dev() on failure paths in usbvision_probe().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b89cc72
    • Nicolai Hähnle's avatar
      drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older) · 4e8190cf
      Nicolai Hähnle authored
      [Backport of upstream commit f6ff4f67, with
       an additional NULL pointer guard that is required for kernels 3.17 and older.
      
       To be precise, any kernel that does *not* have commit 954605ca "drm/radeon:
       use common fence implementation for fences, v4" requires this additional
       NULL pointer guard.]
      
      An arbitrary amount of time can pass between spin_unlock and
      radeon_fence_wait_any, so we need to ensure that nobody frees the
      fences from under us.
      
      Based on the analogous fix for amdgpu.
      Signed-off-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      Reviewed-by: Christian König <christian.koenig@amd.com> (v1 + fix)
      Tested-by: default avatarLutz Euler <lutz.euler@freenet.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e8190cf
    • Greg Kroah-Hartman's avatar
      Revert bad backport of "drm/radeon: hold reference to fences in radeon_sa_bo_new" · 8ac960dc
      Greg Kroah-Hartman authored
      This reverts commit 50353e6f, which is
      commit f6ff4f67 upstream, as it was
      backported to the 3.14-stable tree incorrectly.  A correct fix will
      happen next.
      Reported-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      8ac960dc
    • Alan Stern's avatar
      HID: usbhid: fix inconsistent reset/resume/reset-resume behavior · 0caa9766
      Alan Stern authored
      commit 972e6a99 upstream.
      
      The usbhid driver has inconsistently duplicated code in its post-reset,
      resume, and reset-resume pathways.
      
      	reset-resume doesn't check HID_STARTED before trying to
      	restart the I/O queues.
      
      	resume fails to clear the HID_SUSPENDED flag if HID_STARTED
      	isn't set.
      
      	resume calls usbhid_restart_queues() with usbhid->lock held
      	and the others call it without holding the lock.
      
      The first item in particular causes a problem following a reset-resume
      if the driver hasn't started up its I/O.  URB submission fails because
      usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
      
      This patch fixes the problem by creating a new subroutine,
      hid_restart_io(), to carry out all the common activities.  It also
      adds some checks that were missing in the original code:
      
      	After a reset, there's no need to clear any halted endpoints.
      
      	After a resume, if a reset is pending there's no need to
      	restart any I/O until the reset is finished.
      
      	After a resume, if the interrupt-IN endpoint is halted there's
      	no need to submit the input URB until the halt has been
      	cleared.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarDaniel Fraga <fragabr@gmail.com>
      Tested-by: default avatarDaniel Fraga <fragabr@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0caa9766
    • Peter Zijlstra's avatar
      perf: Cure event->pending_disable race · 1931344f
      Peter Zijlstra authored
      commit 28a967c3 upstream.
      
      Because event_sched_out() checks event->pending_disable _before_
      actually disabling the event, it can happen that the event fires after
      it checks but before it gets disabled.
      
      This would leave event->pending_disable set and the queued irq_work
      will try and process it.
      
      However, if the event trigger was during schedule(), the event might
      have been de-scheduled by the time the irq_work runs, and
      perf_event_disable_local() will fail.
      
      Fix this by checking event->pending_disable _after_ we call
      event->pmu->del(). This depends on the latter being a compiler
      barrier, such that the compiler does not lift the load and re-creates
      the problem.
      Tested-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: dvyukov@google.com
      Cc: eranian@google.com
      Cc: oleg@redhat.com
      Cc: panand@redhat.com
      Cc: sasha.levin@oracle.com
      Cc: vince@deater.net
      Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1931344f
    • Theodore Ts'o's avatar
      ext4: add lockdep annotations for i_data_sem · ebe9c20f
      Theodore Ts'o authored
      commit daf647d2 upstream.
      
      With the internal Quota feature, mke2fs creates empty quota inodes and
      quota usage tracking is enabled as soon as the file system is mounted.
      Since quotacheck is no longer preallocating all of the blocks in the
      quota inode that are likely needed to be written to, we are now seeing
      a lockdep false positive caused by needing to allocate a quota block
      from inside ext4_map_blocks(), while holding i_data_sem for a data
      inode.  This results in this complaint:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&ei->i_data_sem);
                                      lock(&s->s_dquot.dqio_mutex);
                                      lock(&ei->i_data_sem);
         lock(&s->s_dquot.dqio_mutex);
      
      Google-Bug-Id: 27907753
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebe9c20f
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer · 8fab4f52
      Yoshihiro Shimoda authored
      commit 6490865c upstream.
      
      This patch adds a code to surely disable TX IRQ of the pipe before
      starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
      may happen in rare cases when DMAC is used.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fab4f52
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() · df6e6cc0
      Yoshihiro Shimoda authored
      commit 894f2fc4 upstream.
      
      When unexpected situation happened (e.g. tx/rx irq happened while
      DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
      pointer dereference like the followings:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 80000007 [#1] SMP ARM
      Modules linked in: usb_f_acm u_serial g_serial libcomposite
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
      Hardware name: Generic R8A7790 (Flattened Device Tree)
      task: c0729c00 ti: c0724000 task.ti: c0724000
      PC is at 0x0
      LR is at usbhsf_pkt_handler+0xac/0x118
      pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
      sp : c0725db8  ip : 00000000  fp : c0725df4
      r10: 00000001  r9 : 00000193  r8 : ef3ccab4
      r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
      r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
      
      This patch adds a condition to avoid the dereference.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df6e6cc0
    • Michal Kazior's avatar
      mac80211: fix unnecessary frame drops in mesh fwding · 8c755b42
      Michal Kazior authored
      commit cf440128 upstream.
      
      The ieee80211_queue_stopped() expects hw queue
      number but it was given raw WMM AC number instead.
      
      This could cause frame drops and problems with
      traffic in some cases - most notably if driver
      doesn't map AC numbers to queue numbers 1:1 and
      uses ieee80211_stop_queues() and
      ieee80211_wake_queue() only without ever calling
      ieee80211_wake_queues().
      
      On ath10k it was possible to hit this problem in
      the following case:
      
        1. wlan0 uses queue 0
           (ath10k maps queues per vif)
        2. offchannel uses queue 15
        3. queues 1-14 are unused
        4. ieee80211_stop_queues()
        5. ieee80211_wake_queue(q=0)
        6. ieee80211_wake_queue(q=15)
           (other queues are not woken up because both
            driver and mac80211 know other queues are
            unused)
        7. ieee80211_rx_h_mesh_fwding()
        8. ieee80211_select_queue_80211() returns 2
        9. ieee80211_queue_stopped(q=2) returns true
       10. frame is dropped (oops!)
      
      Fixes: d3c1597b ("mac80211: fix forwarded mesh frame queue mapping")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c755b42
    • Thadeu Lima de Souza Cascardo's avatar
      ip6_tunnel: set rtnl_link_ops before calling register_netdevice · 59cc645a
      Thadeu Lima de Souza Cascardo authored
      [ Upstream commit b6ee376c ]
      
      When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
      before ip6_tnl_create2 is called. When register_netdevice is called, there
      is no linkinfo attribute in the NEWLINK message because of that.
      
      Setting rtnl_link_ops before calling register_netdevice fixes that.
      
      Fixes: 0b112457 ("ip6tnl: add support of link creation via rtnl")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59cc645a
    • Haishuang Yan's avatar
      ipv6: l2tp: fix a potential issue in l2tp_ip6_recv · 80f9b401
      Haishuang Yan authored
      [ Upstream commit be447f30 ]
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80f9b401
    • Haishuang Yan's avatar
      ipv4: l2tp: fix a potential issue in l2tp_ip_recv · 0123df63
      Haishuang Yan authored
      [ Upstream commit 5745b823 ]
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0123df63
    • Bjørn Mork's avatar
      qmi_wwan: add "D-Link DWM-221 B1" device id · 50474f1f
      Bjørn Mork authored
      [ Upstream commit e84810c7 ]
      
      Thomas reports:
      "Windows:
      
      00 diagnostics
      01 modem
      02 at-port
      03 nmea
      04 nic
      
      Linux:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7e19 Rev=02.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
      Reported-by: default avatarThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50474f1f
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · 2d6c3459
      Guillaume Nault authored
      [ Upstream commit 1f461dcd ]
      
      Let channels hold a reference on their network namespace.
      Some channel types, like ppp_async and ppp_synctty, can have their
      userspace controller running in a different namespace. Therefore they
      can't rely on them to preclude their netns from being removed from
      under them.
      
      ==================================================================
      BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
      addr ffff880064e217e0
      Read of size 8 by task syz-executor/11581
      =============================================================================
      BUG net_namespace (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
      [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
      [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
      [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
      [<     inline     >] slab_alloc kernel/mm/slub.c:2574
      [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
      [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
      [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
      [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
      [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
      [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
      [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
      [<     inline     >] copy_process kernel/kernel/fork.c:1274
      [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
      [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
      [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
      [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
      
      INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
      [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
      [<     inline     >] slab_free kernel/mm/slub.c:2805
      [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
      [<     inline     >] net_free kernel/net/core/net_namespace.c:341
      [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
      [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
      [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
      [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
      [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
      [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
      INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
      flags=0x5fffc0000004080
      INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
      
      CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
       ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
       ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
      Call Trace:
       [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
       [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
       [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
       [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
       [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
       [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
       [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
       [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
       [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
       [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
       [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
       [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
       [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
       [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
       [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
       [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
       [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
       [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
       [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
       [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
       [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
       [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
       [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
       [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
       [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
       [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
       [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
       [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
       [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
       [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
       [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
       [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
       [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
       [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
       [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
       [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
       [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
       [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
       [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
       [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
       [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
      Memory state around the buggy address:
       ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d6c3459
    • Paolo Abeni's avatar
      ipv4: fix broadcast packets reception · 821710a0
      Paolo Abeni authored
      [ Upstream commit ad0ea198 ]
      
      Currently, ingress ipv4 broadcast datagrams are dropped since,
      in udp_v4_early_demux(), ip_check_mc_rcu() is invoked even on
      bcast packets.
      
      This patch addresses the issue, invoking ip_check_mc_rcu()
      only for mcast packets.
      
      Fixes: 6e540309 ("ipv4/udp: Verify multicast group is ours in upd_v4_early_demux()")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      821710a0
    • Manish Chopra's avatar
      qlge: Fix receive packets drop. · fd87f95c
      Manish Chopra authored
      [ Upstream commit 2c9a266a ]
      
      When running small packets [length < 256 bytes] traffic, packets were
      being dropped due to invalid data in those packets which were
      delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
      ensures copying latest and updated data into skb from the receive buffer.
      Signed-off-by: default avatarSony Chacko <sony.chacko@qlogic.com>
      Signed-off-by: default avatarManish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd87f95c
    • Arnd Bergmann's avatar
      ath9k: fix buffer overrun for ar9287 · d805f291
      Arnd Bergmann authored
      [ Upstream commit 83d6f1f1 ]
      
      Code that was added back in 2.6.38 has an obvious overflow
      when accessing a static array, and at the time it was added
      only a code comment was put in front of it as a reminder
      to have it reviewed properly.
      
      This has not happened, but gcc-6 now points to the specific
      overflow:
      
      drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
      drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
           maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
      
      It turns out that the correct array length exists in the local
      'intercepts' variable of this function, so we can just use that
      instead of hardcoding '4', so this patch changes all three
      instances to use that variable. The other two instances were
      already correct, but it's more consistent this way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 940cd2c1 ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d805f291
    • Arnd Bergmann's avatar
      farsync: fix off-by-one bug in fst_add_one · 26a628c5
      Arnd Bergmann authored
      [ Upstream commit e725a66c ]
      
      gcc-6 finds an out of bounds access in the fst_add_one function
      when calculating the end of the mmio area:
      
      drivers/net/wan/farsync.c: In function 'fst_add_one':
      drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]
       #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                                           ^
      include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'
        __builtin_offsetof(a, b)
                           ^
      drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'
       #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                           ^~~~~~~~
      drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'
                                        + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);
                                          ^~~~~~~~~~
      
      The warning is correct, but not critical because this appears
      to be a write-only variable that is set by each WAN driver but
      never accessed afterwards.
      
      I'm taking the minimal fix here, using the correct pointer by
      pointing 'mem_end' to the last byte inside of the register area
      as all other WAN drivers do, rather than the first byte outside of
      it. An alternative would be to just remove the mem_end member
      entirely.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26a628c5
    • Arnaldo Carvalho de Melo's avatar
      net: Fix use after free in the recvmmsg exit path · 902b916d
      Arnaldo Carvalho de Melo authored
      [ Upstream commit 34b88a68 ]
      
      The syzkaller fuzzer hit the following use-after-free:
      
        Call Trace:
         [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
         [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
         [<     inline     >] SYSC_recvmmsg net/socket.c:2281
         [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
         [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
        arch/x86/entry/entry_64.S:185
      
      And, as Dmitry rightly assessed, that is because we can drop the
      reference and then touch it when the underlying recvmsg calls return
      some packets and then hit an error, which will make recvmmsg to set
      sock->sk->sk_err, oops, fix it.
      Reported-and-Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Fixes: a2e27255 ("net: Introduce recvmmsg socket syscall")
      http://lkml.kernel.org/r/20160122211644.GC2470@redhat.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      902b916d
    • Sergei Shtylyov's avatar
      sh_eth: fix NULL pointer dereference in sh_eth_ring_format() · 3b199517
      Sergei Shtylyov authored
      [ Upstream commit c1b7fca6 ]
      
      In a low memory situation, if netdev_alloc_skb() fails on a first RX ring
      loop iteration  in sh_eth_ring_format(), 'rxdesc' is still NULL.  Avoid
      kernel oops by adding the 'rxdesc' check after the loop.
      Reported-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b199517
    • Bill Sommerfeld's avatar
      udp6: fix UDP/IPv6 encap resubmit path · 1a660207
      Bill Sommerfeld authored
      [ Upstream commit 59dca1d8 ]
      
      IPv4 interprets a negative return value from a protocol handler as a
      request to redispatch to a new protocol.  In contrast, IPv6 interprets a
      negative value as an error, and interprets a positive value as a request
      for redispatch.
      
      UDP for IPv6 was unaware of this difference.  Change __udp6_lib_rcv() to
      return a positive value for redispatch.  Note that the socket's
      encap_rcv hook still needs to return a negative value to request
      dispatch, and in the case of IPv6 packets, adjust IP6CB(skb)->nhoff to
      identify the byte containing the next protocol.
      Signed-off-by: default avatarBill Sommerfeld <wsommerfeld@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a660207
    • Oliver Neukum's avatar
      usbnet: cleanup after bind() in probe() · 7f3216be
      Oliver Neukum authored
      [ Upstream commit 1666984c ]
      
      In case bind() works, but a later error forces bailing
      in probe() in error cases work and a timer may be scheduled.
      They must be killed. This fixes an error case related to
      the double free reported in
      http://www.spinics.net/lists/netdev/msg367669.html
      and needs to go on top of Linus' fix to cdc-ncm.
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f3216be
    • Bjørn Mork's avatar
      cdc_ncm: toggle altsetting to force reset before setup · 3aec7e09
      Bjørn Mork authored
      [ Upstream commit 48906f62 ]
      
      Some devices will silently fail setup unless they are reset first.
      This is necessary even if the data interface is already in
      altsetting 0, which it will be when the device is probed for the
      first time.  Briefly toggling the altsetting forces a function
      reset regardless of the initial state.
      
      This fixes a setup problem observed on a number of Huawei devices,
      appearing to operate in NTB-32 mode even if we explicitly set them
      to NTB-16 mode.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3aec7e09
    • Florian Westphal's avatar
      ipv6: re-enable fragment header matching in ipv6_find_hdr · 369b2427
      Florian Westphal authored
      [ Upstream commit 5d150a98 ]
      
      When ipv6_find_hdr is used to find a fragment header
      (caller specifies target NEXTHDR_FRAGMENT) we erronously return
      -ENOENT for all fragments with nonzero offset.
      
      Before commit 9195bb8e, when target was specified, we did not
      enter the exthdr walk loop as nexthdr == target so this used to work.
      
      Now we do (so we can skip empty route headers). When we then stumble upon
      a frag with nonzero frag_off we must return -ENOENT ("header not found")
      only if the caller did not specifically request NEXTHDR_FRAGMENT.
      
      This allows nfables exthdr expression to match ipv6 fragments, e.g. via
      
      nft add rule ip6 filter input frag frag-off gt 0
      
      Fixes: 9195bb8e ("ipv6: improve ipv6_find_hdr() to skip empty routing headers")
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      369b2427
    • Xin Long's avatar
      sctp: lack the check for ports in sctp_v6_cmp_addr · 893ec5b7
      Xin Long authored
      [ Upstream commit 40b4f0fd ]
      
      As the member .cmp_addr of sctp_af_inet6, sctp_v6_cmp_addr should also check
      the port of addresses, just like sctp_v4_cmp_addr, cause it's invoked by
      sctp_cmp_addr_exact().
      
      Now sctp_v6_cmp_addr just check the port when two addresses have different
      family, and lack the port check for two ipv6 addresses. that will make
      sctp_hash_cmp() cannot work well.
      
      so fix it by adding ports comparison in sctp_v6_cmp_addr().
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      893ec5b7
    • Diego Viola's avatar
      net: jme: fix suspend/resume on JMC260 · 1911c25b
      Diego Viola authored
      [ Upstream commit ee50c130 ]
      
      The JMC260 network card fails to suspend/resume because the call to
      jme_start_irq() was too early, moving the call to jme_start_irq() after
      the call to jme_reset_link() makes it work.
      
      Prior this change suspend/resume would fail unless /sys/power/pm_async=0
      was explicitly specified.
      
      Relevant bug report: https://bugzilla.kernel.org/show_bug.cgi?id=112351Signed-off-by: default avatarDiego Viola <diego.viola@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1911c25b
    • Boris Ostrovsky's avatar
      xen/events: Mask a moving irq · f808d9a0
      Boris Ostrovsky authored
      commit ff1e22e7 upstream.
      
      Moving an unmasked irq may result in irq handler being invoked on both
      source and target CPUs.
      
      With 2-level this can happen as follows:
      
      On source CPU:
              evtchn_2l_handle_events() ->
                  generic_handle_irq() ->
                      handle_edge_irq() ->
                         eoi_pirq():
                             irq_move_irq(data);
      
                             /***** WE ARE HERE *****/
      
                             if (VALID_EVTCHN(evtchn))
                                 clear_evtchn(evtchn);
      
      If at this moment target processor is handling an unrelated event in
      evtchn_2l_handle_events()'s loop it may pick up our event since target's
      cpu_evtchn_mask claims that this event belongs to it *and* the event is
      unmasked and still pending. At the same time, source CPU will continue
      executing its own handle_edge_irq().
      
      With FIFO interrupt the scenario is similar: irq_move_irq() may result
      in a EVTCHNOP_unmask hypercall which, in turn, may make the event
      pending on the target CPU.
      
      We can avoid this situation by moving and clearing the event while
      keeping event masked.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f808d9a0