1. 05 Jul, 2017 15 commits
    • James Hogan's avatar
      MIPS: Avoid accidental raw backtrace · c9c5c35b
      James Hogan authored
      commit 85423636 upstream.
      
      Since commit 81a76d71 ("MIPS: Avoid using unwind_stack() with
      usermode") show_backtrace() invokes the raw backtracer when
      cp0_status & ST0_KSU indicates user mode to fix issues on EVA kernels
      where user and kernel address spaces overlap.
      
      However this is used by show_stack() which creates its own pt_regs on
      the stack and leaves cp0_status uninitialised in most of the code paths.
      This results in the non deterministic use of the raw back tracer
      depending on the previous stack content.
      
      show_stack() deals exclusively with kernel mode stacks anyway, so
      explicitly initialise regs.cp0_status to KSU_KERNEL (i.e. 0) to ensure
      we get a useful backtrace.
      
      Fixes: 81a76d71 ("MIPS: Avoid using unwind_stack() with usermode")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16656/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9c5c35b
    • Julien Grall's avatar
      arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str · 8d87bf7c
      Julien Grall authored
      commit f228b494 upstream.
      
      The loop that browses the array compat_hwcap_str will stop when a NULL
      is encountered, however NULL is missing at the end of array. This will
      lead to overrun until a NULL is found somewhere in the following memory.
      In reality, this works out because the compat_hwcap2_str array tends to
      follow immediately in memory, and that *is* terminated correctly.
      Furthermore, the unsigned int compat_elf_hwcap is checked before
      printing each capability, so we end up doing the right thing because
      the size of the two arrays is less than 32. Still, this is an obvious
      mistake and should be fixed.
      
      Note for backporting: commit 12d11817 ("arm64: Move
      /proc/cpuinfo handling code") moved this code in v4.4. Prior to that
      commit, the same change should be made in arch/arm64/kernel/setup.c.
      
      Fixes: 44b82b77 "arm64: Fix up /proc/cpuinfo"
      Signed-off-by: default avatarJulien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d87bf7c
    • Gao Feng's avatar
      net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev · 3930a417
      Gao Feng authored
      
      [ Upstream commit 9745e362 ]
      
      The register_vlan_device would invoke free_netdev directly, when
      register_vlan_dev failed. It would trigger the BUG_ON in free_netdev
      if the dev was already registered. In this case, the netdev would be
      freed in netdev_run_todo later.
      
      So add one condition check now. Only when dev is not registered, then
      free it directly.
      
      The following is the part coredump when netdev_upper_dev_link failed
      in register_vlan_dev. I removed the lines which are too long.
      
      [  411.237457] ------------[ cut here ]------------
      [  411.237458] kernel BUG at net/core/dev.c:7998!
      [  411.237484] invalid opcode: 0000 [#1] SMP
      [  411.237705]  [last unloaded: 8021q]
      [  411.237718] CPU: 1 PID: 12845 Comm: vconfig Tainted: G            E   4.12.0-rc5+ #6
      [  411.237737] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
      [  411.237764] task: ffff9cbeb6685580 task.stack: ffffa7d2807d8000
      [  411.237782] RIP: 0010:free_netdev+0x116/0x120
      [  411.237794] RSP: 0018:ffffa7d2807dbdb0 EFLAGS: 00010297
      [  411.237808] RAX: 0000000000000002 RBX: ffff9cbeb6ba8fd8 RCX: 0000000000001878
      [  411.237826] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 0000000000000000
      [  411.237844] RBP: ffffa7d2807dbdc8 R08: 0002986100029841 R09: 0002982100029801
      [  411.237861] R10: 0004000100029980 R11: 0004000100029980 R12: ffff9cbeb6ba9000
      [  411.238761] R13: ffff9cbeb6ba9060 R14: ffff9cbe60f1a000 R15: ffff9cbeb6ba9000
      [  411.239518] FS:  00007fb690d81700(0000) GS:ffff9cbebb640000(0000) knlGS:0000000000000000
      [  411.239949] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  411.240454] CR2: 00007f7115624000 CR3: 0000000077cdf000 CR4: 00000000003406e0
      [  411.240936] Call Trace:
      [  411.241462]  vlan_ioctl_handler+0x3f1/0x400 [8021q]
      [  411.241910]  sock_ioctl+0x18b/0x2c0
      [  411.242394]  do_vfs_ioctl+0xa1/0x5d0
      [  411.242853]  ? sock_alloc_file+0xa6/0x130
      [  411.243465]  SyS_ioctl+0x79/0x90
      [  411.243900]  entry_SYSCALL_64_fastpath+0x1e/0xa9
      [  411.244425] RIP: 0033:0x7fb69089a357
      [  411.244863] RSP: 002b:00007ffcd04e0fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
      [  411.245445] RAX: ffffffffffffffda RBX: 00007ffcd04e2884 RCX: 00007fb69089a357
      [  411.245903] RDX: 00007ffcd04e0fd0 RSI: 0000000000008983 RDI: 0000000000000003
      [  411.246527] RBP: 00007ffcd04e0fd0 R08: 0000000000000000 R09: 1999999999999999
      [  411.246976] R10: 000000000000053f R11: 0000000000000202 R12: 0000000000000004
      [  411.247414] R13: 00007ffcd04e1128 R14: 00007ffcd04e2888 R15: 0000000000000001
      [  411.249129] RIP: free_netdev+0x116/0x120 RSP: ffffa7d2807dbdb0
      Signed-off-by: default avatarGao Feng <gfree.wind@vip.163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3930a417
    • Wei Wang's avatar
      decnet: always not take dst->__refcnt when inserting dst into hash table · 316e55aa
      Wei Wang authored
      
      [ Upstream commit 76371d2e ]
      
      In the existing dn_route.c code, dn_route_output_slow() takes
      dst->__refcnt before calling dn_insert_route() while dn_route_input_slow()
      does not take dst->__refcnt before calling dn_insert_route().
      This makes the whole routing code very buggy.
      In dn_dst_check_expire(), dnrt_free() is called when rt expires. This
      makes the routes inserted by dn_route_output_slow() not able to be
      freed as the refcnt is not released.
      In dn_dst_gc(), dnrt_drop() is called to release rt which could
      potentially cause the dst->__refcnt to be dropped to -1.
      In dn_run_flush(), dst_free() is called to release all the dst. Again,
      it makes the dst inserted by dn_route_output_slow() not able to be
      released and also, it does not wait on the rcu and could potentially
      cause crash in the path where other users still refer to this dst.
      
      This patch makes sure both input and output path do not take
      dst->__refcnt before calling dn_insert_route() and also makes sure
      dnrt_free()/dst_free() is called when removing dst from the hash table.
      The only difference between those 2 calls is that dnrt_free() waits on
      the rcu while dst_free() does not.
      Signed-off-by: default avatarWei Wang <weiwan@google.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      316e55aa
    • Xin Long's avatar
      ipv6: fix calling in6_ifa_hold incorrectly for dad work · 00e32559
      Xin Long authored
      
      [ Upstream commit f8a894b2 ]
      
      Now when starting the dad work in addrconf_mod_dad_work, if the dad work
      is idle and queued, it needs to hold ifa.
      
      The problem is there's one gap in [1], during which if the pending dad work
      is removed elsewhere. It will miss to hold ifa, but the dad word is still
      idea and queue.
      
              if (!delayed_work_pending(&ifp->dad_work))
                      in6_ifa_hold(ifp);
                          <--------------[1]
              mod_delayed_work(addrconf_wq, &ifp->dad_work, delay);
      
      An use-after-free issue can be caused by this.
      
      Chen Wei found this issue when WARN_ON(!hlist_unhashed(&ifp->addr_lst)) in
      net6_ifa_finish_destroy was hit because of it.
      
      As Hannes' suggestion, this patch is to fix it by holding ifa first in
      addrconf_mod_dad_work, then calling mod_delayed_work and putting ifa if
      the dad_work is already in queue.
      
      Note that this patch did not choose to fix it with:
      
        if (!mod_delayed_work(delay))
                in6_ifa_hold(ifp);
      
      As with it, when delay == 0, dad_work would be scheduled immediately, all
      addrconf_mod_dad_work(0) callings had to be moved under ifp->lock.
      Reported-by: default avatarWei Chen <weichen@redhat.com>
      Suggested-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      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>
      00e32559
    • WANG Cong's avatar
      igmp: add a missing spin_lock_init() · e3fa173e
      WANG Cong authored
      
      [ Upstream commit b4846fc3 ]
      
      Andrey reported a lockdep warning on non-initialized
      spinlock:
      
       INFO: trying to register non-static key.
       the code is fine but needs lockdep annotation.
       turning off the locking correctness validator.
       CPU: 1 PID: 4099 Comm: a.out Not tainted 4.12.0-rc6+ #9
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       Call Trace:
        __dump_stack lib/dump_stack.c:16
        dump_stack+0x292/0x395 lib/dump_stack.c:52
        register_lock_class+0x717/0x1aa0 kernel/locking/lockdep.c:755
        ? 0xffffffffa0000000
        __lock_acquire+0x269/0x3690 kernel/locking/lockdep.c:3255
        lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
        __raw_spin_lock_bh ./include/linux/spinlock_api_smp.h:135
        _raw_spin_lock_bh+0x36/0x50 kernel/locking/spinlock.c:175
        spin_lock_bh ./include/linux/spinlock.h:304
        ip_mc_clear_src+0x27/0x1e0 net/ipv4/igmp.c:2076
        igmpv3_clear_delrec+0xee/0x4f0 net/ipv4/igmp.c:1194
        ip_mc_destroy_dev+0x4e/0x190 net/ipv4/igmp.c:1736
      
      We miss a spin_lock_init() in igmpv3_add_delrec(), probably
      because previously we never use it on this code path. Since
      we already unlink it from the global mc_tomb list, it is
      probably safe not to acquire this spinlock here. It does not
      harm to have it although, to avoid conditional locking.
      
      Fixes: c38b7d32 ("igmp: acquire pmc lock for ip_mc_clear_src()")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3fa173e
    • WANG Cong's avatar
      igmp: acquire pmc lock for ip_mc_clear_src() · 2f8e1d05
      WANG Cong authored
      
      [ Upstream commit c38b7d32 ]
      
      Andrey reported a use-after-free in add_grec():
      
              for (psf = *psf_list; psf; psf = psf_next) {
      		...
                      psf_next = psf->sf_next;
      
      where the struct ip_sf_list's were already freed by:
      
       kfree+0xe8/0x2b0 mm/slub.c:3882
       ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
       ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
       ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
       inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
       sock_release+0x8d/0x1e0 net/socket.c:597
       sock_close+0x16/0x20 net/socket.c:1072
      
      This happens because we don't hold pmc->lock in ip_mc_clear_src()
      and a parallel mr_ifc_timer timer could jump in and access them.
      
      The RCU lock is there but it is merely for pmc itself, this
      spinlock could actually ensure we don't access them in parallel.
      
      Thanks to Eric and Long for discussion on this bug.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Xin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-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>
      2f8e1d05
    • Jia-Ju Bai's avatar
      net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx · e1f1dea9
      Jia-Ju Bai authored
      
      [ Upstream commit f146e872 ]
      
      The kernel may sleep under a rcu read lock in cfpkt_create_pfx, and the
      function call path is:
      cfcnfg_linkup_rsp (acquire the lock by rcu_read_lock)
        cfctrl_linkdown_req
          cfpkt_create
            cfpkt_create_pfx
              alloc_skb(GFP_KERNEL) --> may sleep
      cfserl_receive (acquire the lock by rcu_read_lock)
        cfpkt_split
          cfpkt_create_pfx
            alloc_skb(GFP_KERNEL) --> may sleep
      
      There is "in_interrupt" in cfpkt_create_pfx to decide use "GFP_KERNEL" or
      "GFP_ATOMIC". In this situation, "GFP_KERNEL" is used because the function
      is called under a rcu read lock, instead in interrupt.
      
      To fix it, only "GFP_ATOMIC" is used in cfpkt_create_pfx.
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1f1dea9
    • Krister Johansen's avatar
      Fix an intermittent pr_emerg warning about lo becoming free. · 721ee8db
      Krister Johansen authored
      
      [ Upstream commit f186ce61 ]
      
      It looks like this:
      
      Message from syslogd@flamingo at Apr 26 00:45:00 ...
       kernel:unregister_netdevice: waiting for lo to become free. Usage count = 4
      
      They seem to coincide with net namespace teardown.
      
      The message is emitted by netdev_wait_allrefs().
      
      Forced a kdump in netdev_run_todo, but found that the refcount on the lo
      device was already 0 at the time we got to the panic.
      
      Used bcc to check the blocking in netdev_run_todo.  The only places
      where we're off cpu there are in the rcu_barrier() and msleep() calls.
      That behavior is expected.  The msleep time coincides with the amount of
      time we spend waiting for the refcount to reach zero; the rcu_barrier()
      wait times are not excessive.
      
      After looking through the list of callbacks that the netdevice notifiers
      invoke in this path, it appears that the dst_dev_event is the most
      interesting.  The dst_ifdown path places a hold on the loopback_dev as
      part of releasing the dev associated with the original dst cache entry.
      Most of our notifier callbacks are straight-forward, but this one a)
      looks complex, and b) places a hold on the network interface in
      question.
      
      I constructed a new bcc script that watches various events in the
      liftime of a dst cache entry.  Note that dst_ifdown will take a hold on
      the loopback device until the invalidated dst entry gets freed.
      
      [      __dst_free] on DST: ffff883ccabb7900 IF tap1008300eth0 invoked at 1282115677036183
          __dst_free
          rcu_nocb_kthread
          kthread
          ret_from_fork
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      721ee8db
    • Mateusz Jurczyk's avatar
      decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb · 80f5fba8
      Mateusz Jurczyk authored
      
      [ Upstream commit dd0da17b ]
      
      Verify that the length of the socket buffer is sufficient to cover the
      nlmsghdr structure before accessing the nlh->nlmsg_len field for further
      input sanitization. If the client only supplies 1-3 bytes of data in
      sk_buff, then nlh->nlmsg_len remains partially uninitialized and
      contains leftover memory from the corresponding kernel allocation.
      Operating on such data may result in indeterminate evaluation of the
      nlmsg_len < sizeof(*nlh) expression.
      
      The bug was discovered by a runtime instrumentation designed to detect
      use of uninitialized memory in the kernel. The patch prevents this and
      other similar tools (e.g. KMSAN) from flagging this behavior in the future.
      Signed-off-by: default avatarMateusz Jurczyk <mjurczyk@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80f5fba8
    • Alexander Potapenko's avatar
      net: don't call strlen on non-terminated string in dev_set_alias() · 0d487bc5
      Alexander Potapenko authored
      
      [ Upstream commit c28294b9 ]
      
      KMSAN reported a use of uninitialized memory in dev_set_alias(),
      which was caused by calling strlcpy() (which in turn called strlen())
      on the user-supplied non-terminated string.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d487bc5
    • Eric Leblond's avatar
      netfilter: synproxy: fix conntrackd interaction · dc818ce5
      Eric Leblond authored
      commit 87e94dbc upstream.
      
      This patch fixes the creation of connection tracking entry from
      netlink when synproxy is used. It was missing the addition of
      the synproxy extension.
      
      This was causing kernel crashes when a conntrack entry created by
      conntrackd was used after the switch of traffic from active node
      to the passive node.
      Signed-off-by: default avatarEric Leblond <eric@regit.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc818ce5
    • Eric Dumazet's avatar
      netfilter: xt_TCPMSS: add more sanity tests on tcph->doff · f4549a69
      Eric Dumazet authored
      commit 2638fd0f upstream.
      
      Denys provided an awesome KASAN report pointing to an use
      after free in xt_TCPMSS
      
      I have provided three patches to fix this issue, either in xt_TCPMSS or
      in xt_tcpudp.c. It seems xt_TCPMSS patch has the smallest possible
      impact.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDenys Fedoryshchenko <nuclearcat@nuclearcat.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4549a69
    • Willem de Bruijn's avatar
      ipv6: release dst on error in ip6_dst_lookup_tail · 51ef22af
      Willem de Bruijn authored
      commit 00ea1cee upstream.
      
      If ip6_dst_lookup_tail has acquired a dst and fails the IPv4-mapped
      check, release the dst before returning an error.
      
      Fixes: ec5e3b0a ("ipv6: Inhibit IPv4-mapped src address on the wire.")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51ef22af
    • Mathias Nyman's avatar
      xhci: fix deadlock at host remove by running watchdog correctly · daa5d1f0
      Mathias Nyman authored
      commit d6169d04 upstream.
      
      If a URB is killed while the host is removed we can end up in a situation
      where the hub thread takes the roothub device lock, and waits for
      the URB to be given back by xhci-hcd, blocking the host remove code.
      
      xhci-hcd tries to stop the endpoint and give back the urb, but can't
      as the host is removed from PCI bus at the same time, preventing the normal
      way of giving back urb.
      
      Instead we need to rely on the stop command timeout function to give back
      the urb. This xhci_stop_endpoint_command_watchdog() timeout function
      used a XHCI_STATE_DYING flag to indicate if the timeout function is already
      running, but later this flag has been taking into use in other places to
      mark that xhci is dying.
      
      Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
      checking that reading from pci state does not return 0xffffffff or that
      host is not halted before trying to stop the endpoint.
      
      This whole area of stopping endpoints, giving back URBs, and the wathdog
      timeout need rework, this fix focuses on solving a specific deadlock
      issue that we can then send to stable before any major rework.
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarHoward Yen <howard_yen@htc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      daa5d1f0
  2. 29 Jun, 2017 17 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.18.59 · 985c6fe6
      Greg Kroah-Hartman authored
      985c6fe6
    • Jason A. Donenfeld's avatar
      mac80211/wpa: use constant time memory comparison for MACs · 6bc55148
      Jason A. Donenfeld authored
      commit 98c67d18 upstream.
      
      Otherwise, we enable all sorts of forgeries via timing attack.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: linux-wireless@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      6bc55148
    • Russell King's avatar
      net: phy: fix marvell phy status reading · 131e696c
      Russell King authored
      commit 898805e0 upstream.
      
      The Marvell driver incorrectly provides phydev->lp_advertising as the
      logical and of the link partner's advert and our advert.  This is
      incorrect - this field is supposed to store the link parter's unmodified
      advertisment.
      
      This allows ethtool to report the correct link partner auto-negotiation
      status.
      
      Fixes: be937f1f ("Marvell PHY m88e1111 driver fix")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      131e696c
    • William Wu's avatar
      usb: gadget: f_fs: avoid out of bounds access on comp_desc · e1957b18
      William Wu authored
      commit b7f73850 upstream.
      
      Companion descriptor is only used for SuperSpeed endpoints,
      if the endpoints are HighSpeed or FullSpeed, the Companion
      descriptor will not allocated, so we can only access it if
      gadget is SuperSpeed.
      
      I can reproduce this issue on Rockchip platform rk3368 SoC
      which supports USB 2.0, and use functionfs for ADB. Kernel
      build with CONFIG_KASAN=y and CONFIG_SLUB_DEBUG=y report
      the following BUG:
      
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x224/0x3a0 at addr ffffffc0601f6509
      Read of size 1 by task swapper/0/0
      ============================================================================
      BUG kmalloc-256 (Not tainted): kasan: bad access detected
      ----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in ffs_func_bind+0x52c/0x99c age=1275 cpu=0 pid=1
      alloc_debug_processing+0x128/0x17c
      ___slab_alloc.constprop.58+0x50c/0x610
      __slab_alloc.isra.55.constprop.57+0x24/0x34
      __kmalloc+0xe0/0x250
      ffs_func_bind+0x52c/0x99c
      usb_add_function+0xd8/0x1d4
      configfs_composite_bind+0x48c/0x570
      udc_bind_to_driver+0x6c/0x170
      usb_udc_attach_driver+0xa4/0xd0
      gadget_dev_desc_UDC_store+0xcc/0x118
      configfs_write_file+0x1a0/0x1f8
      __vfs_write+0x64/0x174
      vfs_write+0xe4/0x200
      SyS_write+0x68/0xc8
      el0_svc_naked+0x24/0x28
      INFO: Freed in inode_doinit_with_dentry+0x3f0/0x7c4 age=1275 cpu=7 pid=247
      ...
      Call trace:
      [<ffffff900808aab4>] dump_backtrace+0x0/0x230
      [<ffffff900808acf8>] show_stack+0x14/0x1c
      [<ffffff90084ad420>] dump_stack+0xa0/0xc8
      [<ffffff90082157cc>] print_trailer+0x188/0x198
      [<ffffff9008215948>] object_err+0x3c/0x4c
      [<ffffff900821b5ac>] kasan_report+0x324/0x4dc
      [<ffffff900821aa38>] __asan_load1+0x24/0x50
      [<ffffff90089eb750>] ffs_func_set_alt+0x224/0x3a0
      [<ffffff90089d3760>] composite_setup+0xdcc/0x1ac8
      [<ffffff90089d7394>] android_setup+0x124/0x1a0
      [<ffffff90089acd18>] _setup+0x54/0x74
      [<ffffff90089b6b98>] handle_ep0+0x3288/0x4390
      [<ffffff90089b9b44>] dwc_otg_pcd_handle_out_ep_intr+0x14dc/0x2ae4
      [<ffffff90089be85c>] dwc_otg_pcd_handle_intr+0x1ec/0x298
      [<ffffff90089ad680>] dwc_otg_pcd_irq+0x10/0x20
      [<ffffff9008116328>] handle_irq_event_percpu+0x124/0x3ac
      [<ffffff9008116610>] handle_irq_event+0x60/0xa0
      [<ffffff900811af30>] handle_fasteoi_irq+0x10c/0x1d4
      [<ffffff9008115568>] generic_handle_irq+0x30/0x40
      [<ffffff90081159b4>] __handle_domain_irq+0xac/0xdc
      [<ffffff9008080e9c>] gic_handle_irq+0x64/0xa4
      ...
      Memory state around the buggy address:
        ffffffc0601f6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffffffc0601f6480: 00 00 00 00 00 00 00 00 00 00 06 fc fc fc fc fc
       >ffffffc0601f6500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                             ^
        ffffffc0601f6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffffffc0601f6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
      ==================================================================
      Signed-off-by: default avatarWilliam Wu <william.wu@rock-chips.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Cc: Jerry Zhang <zhangjerry@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1957b18
    • Michael Ellerman's avatar
      powerpc/slb: Force a full SLB flush when we insert for a bad EA · 668e0da8
      Michael Ellerman authored
      [Note this patch is not upstream. The bug fix was fixed differently in
      upstream prior to the bug being identified.]
      
      The SLB miss handler calls slb_allocate_realmode() in order to create an
      SLB entry for the faulting address. At the very start of that function
      we check that the faulting Effective Address (EA) is less than
      PGTABLE_RANGE (ignoring the region), ie. is it an address which could
      possibly fit in the virtual address space.
      
      For an EA which fails that test, we branch out of line (to label 8), but
      we still go on to create an SLB entry for the address. The SLB entry we
      create has a VSID of 0, which means it will never match anything in the
      hash table and so can't actually translate to a physical address.
      
      However that SLB entry will be inserted in the SLB, and so needs to be
      managed properly like any other SLB entry. In particular we need to
      insert the SLB entry in the SLB cache, so that it will be flushed when
      the process is descheduled.
      
      And that is where the bugs begin. The first bug is that slb_finish_load()
      uses cr7 to decide if it should insert the SLB entry into the SLB cache.
      When we come from the invalid EA case we don't set cr7, it just has some
      junk value from userspace. So we may or may not insert the SLB entry in
      the SLB cache. If we fail to insert it, we may then incorrectly leave it
      in the SLB when the process is descheduled.
      
      The second bug is that even if we do happen to add the entry to the SLB
      cache, we do not have enough bits in the SLB cache to remember the full
      ESID value for very large EAs.
      
      For example if a process branches to 0x788c545a18000000, that results in
      a 256MB SLB entry with an ESID of 0x788c545a1. But each entry in the SLB
      cache is only 32-bits, meaning we truncate the ESID to 0x88c545a1. This
      has the same effect as the first bug, we incorrectly leave the SLB entry
      in the SLB when the process is descheduled.
      
      When a process accesses an invalid EA it results in a SEGV signal being
      sent to the process, which typically results in the process being
      killed. Process death isn't instantaneous however, the process may catch
      the SEGV signal and continue somehow, or the kernel may start writing a
      core dump for the process, either of which means it's possible for the
      process to be preempted while its processing the SEGV but before it's
      been killed.
      
      If that happens, when the process is scheduled back onto the CPU we will
      allocate a new SLB entry for the NIP, which will insert a second entry
      into the SLB for the bad EA. Because we never flushed the original
      entry, due to either bug one or two, we now have two SLB entries that
      match the same EA.
      
      If another access is made to that EA, either by the process continuing
      after catching the SEGV, or by a second process accessing the same bad
      EA on the same CPU, we will trigger an SLB multi-hit machine check
      exception. This has been observed happening in the wild.
      
      The fix is when we hit the invalid EA case, we mark the SLB cache as
      being full. This causes us to not insert the truncated ESID into the SLB
      cache, and means when the process is switched out we will flush the
      entire SLB. Note that this works both for the original fault and for a
      subsequent call to slb_allocate_realmode() from switch_slb().
      
      Because we mark the SLB cache as full, it doesn't really matter what
      value is in cr7, but rather than leaving it as something random we set
      it to indicate the address was a kernel address. That also skips the
      attempt to insert it in the SLB cache which is a nice side effect.
      
      Another way to fix the bug would be to make the entries in the SLB cache
      wider, so that we don't truncate the ESID. However this would be a more
      intrusive change as it alters the size and layout of the paca.
      
      This bug was fixed in upstream by commit f0f558b1 ("powerpc/mm:
      Preserve CFAR value on SLB miss caused by access to bogus address"),
      which changed the way we handle a bad EA entirely removing this bug in
      the process.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      668e0da8
    • Joël Esponde's avatar
      mtd: spi-nor: fix spansion quad enable · 2eb4011c
      Joël Esponde authored
      commit 807c1625 upstream.
      
      With the S25FL127S nor flash part, each writing to the configuration
      register takes hundreds of ms. During that  time, no more accesses to
      the flash should be done (even reads).
      
      This commit adds a wait loop after the register writing until the flash
      finishes its work.
      
      This issue could make rootfs mounting fail when the latter was done too
      much closely to this quad enable bit setting step. And in this case, a
      driver as UBIFS may try to recover the filesystem and may broke it
      completely.
      Signed-off-by: default avatarJoël Esponde <joel.esponde@honeywell.com>
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2eb4011c
    • Tobias Wolf's avatar
      of: Add check to of_scan_flat_dt() before accessing initial_boot_params · db89d5c7
      Tobias Wolf authored
      commit 3ec75441 upstream.
      
      An empty __dtb_start to __dtb_end section might result in
      initial_boot_params being null for arch/mips/ralink. This showed that the
      boot process hangs indefinitely in of_scan_flat_dt().
      Signed-off-by: default avatarTobias Wolf <dev-NTEO@vplace.de>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14605/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db89d5c7
    • David Howells's avatar
      rxrpc: Fix several cases where a padded len isn't checked in ticket decode · 9c3a8a0f
      David Howells authored
      commit 5f2f9765 upstream.
      
      This fixes CVE-2017-7482.
      
      When a kerberos 5 ticket is being decoded so that it can be loaded into an
      rxrpc-type key, there are several places in which the length of a
      variable-length field is checked to make sure that it's not going to
      overrun the available data - but the data is padded to the nearest
      four-byte boundary and the code doesn't check for this extra.  This could
      lead to the size-remaining variable wrapping and the data pointer going
      over the end of the buffer.
      
      Fix this by making the various variable-length data checks use the padded
      length.
      Reported-by: default avatar石磊 <shilei-c@360.cn>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.c.dionne@auristor.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c3a8a0f
    • Nicholas Bellinger's avatar
      target: Fix kref->refcount underflow in transport_cmd_finish_abort · 0b7db7b0
      Nicholas Bellinger authored
      commit 73d4e580 upstream.
      
      This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
      when a fabric driver drops it's second reference from below the
      target_core_tmr.c based callers of transport_cmd_finish_abort().
      
      Recently with the conversion of kref to refcount_t, this bug was
      manifesting itself as:
      
      [705519.601034] refcount_t: underflow; use-after-free.
      [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
      [705539.719111] ------------[ cut here ]------------
      [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51
      
      Since the original kref atomic_t based kref_put() didn't check for
      underflow and only invoked the final callback when zero was reached,
      this bug did not manifest in practice since all se_cmd memory is
      using preallocated tags.
      
      To address this, go ahead and propigate the existing return from
      transport_put_cmd() up via transport_cmd_finish_abort(), and
      change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
      callers to only do their local target_put_sess_cmd() if necessary.
      Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Tested-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b7db7b0
    • Daniel Drake's avatar
      Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list · 90e149d0
      Daniel Drake authored
      commit 817ae460 upstream.
      
      Without this quirk, the touchpad is not responsive on this product, with
      the following message repeated in the logs:
      
       psmouse serio1: bad data from KBC - timeout
      
      Add it to the notimeout list alongside other similar Fujitsu laptops.
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90e149d0
    • Naveen N. Rao's avatar
      powerpc/kprobes: Pause function_graph tracing during jprobes handling · 96ed79b5
      Naveen N. Rao authored
      commit a9f8553e upstream.
      
      This fixes a crash when function_graph and jprobes are used together.
      This is essentially commit 237d28db ("ftrace/jprobes/x86: Fix
      conflict between jprobes and function graph tracing"), but for powerpc.
      
      Jprobes breaks function_graph tracing since the jprobe hook needs to use
      jprobe_return(), which never returns back to the hook, but instead to
      the original jprobe'd function. The solution is to momentarily pause
      function_graph tracing before invoking the jprobe hook and re-enable it
      when returning back to the original jprobe'd function.
      
      Fixes: 6794c782 ("powerpc64: port of the function graph tracer")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96ed79b5
    • Eric W. Biederman's avatar
      signal: Only reschedule timers on signals timers have sent · 0ddaca0a
      Eric W. Biederman authored
      commit 57db7e4a upstream.
      
      Thomas Gleixner  wrote:
      > The CRIU support added a 'feature' which allows a user space task to send
      > arbitrary (kernel) signals to itself. The changelog says:
      >
      >   The kernel prevents sending of siginfo with positive si_code, because
      >   these codes are reserved for kernel.  I think we can allow a task to
      >   send such a siginfo to itself.  This operation should not be dangerous.
      >
      > Quite contrary to that claim, it turns out that it is outright dangerous
      > for signals with info->si_code == SI_TIMER. The following code sequence in
      > a user space task allows to crash the kernel:
      >
      >    id = timer_create(CLOCK_XXX, ..... signo = SIGX);
      >    timer_set(id, ....);
      >    info->si_signo = SIGX;
      >    info->si_code = SI_TIMER:
      >    info->_sifields._timer._tid = id;
      >    info->_sifields._timer._sys_private = 2;
      >    rt_[tg]sigqueueinfo(..., SIGX, info);
      >    sigemptyset(&sigset);
      >    sigaddset(&sigset, SIGX);
      >    rt_sigtimedwait(sigset, info);
      >
      > For timers based on CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID this
      > results in a kernel crash because sigwait() dequeues the signal and the
      > dequeue code observes:
      >
      >   info->si_code == SI_TIMER && info->_sifields._timer._sys_private != 0
      >
      > which triggers the following callchain:
      >
      >  do_schedule_next_timer() -> posix_cpu_timer_schedule() -> arm_timer()
      >
      > arm_timer() executes a list_add() on the timer, which is already armed via
      > the timer_set() syscall. That's a double list add which corrupts the posix
      > cpu timer list. As a consequence the kernel crashes on the next operation
      > touching the posix cpu timer list.
      >
      > Posix clocks which are internally implemented based on hrtimers are not
      > affected by this because hrtimer_start() can handle already armed timers
      > nicely, but it's a reliable way to trigger the WARN_ON() in
      > hrtimer_forward(), which complains about calling that function on an
      > already armed timer.
      
      This problem has existed since the posix timer code was merged into
      2.5.63. A few releases earlier in 2.5.60 ptrace gained the ability to
      inject not just a signal (which linux has supported since 1.0) but the
      full siginfo of a signal.
      
      The core problem is that the code will reschedule in response to
      signals getting dequeued not just for signals the timers sent but
      for other signals that happen to a si_code of SI_TIMER.
      
      Avoid this confusion by testing to see if the queued signal was
      preallocated as all timer signals are preallocated, and so far
      only the timer code preallocates signals.
      
      Move the check for if a timer needs to be rescheduled up into
      collect_signal where the preallocation check must be performed,
      and pass the result back to dequeue_signal where the code reschedules
      timers.   This makes it clear why the code cares about preallocated
      timers.
      Reported-by: default avatarThomas Gleixner <tglx@linutronix.de>
      History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
      Reference: 66dd34ad ("signal: allow to send any siginfo to itself")
      Reference: 1669ce53 ("Add PTRACE_GETSIGINFO and PTRACE_SETSIGINFO")
      Fixes: db8b50ba ("[PATCH] POSIX clocks & timers")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ddaca0a
    • Pavel Shilovsky's avatar
      CIFS: Improve readdir verbosity · 5290a58f
      Pavel Shilovsky authored
      commit dcd87838 upstream.
      
      Downgrade the loglevel for SMB2 to prevent filling the log
      with messages if e.g. readdir was interrupted. Also make SMB2
      and SMB1 codepaths do the same logging during readdir.
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5290a58f
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Preserve userspace HTM state properly · 0b423dab
      Paul Mackerras authored
      commit 46a704f8 upstream.
      
      If userspace attempts to call the KVM_RUN ioctl when it has hardware
      transactional memory (HTM) enabled, the values that it has put in the
      HTM-related SPRs TFHAR, TFIAR and TEXASR will get overwritten by
      guest values.  To fix this, we detect this condition and save those
      SPR values in the thread struct, and disable HTM for the task.  If
      userspace goes to access those SPRs or the HTM facility in future,
      a TM-unavailable interrupt will occur and the handler will reload
      those SPRs and re-enable HTM.
      
      If userspace has started a transaction and suspended it, we would
      currently lose the transactional state in the guest entry path and
      would almost certainly get a "TM Bad Thing" interrupt, which would
      cause the host to crash.  To avoid this, we detect this case and
      return from the KVM_RUN ioctl with an EINVAL error, with the KVM
      exit reason set to KVM_EXIT_FAIL_ENTRY.
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b423dab
    • Ilya Matveychikov's avatar
      lib/cmdline.c: fix get_options() overflow while parsing ranges · 4d6142de
      Ilya Matveychikov authored
      commit a91e0f68 upstream.
      
      When using get_options() it's possible to specify a range of numbers,
      like 1-100500.  The problem is that it doesn't track array size while
      calling internally to get_range() which iterates over the range and
      fills the memory with numbers.
      
      Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.comSigned-off-by: default avatarIlya V. Matveychikov <matvejchikov@gmail.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d6142de
    • NeilBrown's avatar
      autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL · 75735be7
      NeilBrown authored
      commit 9fa4eb8e upstream.
      
      If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL ioctl,
      autofs4_d_automount() will return
      
         ERR_PTR(status)
      
      with that status to follow_automount(), which will then dereference an
      invalid pointer.
      
      So treat a positive status the same as zero, and map to ENOENT.
      
      See comment in systemd src/core/automount.c::automount_send_ready().
      
      Link: http://lkml.kernel.org/r/871sqwczx5.fsf@notabene.neil.brown.nameSigned-off-by: default avatarNeilBrown <neilb@suse.com>
      Cc: Ian Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75735be7
    • Kees Cook's avatar
      fs/exec.c: account for argv/envp pointers · 2dff2164
      Kees Cook authored
      commit 98da7d08 upstream.
      
      When limiting the argv/envp strings during exec to 1/4 of the stack limit,
      the storage of the pointers to the strings was not included.  This means
      that an exec with huge numbers of tiny strings could eat 1/4 of the stack
      limit in strings and then additional space would be later used by the
      pointers to the strings.
      
      For example, on 32-bit with a 8MB stack rlimit, an exec with 1677721
      single-byte strings would consume less than 2MB of stack, the max (8MB /
      4) amount allowed, but the pointers to the strings would consume the
      remaining additional stack space (1677721 * 4 == 6710884).
      
      The result (1677721 + 6710884 == 8388605) would exhaust stack space
      entirely.  Controlling this stack exhaustion could result in
      pathological behavior in setuid binaries (CVE-2017-1000365).
      
      [akpm@linux-foundation.org: additional commenting from Kees]
      Fixes: b6a2fea3 ("mm: variable length argument support")
      Link: http://lkml.kernel.org/r/20170622001720.GA32173@beastSigned-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Qualys Security Advisory <qsa@qualys.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2dff2164
  3. 26 Jun, 2017 8 commits