1. 01 Dec, 2018 34 commits
  2. 27 Nov, 2018 6 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.84 · 4201a586
      Greg Kroah-Hartman authored
      4201a586
    • Ilya Dryomov's avatar
      libceph: fall back to sendmsg for slab pages · 3c7f1671
      Ilya Dryomov authored
      commit 7e241f64 upstream.
      
      skb_can_coalesce() allows coalescing neighboring slab objects into
      a single frag:
      
        return page == skb_frag_page(frag) &&
               off == frag->page_offset + skb_frag_size(frag);
      
      ceph_tcp_sendpage() can be handed slab pages.  One example of this is
      XFS: it passes down sector sized slab objects for its metadata I/O.  If
      the kernel client is co-located on the OSD node, the skb may go through
      loopback and pop on the receive side with the exact same set of frags.
      When tcp_recvmsg() attempts to copy out such a frag, hardened usercopy
      complains because the size exceeds the object's allocated size:
      
        usercopy: kernel memory exposure attempt detected from ffff9ba917f20a00 (kmalloc-512) (1024 bytes)
      
      Although skb_can_coalesce() could be taught to return false if the
      resulting frag would cross a slab object boundary, we already have
      a fallback for non-refcounted pages.  Utilize it for slab pages too.
      
      Cc: stable@vger.kernel.org # 4.8+
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c7f1671
    • Eric Biggers's avatar
      HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges · 540f8937
      Eric Biggers authored
      commit 8c01db76 upstream.
      
      When a UHID_CREATE command is written to the uhid char device, a
      copy_from_user() is done from a user pointer embedded in the command.
      When the address limit is KERNEL_DS, e.g. as is the case during
      sys_sendfile(), this can read from kernel memory.  Alternatively,
      information can be leaked from a setuid binary that is tricked to write
      to the file descriptor.  Therefore, forbid UHID_CREATE in these cases.
      
      No other commands in uhid_char_write() are affected by this bug and
      UHID_CREATE is marked as "obsolete", so apply the restriction to
      UHID_CREATE only rather than to uhid_char_write() entirely.
      
      Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
      Jann Horn for commit 9da3f2b7 ("x86/fault: BUG() when uaccess
      helpers fault on kernel addresses"), allowing this bug to be found.
      
      Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com
      Fixes: d365c6cf ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
      Cc: <stable@vger.kernel.org> # v3.6+
      Cc: Jann Horn <jannh@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      540f8937
    • Hans de Goede's avatar
      ACPI / platform: Add SMB0001 HID to forbidden_id_list · 3cf1a2b4
      Hans de Goede authored
      commit 2bbb5fa3 upstream.
      
      Many HP AMD based laptops contain an SMB0001 device like this:
      
      Device (SMBD)
      {
          Name (_HID, "SMB0001")  // _HID: Hardware ID
          Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
          {
              IO (Decode16,
                  0x0B20,             // Range Minimum
                  0x0B20,             // Range Maximum
                  0x20,               // Alignment
                  0x20,               // Length
                  )
              IRQ (Level, ActiveLow, Shared, )
                  {7}
          })
      }
      
      The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
      be called with legacy=true and this message to show in dmesg:
      ACPI: IRQ 7 override to edge, high
      
      This causes issues when later on the AMD0030 GPIO device gets enumerated:
      
      Device (GPIO)
      {
          Name (_HID, "AMDI0030")  // _HID: Hardware ID
          Name (_CID, "AMDI0030")  // _CID: Compatible ID
          Name (_UID, Zero)  // _UID: Unique ID
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
      	Name (RBUF, ResourceTemplate ()
      	{
      	    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
      	    {
      		0x00000007,
      	    }
      	    Memory32Fixed (ReadWrite,
      		0xFED81500,         // Address Base
      		0x00000400,         // Address Length
      		)
      	})
      	Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
          }
      }
      
      Now acpi_dev_get_irqresource() gets called with legacy=false, but because
      of the earlier override of the trigger-type acpi_register_gsi() returns
      -EBUSY (because we try to register the same interrupt with a different
      trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.
      
      The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
      acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
      resulting in the following in dmesg:
      
      amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
      amd_gpio: probe of AMDI0030:00 failed with error -22
      
      The SMB0001 is a "virtual" device in the sense that the only way the OS
      interacts with it is through calling a couple of methods to do SMBus
      transfers. As such it is weird that it has IO and IRQ resources at all,
      because the driver for it is not expected to ever access the hardware
      directly.
      
      The Linux driver for the SMB0001 device directly binds to the acpi_device
      through the acpi_bus, so we do not need to instantiate a platform_device
      for this ACPI device. This commit adds the SMB0001 HID to the
      forbidden_id_list, avoiding the instantiating of a platform_device for it.
      Not instantiating a platform_device means we will no longer call
      acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
      the AMDI0030 device failing.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523Reported-by: default avatarLukas Kahnert <openproggerfreak@gmail.com>
      Tested-by: default avatarMarc <suaefar@googlemail.com>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cf1a2b4
    • Gustavo A. R. Silva's avatar
      drivers/misc/sgi-gru: fix Spectre v1 vulnerability · 16c233b9
      Gustavo A. R. Silva authored
      commit fee05f45 upstream.
      
      req.gid can be indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
      potential spectre issue 'gru_base' [w]
      
      Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
      uses it to index gru_base.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16c233b9
    • Mattias Jacobsson's avatar
      USB: misc: appledisplay: add 20" Apple Cinema Display · fb37c765
      Mattias Jacobsson authored
      commit f6501f49 upstream.
      
      Add another Apple Cinema Display to the list of supported displays
      Signed-off-by: default avatarMattias Jacobsson <2pi@mok.nu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb37c765