1. 05 Sep, 2018 35 commits
  2. 24 Aug, 2018 5 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.124 · e8d49e42
      Greg Kroah-Hartman authored
      e8d49e42
    • Jann Horn's avatar
      reiserfs: fix broken xattr handling (heap corruption, bad retval) · 696d906b
      Jann Horn authored
      commit a13f085d upstream.
      
      This fixes the following issues:
      
      - When a buffer size is supplied to reiserfs_listxattr() such that each
        individual name fits, but the concatenation of all names doesn't fit,
        reiserfs_listxattr() overflows the supplied buffer.  This leads to a
        kernel heap overflow (verified using KASAN) followed by an out-of-bounds
        usercopy and is therefore a security bug.
      
      - When a buffer size is supplied to reiserfs_listxattr() such that a
        name doesn't fit, -ERANGE should be returned.  But reiserfs instead just
        truncates the list of names; I have verified that if the only xattr on a
        file has a longer name than the supplied buffer length, listxattr()
        incorrectly returns zero.
      
      With my patch applied, -ERANGE is returned in both cases and the memory
      corruption doesn't happen anymore.
      
      Credit for making me clean this code up a bit goes to Al Viro, who pointed
      out that the ->actor calling convention is suboptimal and should be
      changed.
      
      Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com
      Fixes: 48b32a35 ("reiserfs: use generic xattr handlers")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarJeff Mahoney <jeffm@suse.com>
      Cc: Eric Biggers <ebiggers@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      696d906b
    • Esben Haabendal's avatar
      i2c: imx: Fix race condition in dma read · 44745bd1
      Esben Haabendal authored
      commit bed4ff1e upstream.
      
      This fixes a race condition, where the DMAEN bit ends up being set after
      I2C slave has transmitted a byte following the dummy read.  When that
      happens, an interrupt is generated instead, and no DMA request is generated
      to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).
      
      Fixed by setting the DMAEN bit before the dummy read.
      Signed-off-by: default avatarEsben Haabendal <eha@deif.com>
      Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44745bd1
    • Lukas Wunner's avatar
      PCI: pciehp: Fix unprotected list iteration in IRQ handler · 86a3d597
      Lukas Wunner authored
      commit 1204e35b upstream.
      
      Commit b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
      events for a device") iterates over the devices on a hotplug port's
      subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
      It is thus possible for a user to cause a crash by concurrently
      manipulating the device list, e.g. by disabling slot power via sysfs
      on a different CPU or by initiating a remove/rescan via sysfs.
      
      This can't be fixed by acquiring pci_bus_sem because it may sleep.
      The simplest fix is to avoid the list iteration altogether and just
      check the ignore_hotplug flag on the port itself.  This works because
      pci_ignore_hotplug() sets the flag both on the device as well as on its
      parent bridge.
      
      We do lose the ability to print the name of the device blocking hotplug
      in the debug message, but that's probably bearable.
      
      Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86a3d597
    • Lukas Wunner's avatar
      PCI: pciehp: Fix use-after-free on unplug · 3fcdcdd5
      Lukas Wunner authored
      commit 281e878e upstream.
      
      When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
      hotplug_slot struct is deregistered and thus freed before freeing the
      IRQ.  The IRQ handler and the work items it schedules print the slot
      name referenced from the freed structure in various informational and
      debug log messages, each time resulting in a quadruple dereference of
      freed pointers (hotplug_slot -> pci_slot -> kobject -> name).
      
      At best the slot name is logged as "(null)", at worst kernel memory is
      exposed in logs or the driver crashes:
      
        pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present
      
      An attacker may provoke the bug by unplugging multiple devices on a
      Thunderbolt daisy chain at once.  Unplugging can also be simulated by
      powering down slots via sysfs.  The bug is particularly easy to trigger
      in poll mode.
      
      It has been present since the driver's introduction in 2004:
      https://git.kernel.org/tglx/history/c/c16b4b14d980
      
      Fix by rearranging teardown such that the IRQ is freed first.  Run the
      work items queued by the IRQ handler to completion before freeing the
      hotplug_slot struct by draining the work queue from the ->release_slot
      callback which is invoked by pci_hp_deregister().
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.6.4
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fcdcdd5