1. 14 May, 2017 16 commits
  2. 08 May, 2017 10 commits
  3. 03 May, 2017 14 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.26 · d071951e
      Greg Kroah-Hartman authored
      d071951e
    • Josh Poimboeuf's avatar
      ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram · 6d10a6cf
      Josh Poimboeuf authored
      commit 34a477e5 upstream.
      
      On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
      graph tracing and then suspend to RAM, it will triple fault and reboot when
      it resumes.
      
      The first fault happens when booting a secondary CPU:
      
      startup_32_smp()
        load_ucode_ap()
          prepare_ftrace_return()
            ftrace_graph_is_dead()
              (accesses 'kill_ftrace_graph')
      
      The early head_32.S code calls into load_ucode_ap(), which has an an
      ftrace hook, so it calls prepare_ftrace_return(), which calls
      ftrace_graph_is_dead(), which tries to access the global
      'kill_ftrace_graph' variable with a virtual address, causing a fault
      because the CPU is still in real mode.
      
      The fix is to add a check in prepare_ftrace_return() to make sure it's
      running in protected mode before continuing.  The check makes sure the
      stack pointer is a virtual kernel address.  It's a bit of a hack, but
      it's not very intrusive and it works well enough.
      
      For reference, here are a few other (more difficult) ways this could
      have potentially been fixed:
      
      - Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
        is enabled.  (No idea what that would break.)
      
      - Track down load_ucode_ap()'s entire callee tree and mark all the
        functions 'notrace'.  (Probably not realistic.)
      
      - Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
        or __cpu_up(), and ensure that the pause facility can be queried from
        real mode.
      Reported-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Tested-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Reviewed-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>
      Cc: linux-acpi@vger.kernel.org
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/5c1272269a580660703ed2eccf44308e790c7a98.1492123841.git.jpoimboe@redhat.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d10a6cf
    • Vineet Gupta's avatar
      ARCv2: save r30 on kernel entry as gcc uses it for code-gen · 9cbf4337
      Vineet Gupta authored
      commit ecd43afd upstream.
      
      This is not exposed to userspace debugers yet, which can be done
      independently as a seperate patch !
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cbf4337
    • Maksim Salau's avatar
      net: can: usb: gs_usb: Fix buffer on stack · 4684be16
      Maksim Salau authored
      commit b05c73bd upstream.
      
      Allocate buffers on HEAP instead of STACK for local structures
      that are to be sent using usb_control_msg().
      Signed-off-by: default avatarMaksim Salau <maksim.salau@gmail.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4684be16
    • Jason A. Donenfeld's avatar
      macsec: avoid heap overflow in skb_to_sgvec · 07389a14
      Jason A. Donenfeld authored
      commit 4d6fa57b upstream.
      
      While this may appear as a humdrum one line change, it's actually quite
      important. An sk_buff stores data in three places:
      
      1. A linear chunk of allocated memory in skb->data. This is the easiest
         one to work with, but it precludes using scatterdata since the memory
         must be linear.
      2. The array skb_shinfo(skb)->frags, which is of maximum length
         MAX_SKB_FRAGS. This is nice for scattergather, since these fragments
         can point to different pages.
      3. skb_shinfo(skb)->frag_list, which is a pointer to another sk_buff,
         which in turn can have data in either (1) or (2).
      
      The first two are rather easy to deal with, since they're of a fixed
      maximum length, while the third one is not, since there can be
      potentially limitless chains of fragments. Fortunately dealing with
      frag_list is opt-in for drivers, so drivers don't actually have to deal
      with this mess. For whatever reason, macsec decided it wanted pain, and
      so it explicitly specified NETIF_F_FRAGLIST.
      
      Because dealing with (1), (2), and (3) is insane, most users of sk_buff
      doing any sort of crypto or paging operation calls a convenient function
      called skb_to_sgvec (which happens to be recursive if (3) is in use!).
      This takes a sk_buff as input, and writes into its output pointer an
      array of scattergather list items. Sometimes people like to declare a
      fixed size scattergather list on the stack; othertimes people like to
      allocate a fixed size scattergather list on the heap. However, if you're
      doing it in a fixed-size fashion, you really shouldn't be using
      NETIF_F_FRAGLIST too (unless you're also ensuring the sk_buff and its
      frag_list children arent't shared and then you check the number of
      fragments in total required.)
      
      Macsec specifically does this:
      
              size += sizeof(struct scatterlist) * (MAX_SKB_FRAGS + 1);
              tmp = kmalloc(size, GFP_ATOMIC);
              *sg = (struct scatterlist *)(tmp + sg_offset);
      	...
              sg_init_table(sg, MAX_SKB_FRAGS + 1);
              skb_to_sgvec(skb, sg, 0, skb->len);
      
      Specifying MAX_SKB_FRAGS + 1 is the right answer usually, but not if you're
      using NETIF_F_FRAGLIST, in which case the call to skb_to_sgvec will
      overflow the heap, and disaster ensues.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07389a14
    • Yan, Zheng's avatar
      ceph: fix recursion between ceph_set_acl() and __ceph_setattr() · 36e0be31
      Yan, Zheng authored
      commit 8179a101 upstream.
      
      ceph_set_acl() calls __ceph_setattr() if the setacl operation needs
      to modify inode's i_mode. __ceph_setattr() updates inode's i_mode,
      then calls posix_acl_chmod().
      
      The problem is that __ceph_setattr() calls posix_acl_chmod() before
      sending the setattr request. The get_acl() call in posix_acl_chmod()
      can trigger a getxattr request. The reply of the getxattr request
      can restore inode's i_mode to its old value. The set_acl() call in
      posix_acl_chmod() sees old value of inode's i_mode, so it calls
      __ceph_setattr() again.
      
      Link: http://tracker.ceph.com/issues/19688Reported-by: default avatarJerry Lee <leisurelysw24@gmail.com>
      Signed-off-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Tested-by: default avatarLuis Henriques <lhenriques@suse.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36e0be31
    • J. Bruce Fields's avatar
      nfsd: stricter decoding of write-like NFSv2/v3 ops · d7809b9e
      J. Bruce Fields authored
      commit 13bf9fbf upstream.
      
      The NFSv2/v3 code does not systematically check whether we decode past
      the end of the buffer.  This generally appears to be harmless, but there
      are a few places where we do arithmetic on the pointers involved and
      don't account for the possibility that a length could be negative.  Add
      checks to catch these.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7809b9e
    • J. Bruce Fields's avatar
      nfsd4: minor NFSv2/v3 write decoding cleanup · 8ed07979
      J. Bruce Fields authored
      commit db44bac4 upstream.
      
      Use a couple shortcuts that will simplify a following bugfix.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ed07979
    • J. Bruce Fields's avatar
      nfsd: check for oversized NFSv2/v3 arguments · fc6445df
      J. Bruce Fields authored
      commit e6838a29 upstream.
      
      A client can append random data to the end of an NFSv2 or NFSv3 RPC call
      without our complaining; we'll just stop parsing at the end of the
      expected data and ignore the rest.
      
      Encoded arguments and replies are stored together in an array of pages,
      and if a call is too large it could leave inadequate space for the
      reply.  This is normally OK because NFS RPC's typically have either
      short arguments and long replies (like READ) or long arguments and short
      replies (like WRITE).  But a client that sends an incorrectly long reply
      can violate those assumptions.  This was observed to cause crashes.
      
      Also, several operations increment rq_next_page in the decode routine
      before checking the argument size, which can leave rq_next_page pointing
      well past the end of the page array, causing trouble later in
      svc_free_pages.
      
      So, following a suggestion from Neil Brown, add a central check to
      enforce our expectation that no NFSv2/v3 call has both a large call and
      a large reply.
      
      As followup we may also want to rewrite the encoding routines to check
      more carefully that they aren't running off the end of the page array.
      
      We may also consider rejecting calls that have any extra garbage
      appended.  That would be safer, and within our rights by spec, but given
      the age of our server and the NFS protocol, and the fact that we've
      never enforced this before, we may need to balance that against the
      possibility of breaking some oddball client.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc6445df
    • Dmitry Torokhov's avatar
      Input: i8042 - add Clevo P650RS to the i8042 reset list · b88e4113
      Dmitry Torokhov authored
      commit 7c5bb4ac upstream.
      
      Clevo P650RS and other similar devices require i8042 to be reset in order
      to detect Synaptics touchpad.
      Reported-by: default avatarPaweł Bylica <chfast@gmail.com>
      Tested-by: default avatarEd Bordin <edbordin@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=190301Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b88e4113
    • Takashi Iwai's avatar
      ASoC: intel: Fix PM and non-atomic crash in bytcr drivers · 990afef9
      Takashi Iwai authored
      commit 6e4cac23 upstream.
      
      The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry
      the ignore_suspend flag, and this prevents the suspend/resume working
      properly while the stream is running, since SST core code has the
      check of the running streams and returns -EBUSY.  Drop these
      superfluous flags for fixing the behavior.
      
      Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE
      definitions, which leads to the kernel Oops at suspend/resume like:
      
        BUG: scheduling while atomic: systemd-sleep/3144/0x00000003
        Call Trace:
         dump_stack+0x5c/0x7a
         __schedule_bug+0x55/0x70
         __schedule+0x63c/0x8c0
         schedule+0x3d/0x90
         schedule_timeout+0x16b/0x320
         ? del_timer_sync+0x50/0x50
         ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
         ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
         ? remove_wait_queue+0x60/0x60
         ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core]
         ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core]
         ....
      
      This patch addresses these appropriately, too.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      990afef9
    • Al Viro's avatar
      p9_client_readdir() fix · b2b93bbe
      Al Viro authored
      commit 71d6ad08 upstream.
      
      Don't assume that server is sane and won't return more data than
      asked for.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2b93bbe
    • James Cowgill's avatar
      MIPS: Avoid BUG warning in arch_check_elf · 92f0ddec
      James Cowgill authored
      commit c46f59e9 upstream.
      
      arch_check_elf contains a usage of current_cpu_data that will call
      smp_processor_id() with preemption enabled and therefore triggers a
      "BUG: using smp_processor_id() in preemptible" warning when an fpxx
      executable is loaded.
      
      As a follow-up to commit b244614a ("MIPS: Avoid a BUG warning during
      prctl(PR_SET_FP_MODE, ...)"), apply the same fix to arch_check_elf by
      using raw_current_cpu_data instead. The rationale quoted from the previous
      commit:
      
      "It is assumed throughout the kernel that if any CPU has an FPU, then
      all CPUs would have an FPU as well, so it is safe to perform the check
      with preemption enabled - change the code to use raw_ variant of the
      check to avoid the warning."
      
      Fixes: 46490b57 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks")
      Signed-off-by: default avatarJames Cowgill <James.Cowgill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/15951/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92f0ddec
    • James Hogan's avatar
      MIPS: cevt-r4k: Fix out-of-bounds array access · 6fbb6c02
      James Hogan authored
      commit 9d7f29cd upstream.
      
      calculate_min_delta() may incorrectly access a 4th element of buf2[]
      which only has 3 elements. This may trigger undefined behaviour and has
      been reported to cause strange crashes in start_kernel() sometime after
      timer initialization when built with GCC 5.3, possibly due to
      register/stack corruption:
      
      sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns
      CPU 0 Unable to handle kernel paging request at virtual address ffffb0aa, epc == 8067daa8, ra == 8067da84
      Oops[#1]:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.18 #51
      task: 8065e3e0 task.stack: 80644000
      $ 0   : 00000000 00000001 00000000 00000000
      $ 4   : 8065b4d0 00000000 805d0000 00000010
      $ 8   : 00000010 80321400 fffff000 812de408
      $12   : 00000000 00000000 00000000 ffffffff
      $16   : 00000002 ffffffff 80660000 806a666c
      $20   : 806c0000 00000000 00000000 00000000
      $24   : 00000000 00000010
      $28   : 80644000 80645ed0 00000000 8067da84
      Hi    : 00000000
      Lo    : 00000000
      epc   : 8067daa8 start_kernel+0x33c/0x500
      ra    : 8067da84 start_kernel+0x318/0x500
      Status: 11000402 KERNEL EXL
      Cause : 4080040c (ExcCode 03)
      BadVA : ffffb0aa
      PrId  : 0501992c (MIPS 1004Kc)
      Modules linked in:
      Process swapper/0 (pid: 0, threadinfo=80644000, task=8065e3e0, tls=00000000)
      Call Trace:
      [<8067daa8>] start_kernel+0x33c/0x500
      Code: 24050240  0c0131f9  24849c64 <a200b0a8> 41606020  000000c0  0c1a45e6 00000000  0c1a5f44
      
      UBSAN also detects the same issue:
      
      ================================================================
      UBSAN: Undefined behaviour in arch/mips/kernel/cevt-r4k.c:85:41
      load of address 80647e4c with insufficient space
      for an object of type 'unsigned int'
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.18 #47
      Call Trace:
      [<80028f70>] show_stack+0x88/0xa4
      [<80312654>] dump_stack+0x84/0xc0
      [<8034163c>] ubsan_epilogue+0x14/0x50
      [<803417d8>] __ubsan_handle_type_mismatch+0x160/0x168
      [<8002dab0>] r4k_clockevent_init+0x544/0x764
      [<80684d34>] time_init+0x18/0x90
      [<8067fa5c>] start_kernel+0x2f0/0x500
      =================================================================
      
      buf2[] is intentionally only 3 elements so that the last element is the
      median once 5 samples have been inserted, so explicitly prevent the
      possibility of comparing against the 4th element rather than extending
      the array.
      
      Fixes: 1fa40555 ("MIPS: cevt-r4k: Dynamically calculate min_delta_ns")
      Reported-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Tested-by: default avatarRabin Vincent <rabinv@axis.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/15892/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fbb6c02