1. 16 9月, 2016 1 次提交
  2. 15 9月, 2016 18 次提交
  3. 31 7月, 2016 1 次提交
    • M
      random: Fix crashes with sparse node ids · dd0f0cf5
      Michael Ellerman 提交于
      On a system with sparse node ids, eg. a powerpc system with 4 nodes
      numbered like so:
      
        node   0: [mem 0x0000000000000000-0x00000007ffffffff]
        node   1: [mem 0x0000000800000000-0x0000000fffffffff]
        node  16: [mem 0x0000001000000000-0x00000017ffffffff]
        node  17: [mem 0x0000001800000000-0x0000001fffffffff]
      
      The code in rand_initialize() will allocate 4 pointers for the pool
      array, and initialise them correctly.
      
      However when go to use the pool, in eg. extract_crng(), we use the
      numa_node_id() to index into the array. For the higher numbered node ids
      this leads to random memory corruption, depending on what was kmalloc'ed
      adjacent to the pool array.
      
      Fix it by using nr_node_ids to size the pool array.
      
      Fixes: 1e7f583a ("random: make /dev/urandom scalable for silly userspace programs")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd0f0cf5
  4. 28 7月, 2016 1 次提交
  5. 27 7月, 2016 2 次提交
    • T
      ipmi: remove trydefaults parameter and default init · b07b58a3
      Tony Camuso 提交于
      Parameter trydefaults=1 causes the ipmi_init to initialize ipmi through
      the legacy port io space that was designated for ipmi. Architectures
      that do not map legacy port io can panic when trydefaults=1.
      
      Rather than implement build-time conditional exceptions for each
      architecture that does not map legacy port io, we have removed legacy
      port io from the driver.
      
      Parameter 'trydefaults' has been removed. Attempts to use it hereafter
      will evoke the "Unknown symbol in module, or unknown parameter" message.
      
      The patch was built against a number of architectures and tested for
      regressions and functionality on x86_64 and ARM64.
      Signed-off-by: NTony Camuso <tcamuso@redhat.com>
      
      Removed the config entry and the address source entry for default,
      since neither were used any more.
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      b07b58a3
    • H
      shmem: get_unmapped_area align huge page · c01d5b30
      Hugh Dickins 提交于
      Provide a shmem_get_unmapped_area method in file_operations, called at
      mmap time to decide the mapping address.  It could be conditional on
      CONFIG_TRANSPARENT_HUGEPAGE, but save #ifdefs in other places by making
      it unconditional.
      
      shmem_get_unmapped_area() first calls the usual mm->get_unmapped_area
      (which we treat as a black box, highly dependent on architecture and
      config and executable layout).  Lots of conditions, and in most cases it
      just goes with the address that chose; but when our huge stars are
      rightly aligned, yet that did not provide a suitable address, go back to
      ask for a larger arena, within which to align the mapping suitably.
      
      There have to be some direct calls to shmem_get_unmapped_area(), not via
      the file_operations: because of the way shmem_zero_setup() is called to
      create a shmem object late in the mmap sequence, when MAP_SHARED is
      requested with MAP_ANONYMOUS or /dev/zero.  Though this only matters
      when /proc/sys/vm/shmem_huge has been set.
      
      Link: http://lkml.kernel.org/r/1466021202-61880-29-git-send-email-kirill.shutemov@linux.intel.comSigned-off-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c01d5b30
  6. 19 7月, 2016 7 次提交
  7. 14 7月, 2016 1 次提交
  8. 08 7月, 2016 1 次提交
    • J
      x86/mm/pat, /dev/mem: Remove superfluous error message · 39380b80
      Jiri Kosina 提交于
      Currently it's possible for broken (or malicious) userspace to flood a
      kernel log indefinitely with messages a-la
      
      	Program dmidecode tried to access /dev/mem between f0000->100000
      
      because range_is_allowed() is case of CONFIG_STRICT_DEVMEM being turned on
      dumps this information each and every time devmem_is_allowed() fails.
      
      Reportedly userspace that is able to trigger contignuous flow of these
      messages exists.
      
      It would be possible to rate limit this message, but that'd have a
      questionable value; the administrator wouldn't get information about all
      the failing accessess, so then the information would be both superfluous
      and incomplete at the same time :)
      
      Returning EPERM (which is what is actually happening) is enough indication
      for userspace what has happened; no need to log this particular error as
      some sort of special condition.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1607081137020.24757@cbobk.fhfr.pmSigned-off-by: NIngo Molnar <mingo@kernel.org>
      39380b80
  9. 04 7月, 2016 1 次提交
    • T
      random: strengthen input validation for RNDADDTOENTCNT · 86a574de
      Theodore Ts'o 提交于
      Don't allow RNDADDTOENTCNT or RNDADDENTROPY to accept a negative
      entropy value.  It doesn't make any sense to subtract from the entropy
      counter, and it can trigger a warning:
      
      random: negative entropy/overflow: pool input count -40000
      ------------[ cut here ]------------
      WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[<      none
       >] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
      Modules linked in:
      CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffffffff880b58e0 ffff88005dd9fcb0 ffffffff82cc838f ffffffff87158b40
       fffffbfff1016b1c 0000000000000000 0000000000000000 ffffffff87158b40
       ffffffff83283dae 0000000000000009 ffff88005dd9fcf8 ffffffff8136d27f
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82cc838f>] dump_stack+0x12e/0x18f lib/dump_stack.c:51
       [<ffffffff8136d27f>] __warn+0x19f/0x1e0 kernel/panic.c:516
       [<ffffffff8136d48c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
       [<ffffffff83283dae>] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
       [<     inline     >] credit_entropy_bits_safe drivers/char/random.c:734
       [<ffffffff8328785d>] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
       [<     inline     >] vfs_ioctl fs/ioctl.c:43
       [<ffffffff8185316c>] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
       [<     inline     >] SYSC_ioctl fs/ioctl.c:689
       [<ffffffff8185405f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
       [<ffffffff86a995c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
      arch/x86/entry/entry_64.S:207
      ---[ end trace 5d4902b2ba842f1f ]---
      
      This was triggered using the test program:
      
      // autogenerated by syzkaller (http://github.com/google/syzkaller)
      
      int main() {
              int fd = open("/dev/random", O_RDWR);
              int val = -5000;
              ioctl(fd, RNDADDTOENTCNT, &val);
              return 0;
      }
      
      It's harmless in that (a) only root can trigger it, and (b) after
      complaining the code never does let the entropy count go negative, but
      it's better to simply not allow this userspace from passing in a
      negative entropy value altogether.
      
      Google-Bug-Id: #29575089
      Reported-By: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      86a574de
  10. 03 7月, 2016 3 次提交
  11. 29 6月, 2016 1 次提交
  12. 27 6月, 2016 1 次提交
    • N
      hwrng: omap - Fix assumption that runtime_get_sync will always succeed · 61dc0a44
      Nishanth Menon 提交于
      pm_runtime_get_sync does return a error value that must be checked for
      error conditions, else, due to various reasons, the device maynot be
      enabled and the system will crash due to lack of clock to the hardware
      module.
      
      Before:
      12.562784] [00000000] *pgd=fe193835
      12.562792] Internal error: : 1406 [#1] SMP ARM
      [...]
      12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
      12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
      12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
      12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
      12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
      [...]
      
      After the proper checks:
      [   94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
      missing hwmod/omap_dev info
      [   94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
      [   94.382351] omap_rng 48090000.rng: initialization failed.
      
      Fixes: 665d92fa ("hwrng: OMAP: convert to use runtime PM")
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      61dc0a44
  13. 26 6月, 2016 1 次提交
  14. 25 6月, 2016 1 次提交