1. 07 Jun, 2016 40 commits
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · c57d15c3
      Guillaume Nault authored
      commit 1f461dcd upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      c57d15c3
    • Manish Chopra's avatar
      qlge: Fix receive packets drop. · fb7d23cb
      Manish Chopra authored
      commit 2c9a266a upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      fb7d23cb
    • Arnd Bergmann's avatar
      ath9k: fix buffer overrun for ar9287 · d6a8ef9f
      Arnd Bergmann authored
      commit 83d6f1f1 upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      d6a8ef9f
    • Arnd Bergmann's avatar
      farsync: fix off-by-one bug in fst_add_one · 4d882b64
      Arnd Bergmann authored
      commit e725a66c upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      4d882b64
    • Arnaldo Carvalho de Melo's avatar
      net: Fix use after free in the recvmmsg exit path · 8ba9ba1a
      Arnaldo Carvalho de Melo authored
      commit 34b88a68 upstream.
      
      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>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      8ba9ba1a
    • Sergei Shtylyov's avatar
      sh_eth: fix NULL pointer dereference in sh_eth_ring_format() · 0babba1b
      Sergei Shtylyov authored
      commit c1b7fca6 upstream.
      
      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>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      0babba1b
    • Bill Sommerfeld's avatar
      udp6: fix UDP/IPv6 encap resubmit path · 952bca89
      Bill Sommerfeld authored
      commit 59dca1d8 upstream.
      
      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>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      952bca89
    • Oliver Neukum's avatar
      usbnet: cleanup after bind() in probe() · cfa74bdc
      Oliver Neukum authored
      commit 1666984c upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      cfa74bdc
    • Bjrn Mork's avatar
      cdc_ncm: toggle altsetting to force reset before setup · 13eec5c1
      Bjrn Mork authored
      commit 48906f62 upstream.
      
      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>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      13eec5c1
    • Florian Westphal's avatar
      ipv6: re-enable fragment header matching in ipv6_find_hdr · abcb7fb8
      Florian Westphal authored
      commit 5d150a98 upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      abcb7fb8
    • Xin Long's avatar
      sctp: lack the check for ports in sctp_v6_cmp_addr · 9ad2f2e8
      Xin Long authored
      commit 40b4f0fd upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      9ad2f2e8
    • Diego Viola's avatar
      net: jme: fix suspend/resume on JMC260 · 6bd21b4a
      Diego Viola authored
      commit ee50c130 upstream.
      
      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 avatarWilly Tarreau <w@1wt.eu>
      6bd21b4a
    • Takashi Iwai's avatar
      ALSA: timer: Use mod_timer() for rearming the system timer · 0e57779a
      Takashi Iwai authored
      commit 4a07083e upstream.
      
      ALSA system timer backend stops the timer via del_timer() without sync
      and leaves del_timer_sync() at the close instead.  This is because of
      the restriction by the design of ALSA timer: namely, the stop callback
      may be called from the timer handler, and calling the sync shall lead
      to a hangup.  However, this also triggers a kernel BUG() when the
      timer is rearmed immediately after stopping without sync:
       kernel BUG at kernel/time/timer.c:966!
       Call Trace:
        <IRQ>
        [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
        [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
        [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
        [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
        [<ffffffff81296b72>] call_timer_fn+0x162/0x520
        [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
        [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
        ....
      
      It's the place where add_timer() checks the pending timer.  It's clear
      that this may happen after the immediate restart without sync in our
      cases.
      
      So, the workaround here is just to use mod_timer() instead of
      add_timer().  This looks like a band-aid fix, but it's a right move,
      as snd_timer_interrupt() takes care of the continuous rearm of timer.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      0e57779a
    • Helge Deller's avatar
      parisc: Fix kernel crash with reversed copy_from_user() · 247ed0d3
      Helge Deller authored
      commit ef72f311 upstream.
      
      The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
      crash on parisc if the parameters for copy_from_user were reversed
      ("illegal reversed copy_to_user" testcase).
      
      Fix this potential crash by checking the fault handler if the faulting
      address is in the exception table.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      247ed0d3
    • Helge Deller's avatar
      parisc: Avoid function pointers for kernel exception routines · ac6a8eb7
      Helge Deller authored
      commit e3893027 upstream.
      
      We want to avoid the kernel module loader to create function pointers
      for the kernel fixup routines of get_user() and put_user(). Changing
      the external reference from function type to int type fixes this.
      
      This unbreaks exception handling for get_user() and put_user() when
      called from a kernel module.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      ac6a8eb7
    • Guenter Roeck's avatar
      hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated · 1c6a2c4c
      Guenter Roeck authored
      commit 3c2e2266 upstream.
      
      arm:pxa_defconfig can result in the following crash if the max1111 driver
      is not instantiated.
      
      Unhandled fault: page domain fault (0x01b) at 0x00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: : 1b [#1] PREEMPT ARM
      Modules linked in:
      CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680 #10
      Hardware name: SHARP Akita
      Workqueue: events sharpsl_charge_toggle
      task: c390a000 ti: c391e000 task.ti: c391e000
      PC is at max1111_read_channel+0x20/0x30
      LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
      pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
      ...
      [<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
      					(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)
      [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
      					(spitzpm_read_devdata+0x5c/0xc4)
      [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
      					(sharpsl_check_battery_temp+0x78/0x110)
      [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
      					(sharpsl_charge_toggle+0x48/0x110)
      [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
      					(process_one_work+0x14c/0x48c)
      [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
      [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
      [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)
      
      This can occur because the SPI controller driver (SPI_PXA2XX) is built as
      module and thus not necessarily loaded. While building SPI_PXA2XX into the
      kernel would make the problem disappear, it appears prudent to ensure that
      the driver is instantiated before accessing its data structures.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      1c6a2c4c
    • Andi Kleen's avatar
      perf/x86/intel: Fix PEBS data source interpretation on Nehalem/Westmere · 750fc132
      Andi Kleen authored
      commit e17dc653 upstream.
      
      Jiri reported some time ago that some entries in the PEBS data source table
      in perf do not agree with the SDM. We investigated and the bits
      changed for Sandy Bridge, but the SDM was not updated.
      
      perf already implements the bits correctly for Sandy Bridge
      and later. This patch patches it up for Nehalem and Westmere.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: jolsa@kernel.org
      Link: http://lkml.kernel.org/r/1456871124-15985-1-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      750fc132
    • Thomas Gleixner's avatar
      sched/cputime: Fix steal time accounting vs. CPU hotplug · 0579a127
      Thomas Gleixner authored
      commit e9532e69 upstream.
      
      On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time
      value over CPU down and up. So after the CPU comes up again the delta
      calculation in steal_account_process_tick() wreckages itself due to the
      unsigned math:
      
      	 u64 steal = paravirt_steal_clock(smp_processor_id());
      
      	 steal -= this_rq()->prev_steal_time;
      
      So if steal is smaller than rq->prev_steal_time we end up with an insane large
      value which then gets added to rq->prev_steal_time, resulting in a permanent
      wreckage of the accounting. As a consequence the per CPU stats in /proc/stat
      become stale.
      
      Nice trick to tell the world how idle the system is (100%) while the CPU is
      100% busy running tasks. Though we prefer realistic numbers.
      
      None of the accounting values which use a previous value to account for
      fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity
      check for prev_irq_time and prev_steal_time_rq, but that sanity check solely
      deals with clock warps and limits the /proc/stat visible wreckage. The
      prev_time values are still wrong.
      
      Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Cc: <stable@vger.kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Glauber Costa <glommer@parallels.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: commit 095c0aa8 "sched: adjust scheduler cpu power for stolen time"
      Fixes: commit aa483808 "sched: Remove irq time from available CPU power"
      Fixes: commit e6e6685a "KVM guest: Steal time accounting"
      Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603041539490.3686@nanosSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      0579a127
    • Aaro Koskinen's avatar
      mtd: onenand: fix deadlock in onenand_block_markbad · 155025b2
      Aaro Koskinen authored
      commit 5e64c29e upstream.
      
      Commit 5942ddbc ("mtd: introduce mtd_block_markbad interface")
      incorrectly changed onenand_block_markbad() to call mtd_block_markbad
      instead of onenand_chip's block_markbad function. As a result the function
      will now recurse and deadlock. Fix by reverting the change.
      
      Fixes: 5942ddbc ("mtd: introduce mtd_block_markbad interface")
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Acked-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      155025b2
    • Joseph Qi's avatar
      ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list · 898eeac1
      Joseph Qi authored
      commit be12b299 upstream.
      
      When master handles convert request, it queues ast first and then
      returns status.  This may happen that the ast is sent before the request
      status because the above two messages are sent by two threads.  And
      right after the ast is sent, if master down, it may trigger BUG in
      dlm_move_lockres_to_recovery_list in the requested node because ast
      handler moves it to grant list without clear lock->convert_pending.  So
      remove BUG_ON statement and check if the ast is processed in
      dlmconvert_remote.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      898eeac1
    • Joseph Qi's avatar
      ocfs2/dlm: fix race between convert and recovery · 70f5f65c
      Joseph Qi authored
      commit ac7cf246 upstream.
      
      There is a race window between dlmconvert_remote and
      dlm_move_lockres_to_recovery_list, which will cause a lock with
      OCFS2_LOCK_BUSY in grant list, thus system hangs.
      
      dlmconvert_remote
      {
              spin_lock(&res->spinlock);
              list_move_tail(&lock->list, &res->converting);
              lock->convert_pending = 1;
              spin_unlock(&res->spinlock);
      
              status = dlm_send_remote_convert_request();
              >>>>>> race window, master has queued ast and return DLM_NORMAL,
                     and then down before sending ast.
                     this node detects master down and calls
                     dlm_move_lockres_to_recovery_list, which will revert the
                     lock to grant list.
                     Then OCFS2_LOCK_BUSY won't be cleared as new master won't
                     send ast any more because it thinks already be authorized.
      
              spin_lock(&res->spinlock);
              lock->convert_pending = 0;
              if (status != DLM_NORMAL)
                      dlm_revert_pending_convert(res, lock);
              spin_unlock(&res->spinlock);
      }
      
      In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set
      (res is still in recovering) or res master changed (new master has
      finished recovery), reset the status to DLM_RECOVERING, then it will
      retry convert.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Reviewed-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      70f5f65c
    • Vladis Dronov's avatar
      Input: ati_remote2 - fix crashes on detecting device with invalid descriptor · 0db38337
      Vladis Dronov authored
      commit 950336ba upstream.
      
      The ati_remote2 driver expects at least two interfaces with one
      endpoint each. If given malicious descriptor that specify one
      interface or no endpoints, it will crash in the probe function.
      Ensure there is at least two interfaces and one endpoint for each
      interface before using it.
      
      The full disclosure: http://seclists.org/bugtraq/2016/Mar/90Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      0db38337
    • Oliver Neukum's avatar
      Input: ims-pcu - sanity check against missing interfaces · da23ec55
      Oliver Neukum authored
      commit a0ad220c upstream.
      
      A malicious device missing interface can make the driver oops.
      Add sanity checking.
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      da23ec55
    • Julia Lawall's avatar
      scripts/coccinelle: modernize & · 869dc279
      Julia Lawall authored
      commit 1b669e71 upstream.
      
      & is no longer allowed in column 0, since Coccinelle 1.0.4.
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Tested-by: default avatarNishanth Menon <nm@ti.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      869dc279
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix trace_printk() to print when not using bprintk() · 2ec6dac1
      Steven Rostedt (Red Hat) authored
      commit 3debb0a9 upstream.
      
      The trace_printk() code will allocate extra buffers if the compile detects
      that a trace_printk() is used. To do this, the format of the trace_printk()
      is saved to the __trace_printk_fmt section, and if that section is bigger
      than zero, the buffers are allocated (along with a message that this has
      happened).
      
      If trace_printk() uses a format that is not a constant, and thus something
      not guaranteed to be around when the print happens, the compiler optimizes
      the fmt out, as it is not used, and the __trace_printk_fmt section is not
      filled. This means the kernel will not allocate the special buffers needed
      for the trace_printk() and the trace_printk() will not write anything to the
      tracing buffer.
      
      Adding a "__used" to the variable in the __trace_printk_fmt section will
      keep it around, even though it is set to NULL. This will keep the string
      from being printed in the debugfs/tracing/printk_formats section as it is
      not needed.
      Reported-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Fixes: 07d777fe "tracing: Add percpu buffers for trace_printk()"
      Cc: stable@vger.kernel.org # v3.5+
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      2ec6dac1
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix crash from reading trace_pipe with sendfile · 3f3f1fce
      Steven Rostedt (Red Hat) authored
      commit a29054d9 upstream.
      
      If tracing contains data and the trace_pipe file is read with sendfile(),
      then it can trigger a NULL pointer dereference and various BUG_ON within the
      VM code.
      
      There's a patch to fix this in the splice_to_pipe() code, but it's also a
      good idea to not let that happen from trace_pipe either.
      
      Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.in
      
      Cc: stable@vger.kernel.org # 2.6.30+
      Reported-by: default avatarRabin Vincent <rabin.vincent@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      3f3f1fce
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Have preempt(irqs)off trace preempt disabled functions · e5509925
      Steven Rostedt (Red Hat) authored
      commit cb86e053 upstream.
      
      Joel Fernandes reported that the function tracing of preempt disabled
      sections was not being reported when running either the preemptirqsoff or
      preemptoff tracers. This was due to the fact that the function tracer
      callback for those tracers checked if irqs were disabled before tracing. But
      this fails when we want to trace preempt off locations as well.
      
      Joel explained that he wanted to see funcitons where interrupts are enabled
      but preemption was disabled. The expected output he wanted:
      
         <...>-2265    1d.h1 3419us : preempt_count_sub <-irq_exit
         <...>-2265    1d..1 3419us : __do_softirq <-irq_exit
         <...>-2265    1d..1 3419us : msecs_to_jiffies <-__do_softirq
         <...>-2265    1d..1 3420us : irqtime_account_irq <-__do_softirq
         <...>-2265    1d..1 3420us : __local_bh_disable_ip <-__do_softirq
         <...>-2265    1..s1 3421us : run_timer_softirq <-__do_softirq
         <...>-2265    1..s1 3421us : hrtimer_run_pending <-run_timer_softirq
         <...>-2265    1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq
         <...>-2265    1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq
         <...>-2265    1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq
         <...>-2265    1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq
         <...>-2265    1..s1 3423us : rcu_bh_qs <-__do_softirq
         <...>-2265    1d.s1 3423us : irqtime_account_irq <-__do_softirq
         <...>-2265    1d.s1 3423us : __local_bh_enable <-__do_softirq
      
      There's a comment saying that the irq disabled check is because there's a
      possible race that tracing_cpu may be set when the function is executed. But
      I don't remember that race. For now, I added a check for preemption being
      enabled too to not record the function, as there would be no race if that
      was the case. I need to re-investigate this, as I'm now thinking that the
      tracing_cpu will always be correct. But no harm in keeping the check for
      now, except for the slight performance hit.
      
      Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com
      
      Fixes: 5e6d2b9c "tracing: Use one prologue for the preempt irqs off tracer function tracers"
      Cc: stable@vget.kernel.org # 2.6.37+
      Reported-by: default avatarJoel Fernandes <agnel.joel@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      e5509925
    • Mario Kleiner's avatar
      drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards. · aeda7369
      Mario Kleiner authored
      commit 459ee1c3 upstream.
      
      As observed on Apple iMac10,1, DCE-3.2, RV-730,
      link rate of 2.7 Ghz is not selected, because
      the args.v1.ucConfig flag setting for 2.7 Ghz
      gets overwritten by a following assignment of
      the transmitter to use.
      
      Move link rate setup a few lines down to fix this.
      In practice this didn't have any positive or
      negative effect on display setup on the tested
      iMac10,1 so i don't know if backporting to stable
      makes sense or not.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      aeda7369
    • Gabriel Krisman Bertazi's avatar
      ipr: Fix regression when loading firmware · e018f7b8
      Gabriel Krisman Bertazi authored
      commit 21b81716 upstream.
      
      Commit d63c7dd5 ("ipr: Fix out-of-bounds null overwrite") removed
      the end of line handling when storing the update_fw sysfs attribute.
      This changed the userpace API because it started refusing writes
      terminated by a line feed, which broke the update tools we already have.
      
      This patch re-adds that handling, so both a write terminated by a line
      feed or not can make it through with the update.
      
      Fixes: d63c7dd5 ("ipr: Fix out-of-bounds null overwrite")
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
      Cc: Insu Yun <wuninsu@gmail.com>
      Acked-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      e018f7b8
    • Insu Yun's avatar
      ipr: Fix out-of-bounds null overwrite · c7f5b11e
      Insu Yun authored
      commit d63c7dd5 upstream.
      
      Return value of snprintf is not bound by size value, 2nd argument.
      (https://www.kernel.org/doc/htmldocs/kernel-api/API-snprintf.html).
      Return value is number of printed chars, can be larger than 2nd
      argument.  Therefore, it can write null byte out of bounds ofbuffer.
      Since snprintf puts null, it does not need to put additional null byte.
      Signed-off-by: default avatarInsu Yun <wuninsu@gmail.com>
      Reviewed-by: default avatarShane Seymour <shane.seymour@hpe.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      c7f5b11e
    • Aurelien Jacquiot's avatar
      rapidio/rionet: fix deadlock on SMP · 7af534de
      Aurelien Jacquiot authored
      commit 36915976 upstream.
      
      Fix deadlocking during concurrent receive and transmit operations on SMP
      platforms caused by the use of incorrect lock: on transmit 'tx_lock'
      spinlock should be used instead of 'lock' which is used for receive
      operation.
      
      This fix is applicable to kernel versions starting from v2.15.
      Signed-off-by: default avatarAurelien Jacquiot <a-jacquiot@ti.com>
      Signed-off-by: default avatarAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      7af534de
    • Jes Sorensen's avatar
      md/raid5: Compare apples to apples (or sectors to sectors) · f6d033a3
      Jes Sorensen authored
      commit e7597e69 upstream.
      
      'max_discard_sectors' is in sectors, while 'stripe' is in bytes.
      
      This fixes the problem where DISCARD would get disabled on some larger
      RAID5 configurations (6 or more drives in my testing), while it worked
      as expected with smaller configurations.
      
      Fixes: 620125f2 ("MD: raid5 trim support")
      Cc: stable@vger.kernel.org v3.7+
      Signed-off-by: default avatarJes Sorensen <Jes.Sorensen@redhat.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      f6d033a3
    • Max Filippov's avatar
      xtensa: clear all DBREAKC registers on start · c716151e
      Max Filippov authored
      commit 7de7ac78 upstream.
      
      There are XCHAL_NUM_DBREAK registers, clear them all.
      This also fixes cryptic assembler error message with binutils 2.25 when
      XCHAL_NUM_DBREAK is 0:
      
        as: out of memory allocating 18446744073709551575 bytes after a total
        of 495616 bytes
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      c716151e
    • Max Filippov's avatar
      xtensa: ISS: don't hang if stdin EOF is reached · fd5924d8
      Max Filippov authored
      commit 362014c8 upstream.
      
      Simulator stdin may be connected to a file, when its end is reached
      kernel hangs in infinite loop inside rs_poll, because simc_poll always
      signals that descriptor 0 is readable and simc_read always returns 0.
      Check simc_read return value and exit loop if it's not positive. Also
      don't rewind polling timer if it's zero.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      fd5924d8
    • Rabin Vincent's avatar
      splice: handle zero nr_pages in splice_to_pipe() · 929522bf
      Rabin Vincent authored
      commit d6785d91 upstream.
      
      Running the following command:
      
       busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null
      
      with any tracing enabled pretty very quickly leads to various NULL
      pointer dereferences and VM BUG_ON()s, such as these:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       IP: [<ffffffff8119df6c>] generic_pipe_buf_release+0xc/0x40
       Call Trace:
        [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
        [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
        [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
        [<ffffffff81196869>] do_sendfile+0x199/0x380
        [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
        [<ffffffff8192cbee>] entry_SYSCALL_64_fastpath+0x12/0x6d
      
       page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
       kernel BUG at include/linux/mm.h:367!
       invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       RIP: [<ffffffff8119df9c>] generic_pipe_buf_release+0x3c/0x40
       Call Trace:
        [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
        [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
        [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
        [<ffffffff81196869>] do_sendfile+0x199/0x380
        [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
        [<ffffffff8192cd1e>] tracesys_phase2+0x84/0x89
      
      (busybox's cat uses sendfile(2), unlike the coreutils version)
      
      This is because tracing_splice_read_pipe() can call splice_to_pipe()
      with spd->nr_pages == 0.  spd_pages underflows in splice_to_pipe() and
      we fill the page pointers and the other fields of the pipe_buffers with
      garbage.
      
      All other callers of splice_to_pipe() avoid calling it when nr_pages ==
      0, and we could make tracing_splice_read_pipe() do that too, but it
      seems reasonable to have splice_to_page() handle this condition
      gracefully.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      929522bf
    • Michael S. Tsirkin's avatar
      watchdog: rc32434_wdt: fix ioctl error handling · 9bd0caf3
      Michael S. Tsirkin authored
      commit 10e7ac22 upstream.
      
      Calling return copy_to_user(...) in an ioctl will not do the right thing
      if there's a pagefault: copy_to_user returns the number of bytes not
      copied in this case.
      
      Fix up watchdog/rc32434_wdt to do
      	return copy_to_user(...)) ?  -EFAULT : 0;
      
      instead.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWim Van Sebroeck <wim@iguana.be>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      9bd0caf3
    • Eric Wheeler's avatar
      bcache: fix cache_set_flush() NULL pointer dereference on OOM · f5b0d853
      Eric Wheeler authored
      commit f8b11260 upstream.
      
      When bch_cache_set_alloc() fails to kzalloc the cache_set, the
      asyncronous closure handling tries to dereference a cache_set that
      hadn't yet been allocated inside of cache_set_flush() which is called
      by __cache_set_unregister() during cleanup.  This appears to happen only
      during an OOM condition on bcache_register.
      Signed-off-by: default avatarEric Wheeler <bcache@linux.ewheeler.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      f5b0d853
    • OGAWA Hirofumi's avatar
      jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path · 7493d128
      OGAWA Hirofumi authored
      commit c0a2ad9b upstream.
      
      On umount path, jbd2_journal_destroy() writes latest transaction ID
      (->j_tail_sequence) to be used at next mount.
      
      The bug is that ->j_tail_sequence is not holding latest transaction ID
      in some cases. So, at next mount, there is chance to conflict with
      remaining (not overwritten yet) transactions.
      
      	mount (id=10)
      	write transaction (id=11)
      	write transaction (id=12)
      	umount (id=10) <= the bug doesn't write latest ID
      
      	mount (id=10)
      	write transaction (id=11)
      	crash
      
      	mount
      	[recovery process]
      		transaction (id=11)
      		transaction (id=12) <= valid transaction ID, but old commit
                                             must not replay
      
      Like above, this bug become the cause of recovery failure, or FS
      corruption.
      
      So why ->j_tail_sequence doesn't point latest ID?
      
      Because if checkpoint transactions was reclaimed by memory pressure
      (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
      (And another case is, __jbd2_journal_clean_checkpoint_list() is called
      with empty transaction.)
      
      So in above cases, ->j_tail_sequence is not pointing latest
      transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
      done too.
      
      So, to fix this problem with minimum changes, this patch updates
      ->j_tail_sequence, and issue REQ_FLUSH.  (With more complex changes,
      some optimizations would be possible to avoid unnecessary REQ_FLUSH
      for example though.)
      
      BTW,
      
      	journal->j_tail_sequence =
      		++journal->j_transaction_sequence;
      
      Increment of ->j_transaction_sequence seems to be unnecessary, but
      ext3 does this.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      7493d128
    • Vittorio Gambaletta (VittGam)'s avatar
      ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41. · f4795a4e
      Vittorio Gambaletta (VittGam) authored
      commit 4061db03 upstream.
      
      The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
      will often fail, so add a quirk entry to fix it.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      f4795a4e
    • Tiffany Lin's avatar
      media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32 · 68d6ceb7
      Tiffany Lin authored
      commit 7df5ab87 upstream.
      
      In v4l2-compliance utility, test QUERYBUF required correct length
      value to go through each planar to check planar's length in
      multi-planar buffer type
      Signed-off-by: default avatarTiffany Lin <tiffany.lin@mediatek.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: <stable@vger.kernel.org>      # for v3.7 and up
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      68d6ceb7