1. 03 May, 2017 32 commits
  2. 27 Apr, 2017 8 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.25 · a8c90ef6
      Greg Kroah-Hartman authored
      a8c90ef6
    • Dan Williams's avatar
      device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation · c36eaa6c
      Dan Williams authored
      commit 956a4cd2 upstream.
      
      The following warning triggers with a new unit test that stresses the
      device-dax interface.
      
       ===============================
       [ ERR: suspicious RCU usage.  ]
       4.11.0-rc4+ #1049 Tainted: G           O
       -------------------------------
       ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 0
       2 locks held by fio/9070:
        #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
        #1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]
      
       Call Trace:
        dump_stack+0x86/0xc3
        lockdep_rcu_suspicious+0xd7/0x110
        ___might_sleep+0xac/0x250
        __might_sleep+0x4a/0x80
        __alloc_pages_nodemask+0x23a/0x360
        alloc_pages_current+0xa1/0x1f0
        pte_alloc_one+0x17/0x80
        __pte_alloc+0x1e/0x120
        __get_locked_pte+0x1bf/0x1d0
        insert_pfn.isra.70+0x3a/0x100
        ? lookup_memtype+0xa6/0xd0
        vm_insert_mixed+0x64/0x90
        dax_dev_huge_fault+0x520/0x620 [dax]
        ? dax_dev_huge_fault+0x32/0x620 [dax]
        dax_dev_fault+0x10/0x20 [dax]
        __do_fault+0x1e/0x140
        __handle_mm_fault+0x9af/0x10d0
        handle_mm_fault+0x16d/0x370
        ? handle_mm_fault+0x47/0x370
        __do_page_fault+0x28c/0x4f0
        trace_do_page_fault+0x58/0x2a0
        do_async_page_fault+0x1a/0xa0
        async_page_fault+0x28/0x30
      
      Inserting a page table entry may trigger an allocation while we are
      holding a read lock to keep the device instance alive for the duration
      of the fault. Use srcu for this keep-alive protection.
      
      Fixes: dee41079 ("/dev/dax, core: file operations and dax-mmap")
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c36eaa6c
    • Vishal Verma's avatar
      x86/mce: Make the MCE notifier a blocking one · f8bc0881
      Vishal Verma authored
      commit 0dc9c639 upstream.
      
      The NFIT MCE handler callback (for handling media errors on NVDIMMs)
      takes a mutex to add the location of a memory error to a list. But since
      the notifier call chain for machine checks (x86_mce_decoder_chain) is
      atomic, we get a lockdep splat like:
      
        BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
        in_atomic(): 1, irqs_disabled(): 0, pid: 4, name: kworker/0:0
        [..]
        Call Trace:
         dump_stack
         ___might_sleep
         __might_sleep
         mutex_lock_nested
         ? __lock_acquire
         nfit_handle_mce
         notifier_call_chain
         atomic_notifier_call_chain
         ? atomic_notifier_call_chain
         mce_gen_pool_process
      
      Convert the notifier to a blocking one which gets to run only in process
      context.
      
      Boris: remove the notifier call in atomic context in print_mce(). For
      now, let's print the MCE on the atomic path so that we can make sure
      they go out and get logged at least.
      
      Fixes: 6839a6d9 ("nfit: do an ARS scrub on hitting a latent media error")
      Reported-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: x86-ml <x86@kernel.org>
      Link: http://lkml.kernel.org/r/20170411224457.24777-1-vishal.l.verma@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8bc0881
    • Yazen Ghannam's avatar
      x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs · 6966a657
      Yazen Ghannam authored
      commit 29f72ce3 upstream.
      
      MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
      However, MCA bank 3 is defined on Fam17h systems and can be accessed
      using legacy MSRs. Without a name we get a stack trace on Fam17h systems
      when trying to register sysfs files for bank 3 on kernels that don't
      recognize Scalable MCA.
      
      Call MCA bank 3 "decode_unit" since this is what it represents on
      Fam17h. This will allow kernels without SMCA support to see this bank on
      Fam17h+ and prevent the stack trace. This will not affect older systems
      since this bank is reserved on them, i.e. it'll be ignored.
      
      Tested on AMD Fam15h and Fam17h systems.
      
        WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
        kobject: (ffff88085bb256c0): attempted to be registered with empty name!
        ...
        Call Trace:
         kobject_add_internal
         kobject_add
         kobject_create_and_add
         threshold_create_device
         threshold_init_device
      Signed-off-by: default avatarYazen Ghannam <yazen.ghannam@amd.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-Yazen.Ghannam@amd.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6966a657
    • Ravi Bangoria's avatar
      powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction · 1bd55ab1
      Ravi Bangoria authored
      commit 9e1ba4f2 upstream.
      
      If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
      OOPS:
      
        Bad kernel stack pointer cd93c840 at c000000000009868
        Oops: Bad kernel stack pointer, sig: 6 [#1]
        ...
        GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840
        ...
        NIP [c000000000009868] resume_kernel+0x2c/0x58
        LR [c000000000006208] program_check_common+0x108/0x180
      
      On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
      not emulate actual store in emulate_step() because it may corrupt the exception
      frame. So the kernel does the actual store operation in exception return code
      i.e. resume_kernel().
      
      resume_kernel() loads the saved stack pointer from memory using lwz, which only
      loads the low 32-bits of the address, causing the kernel crash.
      
      Fix this by loading the 64-bit value instead.
      
      Fixes: be96f633 ("powerpc: Split out instruction analysis part of emulate_step()")
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reviewed-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Reviewed-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      [mpe: Change log massage, add stable tag]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1bd55ab1
    • Sebastian Siewior's avatar
      ubi/upd: Always flush after prepared for an update · 790b2b5a
      Sebastian Siewior authored
      commit 9cd9a21c upstream.
      
      In commit 6afaf8a4 ("UBI: flush wl before clearing update marker") I
      managed to trigger and fix a similar bug. Now here is another version of
      which I assumed it wouldn't matter back then but it turns out UBI has a
      check for it and will error out like this:
      
      |ubi0 warning: validate_vid_hdr: inconsistent used_ebs
      |ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592
      
      All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
      powercut in the middle of the operation.
      ubi_start_update() sets the update-marker and puts all EBs on the erase
      list. After that userland can proceed to write new data while the old EB
      aren't erased completely. A powercut at this point is usually not that
      much of a tragedy. UBI won't give read access to the static volume
      because it has the update marker. It will most likely set the corrupted
      flag because it misses some EBs.
      So we are all good. Unless the size of the image that has been written
      differs from the old image in the magnitude of at least one EB. In that
      case UBI will find two different values for `used_ebs' and refuse to
      attach the image with the error message mentioned above.
      
      So in order not to get in the situation, the patch will ensure that we
      wait until everything is removed before it tries to write any data.
      The alternative would be to detect such a case and remove all EBs at the
      attached time after we processed the volume-table and see the
      update-marker set. The patch looks bigger and I doubt it is worth it
      since usually the write() will wait from time to time for a new EB since
      usually there not that many spare EB that can be used.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      790b2b5a
    • Johannes Berg's avatar
      mac80211: fix MU-MIMO follow-MAC mode · 87cfeaa5
      Johannes Berg authored
      commit 9e478066 upstream.
      
      There are two bugs in the follow-MAC code:
       * it treats the radiotap header as the 802.11 header
         (therefore it can't possibly work)
       * it doesn't verify that the skb data it accesses is actually
         present in the header, which is mitigated by the first point
      
      Fix this by moving all of this out into a separate function.
      This function copies the data it needs using skb_copy_bits()
      to make sure it can be accessed if it's paged, and offsets
      that by the possibly present vendor radiotap header.
      
      This also makes all those conditions more readable.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87cfeaa5
    • Johannes Berg's avatar
      mac80211: reject ToDS broadcast data frames · e0411f1e
      Johannes Berg authored
      commit 3018e947 upstream.
      
      AP/AP_VLAN modes don't accept any real 802.11 multicast data
      frames, but since they do need to accept broadcast management
      frames the same is currently permitted for data frames. This
      opens a security problem because such frames would be decrypted
      with the GTK, and could even contain unicast L3 frames.
      
      Since the spec says that ToDS frames must always have the BSSID
      as the RA (addr1), reject any other data frames.
      
      The problem was originally reported in "Predicting, Decrypting,
      and Abusing WPA2/802.11 Group Keys" at usenix
      https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef
      and brought to my attention by Jouni.
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      --
      e0411f1e