1. 26 Sep, 2018 1 commit
    • Corey Minyard's avatar
      ipmi: Fix I2C client removal in the SSIF driver · 888e989a
      Corey Minyard authored
      commit 0745dde62835be7e2afe62fcdb482fcad79cb743 upstream.
      The SSIF driver was removing any client that came in through the
      platform interface, but it should only remove clients that it
      added.  On a failure in the probe function, this could result
      in the following oops when the driver is removed and the
      client gets unregistered twice:
       CPU: 107 PID: 30266 Comm: rmmod Not tainted 4.18.0+ #80
       Hardware name: Cavium Inc. Saber/Saber, BIOS Cavium reference firmware version 7.0 08/04/2018
       pstate: 60400009 (nZCv daif +PAN -UAO)
       pc : kernfs_find_ns+0x28/0x120
       lr : kernfs_find_and_get_ns+0x40/0x60
       sp : ffff00002310fb50
       x29: ffff00002310fb50 x28: ffff800a8240f800
       x27: 0000000000000000 x26: 0000000000000000
       x25: 0000000056000000 x24: ffff000009073000
       x23: ffff000008998b38 x22: 0000000000000000
       x21: ffff800ed86de820 x20: 0000000000000000
       x19: ffff00000913a1d8 x18: 0000000000000000
       x17: 0000000000000000 x16: 0000000000000000
       x15: 0000000000000000 x14: 5300737265766972
       x13: 643d4d4554535953 x12: 0000000000000030
       x11: 0000000000000030 x10: 0101010101010101
       x9 : ffff800ea06cc3f9 x8 : 0000000000000000
       x7 : 0000000000000141 x6 : ffff000009073000
       x5 : ffff800adb706b00 x4 : 0000000000000000
       x3 : 00000000ffffffff x2 : 0000000000000000
       x1 : ffff000008998b38 x0 : ffff000008356760
       Process rmmod (pid: 30266, stack limit = 0x00000000e218418d)
       Call trace:
        i2c_unregister_device+0x84/0x90 [i2c_core]
        ssif_platform_remove+0x38/0x98 [ipmi_ssif]
        cleanup_ipmi_ssif+0x50/0xd82c [ipmi_ssif]
       Code: aa1e03e0 aa0203f6 aa0103f7 d503201f (7940e280)
       ---[ end trace 09f0e34cce8e2d8c ]---
       Kernel panic - not syncing: Fatal exception
       SMP: stopping secondary CPUs
       Kernel Offset: disabled
       CPU features: 0x23800c38
      So track the clients that the SSIF driver adds and only remove
      Reported-by: 's avatarGeorge Cherian <george.cherian@cavium.com>
      Signed-off-by: 's avatarCorey Minyard <cminyard@mvista.com>
      Tested-by: 's avatarGeorge Cherian <george.cherian@cavium.com>
      Cc: <stable@vger.kernel.org> # 4.14.x
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 19 Sep, 2018 3 commits
  3. 05 Sep, 2018 1 commit
  4. 03 Aug, 2018 1 commit
    • Theodore Ts'o's avatar
      random: mix rdrand with entropy sent in from userspace · af41fd04
      Theodore Ts'o authored
      commit 81e69df38e2911b642ec121dec319fad2a4782f3 upstream.
      Fedora has integrated the jitter entropy daemon to work around slow
      boot problems, especially on VM's that don't support virtio-rng:
      It's understandable why they did this, but the Jitter entropy daemon
      works fundamentally on the principle: "the CPU microarchitecture is
      **so** complicated and we can't figure it out, so it *must* be
      random".  Yes, it uses statistical tests to "prove" it is secure, but
      AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
      flying colors.
      So if RDRAND is available, mix it into entropy submitted from
      userspace.  It can't hurt, and if you believe the NSA has backdoored
      RDRAND, then they probably have enough details about the Intel
      microarchitecture that they can reverse engineer how the Jitter
      entropy daemon affects the microarchitecture, and attack its output
      stream.  And if RDRAND is in fact an honest DRNG, it will immeasurably
      improve on what the Jitter entropy daemon might produce.
      This also provides some protection against someone who is able to read
      or set the entropy seed file.
      Signed-off-by: 's avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 03 Jul, 2018 3 commits
  6. 20 Jun, 2018 1 commit
  7. 30 May, 2018 2 commits
  8. 01 May, 2018 8 commits
  9. 29 Apr, 2018 3 commits
  10. 26 Apr, 2018 1 commit
  11. 24 Apr, 2018 6 commits
  12. 12 Apr, 2018 1 commit
  13. 08 Apr, 2018 1 commit
  14. 24 Mar, 2018 1 commit
    • Kees Cook's avatar
      /dev/mem: Add bounce buffer for copy-out · ea60e54b
      Kees Cook authored
      [ Upstream commit 22ec1a2aea73b9dfe340dff7945bd85af4cc6280 ]
      As done for /proc/kcore in
        commit df04abfd ("fs/proc/kcore.c: Add bounce buffer for ktext data")
      this adds a bounce buffer when reading memory via /dev/mem. This
      is needed to allow kernel text memory to be read out when built with
      CONFIG_HARDENED_USERCOPY (which refuses to read out kernel text) and
      without CONFIG_STRICT_DEVMEM (which would have refused to read any RAM
      contents at all).
      Since this build configuration isn't common (most systems with
      to inform Kconfig about the recommended settings.
      This patch is modified from Brad Spengler/PaX Team's changes to /dev/mem
      code in the last public patch of grsecurity/PaX based on my understanding
      of the code. Changes or omissions from the original code are mine and
      don't reflect the original grsecurity/PaX code.
      Reported-by: 's avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Fixes: f5509cc1 ("mm: Hardened usercopy")
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. 19 Mar, 2018 1 commit
  16. 15 Mar, 2018 5 commits
  17. 09 Mar, 2018 1 commit