1. 24 Aug, 2018 23 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.18.5 · 96158f3a
      Greg Kroah-Hartman authored
      96158f3a
    • Jann Horn's avatar
      reiserfs: fix broken xattr handling (heap corruption, bad retval) · 0d63520b
      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>
      0d63520b
    • Esben Haabendal's avatar
      i2c: imx: Fix race condition in dma read · 7bc1a91a
      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>
      7bc1a91a
    • Hans de Goede's avatar
      i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes · 32d9b363
      Hans de Goede authored
      commit c463a158
      
       upstream.
      
      acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
      is the number of transfers executed on success, so 1.
      
      The ACPI code expects us to store 0 in gsb->status for success, not 1.
      
      Specifically this breaks the following code in the Thinkpad 8 DSDT:
      
                  ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
                  If ((ECST == Zero))
                  {
                      ECRD = I2CR /* \_SB_.I2C1.I2CR */
                  }
      
      Before this commit we set ECST to 1, causing the read to never happen
      breaking battery monitoring on the Thinkpad 8.
      
      This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
      returns 1, so the single write transfer completed successfully, and
      makes it return -EIO on for other (unexpected) return values >= 0.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32d9b363
    • Lukas Wunner's avatar
      PCI: pciehp: Fix unprotected list iteration in IRQ handler · 8c1bd0d0
      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>
      8c1bd0d0
    • Lukas Wunner's avatar
      PCI: pciehp: Fix use-after-free on unplug · 2de0279a
      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>
      2de0279a
    • Myron Stowe's avatar
      PCI: Skip MPS logic for Virtual Functions (VFs) · d2d937b7
      Myron Stowe authored
      commit 3dbe97ef upstream.
      
      PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
      Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
      VFs.  Just prior to the table it states:
      
        "PF and VF functionality is defined in Section 7.5.3.4 except where
         noted in Table 9-16.  For VF fields marked 'RsvdP', the PF setting
         applies to the VF."
      
      All of which implies that with respect to Max_Payload_Size Supported
      (MPSS), MPS, and MRRS values, we should not be paying any attention to the
      VF's fields, but rather only to the PF's.  Only looking at the PF's fields
      also logically makes sense as it's the sole physical interface to the PCIe
      bus.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
      Fixes: 27d868b5
      
       ("PCI: Set MPS to match upstream bridge")
      Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # 4.3+
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Sinan Kaya <okaya@kernel.org>
      Cc: Dongdong Liu <liudongdong3@huawei.com>
      Cc: Jon Mason <jdmason@kudzu.us>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2d937b7
    • Zachary Zhang's avatar
      PCI: aardvark: Size bridges before resources allocation · 16558e4d
      Zachary Zhang authored
      commit 91a2968e upstream.
      
      The PCIE I/O and MEM resource allocation mechanism is that root bus
      goes through the following steps:
      
      1. Check PCI bridges' range and computes I/O and Mem base/limits.
      
      2. Sort all subordinate devices I/O and MEM resource requirements and
         allocate the resources and writes/updates subordinate devices'
         requirements to PCI bridges I/O and Mem MEM/limits registers.
      
      Currently, PCI Aardvark driver only handles the second step and lacks
      the first step, so there is an I/O and MEM resource allocation failure
      when using a PCI switch. This commit fixes that by sizing bridges
      before doing the resource allocation.
      
      Fixes: 8c39d710
      
       ("PCI: aardvark: Add Aardvark PCI host controller
      driver")
      Signed-off-by: default avatarZachary Zhang <zhangzg@marvell.com>
      [Thomas: edit commit log.]
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16558e4d
    • Lukas Wunner's avatar
      PCI: hotplug: Don't leak pci_slot on registration failure · dabfad3c
      Lukas Wunner authored
      commit 4ce64358 upstream.
      
      If addition of sysfs files fails on registration of a hotplug slot, the
      struct pci_slot as well as the entry in the slot_list is leaked.  The
      issue has been present since the hotplug core was introduced in 2002:
      https://git.kernel.org/tglx/history/c/a8a2069f432c
      
      
      
      Perhaps the idea was that even though sysfs addition fails, the slot
      should still be usable.  But that's not how drivers use the interface,
      they abort probe if a non-zero value is returned.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.4.15+
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dabfad3c
    • Rafael J. Wysocki's avatar
      PCI / ACPI / PM: Resume all bridges on suspend-to-RAM · 4d4306a2
      Rafael J. Wysocki authored
      commit 9d64b539 upstream.
      
      Commit 26112ddc (PCI / ACPI / PM: Resume bridges w/o drivers on
      suspend-to-RAM) attempted to fix a functional regression resulting
      from commit c62ec461 (PM / core: Fix direct_complete handling
      for devices with no callbacks) by resuming PCI bridges without
      drivers (that is, "parallel PCI" ones) during system-wide suspend if
      the target system state is not ACPI S0 (working state).
      
      That turns out insufficient, however, as it is reported that, at
      least in one case, the platform firmware gets confused if a PCIe
      root port is suspended before entering the ACPI S3 sleep state.
      That issue was exposed by commit 77b3729ca03 (PCI / PM: Use
      SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) that allowed
      PCIe ports to stay in runtime suspend during system-wide suspend
      (which is OK for suspend-to-idle, but turns out to be problematic
      otherwise).
      
      For this reason, drop the driver check from acpi_pci_need_resume()
      and resume all bridges (including PCIe ports with drivers) during
      system-wide suspend if the target system state is not ACPI S0.
      
      [If the target system state is ACPI S0, it means suspend-to-idle
       and the platform firmware is not going to be invoked to actually
       suspend the system, so there is no need to resume the bridges in
       that case.]
      
      Fixes: 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200675
      
      Reported-by: default avatarteika kazura <teika@gmx.com>
      Tested-by: default avatarteika kazura <teika@gmx.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: 4.16+ <stable@vger.kernel.org> # 4.16+: 26112ddc
      
       (PCI / ACPI / PM: Resume bridges ...)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d4306a2
    • Christian König's avatar
      PCI: Restore resized BAR state on resume · 473af290
      Christian König authored
      commit d3252ace upstream.
      
      Resize BARs after resume to the expected size again.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
      Fixes: d6895ad3 ("drm/amdgpu: resize VRAM BAR for CPU access v6")
      Fixes: 276b738d
      
       ("PCI: Add resizable BAR infrastructure")
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org      # v4.15+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      473af290
    • John David Anglin's avatar
      parisc: Remove ordered stores from syscall.S · 96be7bbd
      John David Anglin authored
      commit 7797167f
      
       upstream.
      
      Now that we use a sync prior to releasing the locks in syscall.S, we don't need
      the PA 2.0 ordered stores used to release some locks.  Using an ordered store,
      potentially slows the release and subsequent code.
      
      There are a number of other ordered stores and loads that serve no purpose.  I
      have converted these to normal stores.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.0+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96be7bbd
    • John David Anglin's avatar
      parisc: Remove unnecessary barriers from spinlock.h · e1d35a1a
      John David Anglin authored
      commit 3b885ac1
      
       upstream.
      
      Now that mb() is an instruction barrier, it will slow performance if we issue
      unnecessary barriers.
      
      The spinlock defines have a number of unnecessary barriers.  The __ldcw()
      define is both a hardware and compiler barrier.  The mb() barriers in the
      routines using __ldcw() serve no purpose.
      
      The only barrier needed is the one in arch_spin_unlock().  We need to ensure
      all accesses are complete prior to releasing the lock.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.0+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1d35a1a
    • Gustavo A. R. Silva's avatar
      drm/amdgpu/pm: Fix potential Spectre v1 · 3df731e0
      Gustavo A. R. Silva authored
      commit ddf74e79 upstream.
      
      idx 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:
      
      drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state()
      warn: potential spectre issue 'data.states'
      
      Fix this by sanitizing idx before using it to index data.states
      
      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 avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3df731e0
    • Gustavo A. R. Silva's avatar
      drm/i915/kvmgt: Fix potential Spectre v1 · d8a1aeca
      Gustavo A. R. Silva authored
      commit de5372da upstream.
      
      info.index 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:
      
      drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
      potential spectre issue 'vgpu->vdev.region' [r]
      
      Fix this by sanitizing info.index before indirectly using it to index
      vgpu->vdev.region
      
      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 avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8a1aeca
    • Jeremy Cline's avatar
      ext4: fix spectre gadget in ext4_mb_regular_allocator() · 5b6ea348
      Jeremy Cline authored
      commit 1a5d5e5d
      
       upstream.
      
      'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the
      derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to
      index arrays which makes it a potential spectre gadget. Fix this by
      sanitizing the value assigned to 'ac->ac2_order'.  This covers the
      following accesses found with the help of smatch:
      
      * fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential
        spectre issue 'grp->bb_counters' [w] (local cap)
      
      * fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue
        'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap)
      
      * fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue
        'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap)
      Suggested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: Greg Kroah-Hartman <gregkh@l...
      5b6ea348
    • Michael Ellerman's avatar
      powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2 · 5bd4084f
      Michael Ellerman authored
      commit 6d44acae upstream.
      
      When I added the spectre_v2 information in sysfs, I included the
      availability of the ori31 speculation barrier.
      
      Although the ori31 barrier can be used to mitigate v2, it's primarily
      intended as a spectre v1 mitigation. Spectre v2 is mitigated by
      hardware changes.
      
      So rework the sysfs files to show the ori31 information in the
      spectre_v1 file, rather than v2.
      
      Currently we display eg:
      
        $ grep . spectre_v*
        spectre_v1:Mitigation: __user pointer sanitization
        spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation barrier enabled
      
      After:
      
        $ grep . spectre_v*
        spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier enabled
        spectre_v2:Mitigation: Indirect branch cache disabled
      
      Fixes: d6fbe1c5
      
       ("powerpc/64s: Wire up cpu_show_spectre_v2()")
      Cc: stable@vger.kernel.org # v4.17+
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5bd4084f
    • Dave Hansen's avatar
      x86/mm/init: Remove freed kernel image areas from alias mapping · c2d73c25
      Dave Hansen authored
      commit c40a56a7 upstream.
      
      The kernel image is mapped into two places in the virtual address space
      (addresses without KASLR, of course):
      
      	1. The kernel direct map (0xffff880000000000)
      	2. The "high kernel map" (0xffffffff81000000)
      
      We actually execute out of #2.  If we get the address of a kernel symbol,
      it points to #2, but almost all physical-to-virtual translations point to
      
      Parts of the "high kernel map" alias are mapped in the userspace page
      tables with the Global bit for performance reasons.  The parts that we map
      to userspace do not (er, should not) have secrets. When PTI is enabled then
      the global bit is usually not set in the high mapping and just used to
      compensate for poor performance on systems which lack PCID.
      
      This is fine, except that some areas in the kernel image that are adjacent
      to the non-secret-containing areas are unused holes.  We free these holes
      back into the normal page allocator and reuse them as normal kernel memory.
      The memory will, of course, get *used* via the normal map, but the alias
      mapping is kept.
      
      This otherwise unused alias mapping of the holes will, by default keep the
      Global bit, be mapped out to userspace, and be vulnerable to Meltdown.
      
      Remove the alias mapping of these pages entirely.  This is likely to
      fracture the 2M page mapping the kernel image near these areas, but this
      should affect a minority of the area.
      
      The pageattr code changes *all* aliases mapping the physical pages that it
      operates on (by default).  We only want to modify a single alias, so we
      need to tweak its behavior.
      
      This unmapping behavior is currently dependent on PTI being in place.
      Going forward, we should at least consider doing this for all
      configurations.  Having an extra read-write alias for memory is not exactly
      ideal for debugging things like random memory corruption and this does
      undercut features like DEBUG_PAGEALLOC or future work like eXclusive Page
      Frame Ownership (XPFO).
      
      Before this patch:
      
      current_kernel:---[ High Kernel Mapping ]---
      current_kernel-0xffffffff80000000-0xffffffff81000000          16M                               pmd
      current_kernel-0xffffffff81000000-0xffffffff81e00000          14M     ro         PSE     GLB x  pmd
      current_kernel-0xffffffff81e00000-0xffffffff81e11000          68K     ro                 GLB x  pte
      current_kernel-0xffffffff81e11000-0xffffffff82000000        1980K     RW                     NX pte
      current_kernel-0xffffffff82000000-0xffffffff82600000           6M     ro         PSE     GLB NX pmd
      current_kernel-0xffffffff82600000-0xffffffff82c00000           6M     RW         PSE         NX pmd
      current_kernel-0xffffffff82c00000-0xffffffff82e00000           2M     RW                     NX pte
      current_kernel-0xffffffff82e00000-0xffffffff83200000           4M     RW         PSE         NX pmd
      current_kernel-0xffffffff83200000-0xffffffffa0000000         462M                               pmd
      
        current_user:---[ High Kernel Mapping ]---
        current_user-0xffffffff80000000-0xffffffff81000000          16M                               pmd
        current_user-0xffffffff81000000-0xffffffff81e00000          14M     ro         PSE     GLB x  pmd
        current_user-0xffffffff81e00000-0xffffffff81e11000          68K     ro                 GLB x  pte
        current_user-0xffffffff81e11000-0xffffffff82000000        1980K     RW                     NX pte
        current_user-0xffffffff82000000-0xffffffff82600000           6M     ro         PSE     GLB NX pmd
        current_user-0xffffffff82600000-0xffffffffa0000000         474M                               pmd
      
      After this patch:
      
      current_kernel:---[ High Kernel Mapping ]---
      current_kernel-0xffffffff80000000-0xffffffff81000000          16M                               pmd
      current_kernel-0xffffffff81000000-0xffffffff81e00000          14M     ro         PSE     GLB x  pmd
      current_kernel-0xffffffff81e00000-0xffffffff81e11000          68K     ro                 GLB x  pte
      current_kernel-0xffffffff81e11000-0xffffffff82000000        1980K                               pte
      current_kernel-0xffffffff82000000-0xffffffff82400000           4M     ro         PSE     GLB NX pmd
      current_kernel-0xffffffff82400000-0xffffffff82488000         544K     ro                     NX pte
      current_kernel-0xffffffff82488000-0xffffffff82600000        1504K                               pte
      current_kernel-0xffffffff82600000-0xffffffff82c00000           6M     RW         PSE         NX pmd
      current_kernel-0xffffffff82c00000-0xffffffff82c0d000          52K     RW                     NX pte
      current_kernel-0xffffffff82c0d000-0xffffffff82dc0000        1740K                               pte
      
        current_user:---[ High Kernel Mapping ]---
        current_user-0xffffffff80000000-0xffffffff81000000          16M                               pmd
        current_user-0xffffffff81000000-0xffffffff81e00000          14M     ro         PSE     GLB x  pmd
        current_user-0xffffffff81e00000-0xffffffff81e11000          68K     ro                 GLB x  pte
        current_user-0xffffffff81e11000-0xffffffff82000000        1980K                               pte
        current_user-0xffffffff82000000-0xffffffff82400000           4M     ro         PSE     GLB NX pmd
        current_user-0xffffffff82400000-0xffffffff82488000         544K     ro                     NX pte
        current_user-0xffffffff82488000-0xffffffff82600000        1504K                               pte
        current_user-0xffffffff82600000-0xffffffffa0000000         474M                               pmd
      
      [ tglx: Do not unmap on 32bit as there is only one mapping ]
      
      Fixes: 0f561fce
      
       ("x86/pti: Enable global pages for shared areas")
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Kees Cook <keescook@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Link: https://lkml.kernel.org/r/20180802225831.5F6A2BFC@viggo.jf.intel.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2d73c25
    • Dave Hansen's avatar
      x86/mm/init: Add helper for freeing kernel image pages · a01cdb47
      Dave Hansen authored
      commit 6ea2738e
      
       upstream.
      
      When chunks of the kernel image are freed, free_init_pages() is used
      directly.  Consolidate the three sites that do this.  Also update the
      string to give an incrementally better description of that memory versus
      what was there before.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: keescook@google.com
      Cc: aarcange@redhat.com
      Cc: jgross@suse.com
      Cc: jpoimboe@redhat.com
      Cc: gregkh@linuxfoundation.org
      Cc: peterz@infradead.org
      Cc: hughd@google.com
      Cc: torvalds@linux-foundation.org
      Cc: bp@alien8.de
      Cc: luto@kernel.org
      Cc: ak@linux.intel.com
      Cc: Kees Cook <keescook@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: https://lkml.kernel.org/r/20180802225829.FE0E32EA@viggo.jf.intel.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a01cdb47
    • Dave Hansen's avatar
      x86/mm/init: Pass unconverted symbol addresses to free_init_pages() · 22ddf852
      Dave Hansen authored
      commit 9f515cdb
      
       upstream.
      
      The x86 code has several places where it frees parts of kernel image:
      
       1. Unused SMP alternative
       2. __init code
       3. The hole between text and rodata
       4. The hole between rodata and data
      
      We call free_init_pages() to do this.  Strangely, we convert the symbol
      addresses to kernel direct map addresses in some cases (#3, #4) but not
      others (#1, #2).
      
      The virt_to_page() and the other code in free_reserved_area() now works
      fine for for symbol addresses on x86, so don't bother converting the
      addresses to direct map addresses before freeing them.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: keescook@google.com
      Cc: aarcange@redhat.com
      Cc: jgross@suse.com
      Cc: jpoimboe@redhat.com
      Cc: gregkh@linuxfoundation.org
      Cc: peterz@infradead.org
      Cc: hughd@google.com
      Cc: torvalds@linux-foundation.org
      Cc: bp@alien8.de
      Cc: luto@kernel.org
      Cc: ak@linux.intel.com
      Cc: Kees Cook <keescook@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: https://lkml.kernel.org/r/20180802225828.89B2D0E2@viggo.jf.intel.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22ddf852
    • Dave Hansen's avatar
      mm: Allow non-direct-map arguments to free_reserved_area() · 0a57c747
      Dave Hansen authored
      commit 0d834328
      
       upstream.
      
      free_reserved_area() takes pointers as arguments to show which addresses
      should be freed.  However, it does this in a somewhat ambiguous way.  If it
      gets a kernel direct map address, it always works.  However, if it gets an
      address that is part of the kernel image alias mapping, it can fail.
      
      It fails if all of the following happen:
       * The specified address is part of the kernel image alias
       * Poisoning is requested (forcing a memset())
       * The address is in a read-only portion of the kernel image
      
      The memset() fails on the read-only mapping, of course.
      free_reserved_area() *is* called both on the direct map and on kernel image
      alias addresses.  We've just lucked out thus far that the kernel image
      alias areas it gets used on are read-write.  I'm fairly sure this has been
      just a happy accident.
      
      It is quite easy to make free_reserved_area() work for all cases: just
      convert the address to a direct map address before doing the memset(), and
      do this unconditionally.  There is little chance of a regression here
      because we previously did a virt_to_page() on the address for the memset,
      so we know these are not highmem pages for which virt_to_page() would fail.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: keescook@google.com
      Cc: aarcange@redhat.com
      Cc: jgross@suse.com
      Cc: jpoimboe@redhat.com
      Cc: gregkh@linuxfoundation.org
      Cc: peterz@infradead.org
      Cc: hughd@google.com
      Cc: torvalds@linux-foundation.org
      Cc: bp@alien8.de
      Cc: luto@kernel.org
      Cc: ak@linux.intel.com
      Cc: Kees Cook <keescook@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: https://lkml.kernel.org/r/20180802225826.1287AE3E@viggo.jf.intel.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a57c747
    • Matthijs van Duin's avatar
      pty: fix O_CLOEXEC for TIOCGPTPEER · 2114c718
      Matthijs van Duin authored
      commit 36ecc148 upstream.
      
      It was being ignored because the flags were not passed to fd allocation.
      
      Fixes: 54ebbfb1
      
       ("tty: add TIOCGPTPEER ioctl")
      Signed-off-by: default avatarMatthijs van Duin <matthijsvanduin@gmail.com>
      Acked-by: default avatarAleksa Sarai <asarai@suse.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2114c718
    • Takashi Iwai's avatar
      EDAC: Add missing MEM_LRDDR4 entry in edac_mem_types[] · 48cf4d45
      Takashi Iwai authored
      commit b748f2de
      
       upstream.
      
      The edac_mem_types[] array misses a MEM_LRDDR4 entry, which leads to
      NULL pointer dereference when accessed via sysfs or such.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/20180810141426.8918-1-tiwai@suse.de
      Fixes: 1e8096bb
      
       ("EDAC: Add LRDDR4 DRAM type")
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48cf4d45
  2. 22 Aug, 2018 17 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.18.4 · 28b2837b
      Greg Kroah-Hartman authored
      28b2837b
    • Hangbin Liu's avatar
      cls_matchall: fix tcf_unbind_filter missing · b1246ef7
      Hangbin Liu authored
      [ Upstream commit a51c76b4 ]
      
      Fix tcf_unbind_filter missing in cls_matchall as this will trigger
      WARN_ON() in cbq_destroy_class().
      
      Fixes: fd62d9f5
      
       ("net/sched: matchall: Fix configuration race")
      Reported-by: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1246ef7
    • Jisheng Zhang's avatar
      net: mvneta: fix mvneta_config_rss on armada 3700 · ffbc6163
      Jisheng Zhang authored
      [ Upstream commit 0f5c6c30
      
       ]
      
      The mvneta Ethernet driver is used on a few different Marvell SoCs.
      Some SoCs have per cpu interrupts for Ethernet events, the driver uses
      a per CPU napi structure for this case. Some SoCs such as armada 3700
      have a single interrupt for Ethernet events, the driver uses a global
      napi structure for this case.
      
      Current mvneta_config_rss() always operates the per cpu napi structure.
      Fix it by operating a global napi for "single interrupt" case, and per
      cpu napi structure for remaining cases.
      Signed-off-by: default avatarJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Fixes: 2636ac3c
      
       ("net: mvneta: Add network support for Armada 3700 SoC")
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffbc6163
    • Andrew Lunn's avatar
      net: ethernet: mvneta: Fix napi structure mixup on armada 3700 · 298f83fe
      Andrew Lunn authored
      [ Upstream commit 7a86f05f
      
       ]
      
      The mvneta Ethernet driver is used on a few different Marvell SoCs.
      Some SoCs have per cpu interrupts for Ethernet events. Some SoCs have
      a single interrupt, independent of the CPU. The driver handles this by
      having a per CPU napi structure when there are per CPU interrupts, and
      a global napi structure when there is a single interrupt.
      
      When the napi core calls mvneta_poll(), it passes the napi
      instance. This was not being propagated through the call chain, and
      instead the per-cpu napi instance was passed to napi_gro_receive()
      call. This breaks when there is a single global napi instance.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Fixes: 2636ac3c
      
       ("net: mvneta: Add network support for Armada 3700 SoC")
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      298f83fe
    • Haishuang Yan's avatar
      ip_vti: fix a null pointer deferrence when create vti fallback tunnel · 043b985f
      Haishuang Yan authored
      [ Upstream commit cd1aa9c2 ]
      
      After set fb_tunnels_only_for_init_net to 1, the itn->fb_tunnel_dev will
      be NULL and will cause following crash:
      
      [ 2742.849298] BUG: unable to handle kernel NULL pointer dereference at 0000000000000941
      [ 2742.851380] PGD 800000042c21a067 P4D 800000042c21a067 PUD 42aaed067 PMD 0
      [ 2742.852818] Oops: 0002 [#1] SMP PTI
      [ 2742.853570] CPU: 7 PID: 2484 Comm: unshare Kdump: loaded Not tainted 4.18.0-rc8+ #2
      [ 2742.855163] Hardware name: Fedora Project OpenStack Nova, BIOS seabios-1.7.5-11.el7 04/01/2014
      [ 2742.856970] RIP: 0010:vti_init_net+0x3a/0x50 [ip_vti]
      [ 2742.858034] Code: 90 83 c0 48 c7 c2 20 a1 83 c0 48 89 fb e8 6e 3b f6 ff 85 c0 75 22 8b 0d f4 19 00 00 48 8b 93 00 14 00 00 48 8b 14 ca 48 8b 12 <c6> 82 41 09 00 00 04 c6 82 38 09 00 00 45 5b c3 66 0f 1f 44 00 00
      [ 2742.861940] RSP: 0018:ffff9be28207fde0 EFLAGS: 00010246
      [ 2742.863044] RAX: 0000000000000000 RBX: ffff8a71ebed4980 RCX: 0000000000000013
      [ 2742.864540] RDX: 0000000000000000 RSI: 0000000000000013 RDI: ffff8a71ebed4980
      [ 2742.866020] RBP: ffff8a71ea717000 R08: ffffffffc083903c R09: ffff8a71ea717000
      [ 2742.867505] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a71ebed4980
      [ 2742.868987] R13: 0000000000000013 R14: ffff8a71ea5b49c0 R15: 0000000000000000
      [ 2742.870473] FS:  00007f02266c9740(0000) GS:ffff8a71ffdc0000(0000) knlGS:0000000000000000
      [ 2742.872143] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2742.873340] CR2: 0000000000000941 CR3: 000000042bc20006 CR4: 00000000001606e0
      [ 2742.874821] Call Trace:
      [ 2742.875358]  ops_init+0x38/0xf0
      [ 2742.876078]  setup_net+0xd9/0x1f0
      [ 2742.876789]  copy_net_ns+0xb7/0x130
      [ 2742.877538]  create_new_namespaces+0x11a/0x1d0
      [ 2742.878525]  unshare_nsproxy_namespaces+0x55/0xa0
      [ 2742.879526]  ksys_unshare+0x1a7/0x330
      [ 2742.880313]  __x64_sys_unshare+0xe/0x20
      [ 2742.881131]  do_syscall_64+0x5b/0x180
      [ 2742.881933]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reproduce:
      echo 1 > /proc/sys/net/core/fb_tunnels_only_for_init_net
      modprobe ip_vti
      unshare -n
      
      Fixes: 79134e6c
      
       ("net: do not create fallback tunnels for non-default namespaces")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      043b985f
    • Jian-Hong Pan's avatar
      r8169: don't use MSI-X on RTL8106e · 63d60df1
      Jian-Hong Pan authored
      [ Upstream commit 7bb05b85 ]
      
      Found the ethernet network on ASUS X441UAR doesn't come back on resume
      from suspend when using MSI-X.  The chip is RTL8106e - version 39.
      
      [   21.848357] libphy: r8169: probed
      [   21.848473] r8169 0000:02:00.0 eth0: RTL8106e, 0c:9d:92:32:67:b4, XID
      44900000, IRQ 127
      [   22.518860] r8169 0000:02:00.0 enp2s0: renamed from eth0
      [   29.458041] Generic PHY r8169-200:00: attached PHY driver [Generic
      PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
      [   63.227398] r8169 0000:02:00.0 enp2s0: Link is Up - 100Mbps/Full -
      flow control off
      [  124.514648] Generic PHY r8169-200:00: attached PHY driver [Generic
      PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
      
      Here is the ethernet controller in detail:
      
      02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
      RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136]
      (rev 07)
      	Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast
      Ethernet controller [1043:200f]
      	Flags: bus master, fast devsel, latency 0, IRQ 16
      	I/O ports at e000 [size=256]
      	Memory at ef100000 (64-bit, non-prefetchable) [size=4K]
      	Memory at e0000000 (64-bit, prefetchable) [size=16K]
      	Capabilities: <access denied>
      	Kernel driver in use: r8169
      	Kernel modules: r8169
      
      Falling back to MSI fixes the issue.
      
      Fixes: 6c6aa15f
      
       ("r8169: improve interrupt handling")
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63d60df1
    • Takashi Iwai's avatar
      hv/netvsc: Fix NULL dereference at single queue mode fallback · 6f560142
      Takashi Iwai authored
      [ Upstream commit b19b4634 ]
      
      The recent commit 916c5e14 ("hv/netvsc: fix handling of fallback
      to single queue mode") tried to fix the fallback behavior to a single
      queue mode, but it changed the function to return zero incorrectly,
      while the function should return an object pointer.  Eventually this
      leads to a NULL dereference at the callers that expect non-NULL
      value.
      
      Fix it by returning the proper net_device object.
      
      Fixes: 916c5e14
      
       ("hv/netvsc: fix handling of fallback to single queue mode")
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Reviewed-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f560142
    • Jeremy Cline's avatar
      net: sock_diag: Fix spectre v1 gadget in __sock_diag_cmd() · cd0fb1cb
      Jeremy Cline authored
      [ Upstream commit 66b51b0a ]
      
      req->sdiag_family is a user-controlled value that's used as an array
      index. Sanitize it after the bounds check to avoid speculative
      out-of-bounds array access.
      
      This also protects the sock_is_registered() call, so this removes the
      sanitize call there.
      
      Fixes: e978de7a
      
       ("net: socket: Fix potential spectre v1 gadget in sock_is_registered")
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: konrad.wilk@oracle.com
      Cc: jamie.iles@oracle.com
      Cc: liran.alon@oracle.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd0fb1cb
    • Kees Cook's avatar
      isdn: Disable IIOCDBGVAR · 3909ccf1
      Kees Cook authored
      [ Upstream commit 5e22002a
      
       ]
      
      It was possible to directly leak the kernel address where the isdn_dev
      structure pointer was stored. This is a kernel ASLR bypass for anyone
      with access to the ioctl. The code had been present since the beginning
      of git history, though this shouldn't ever be needed for normal operation,
      therefore remove it.
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3909ccf1
    • Sudip Mukherjee's avatar
      Bluetooth: avoid killing an already killed socket · 2b9ffbf2
      Sudip Mukherjee authored
      commit 4e1a720d
      
       upstream.
      
      slub debug reported:
      
      [  440.648642] =============================================================================
      [  440.648649] BUG kmalloc-1024 (Tainted: G    BU     O   ): Poison overwritten
      [  440.648651] -----------------------------------------------------------------------------
      
      [  440.648655] INFO: 0xe70f4bec-0xe70f4bec. First byte 0x6a instead of 0x6b
      [  440.648665] INFO: Allocated in sk_prot_alloc+0x6b/0xc6 age=33155 cpu=1 pid=1047
      [  440.648671] 	___slab_alloc.constprop.24+0x1fc/0x292
      [  440.648675] 	__slab_alloc.isra.18.constprop.23+0x1c/0x25
      [  440.648677] 	__kmalloc+0xb6/0x17f
      [  440.648680] 	sk_prot_alloc+0x6b/0xc6
      [  440.648683] 	sk_alloc+0x1e/0xa1
      [  440.648700] 	sco_sock_alloc.constprop.6+0x26/0xaf [bluetooth]
      [  440.648716] 	sco_connect_cfm+0x166/0x281 [bluetooth]
      [  440.648731] 	hci_conn_request_evt.isra.53+0x258/0x281 [bluetooth]
      [  440.648746] 	hci_event_packet+0x28b/0x2326 [bluetooth]
      [  440.648759] 	hci_rx_work+0x161/0x291 [bluetooth]
      [  440.648764] 	process_one_work+0x163/0x2b2
      [  440.648767] 	worker_thread+0x1a9/0x25c
      [  440.648770] 	kthread+0xf8/0xfd
      [  440.648774] 	ret_from_fork+0x2e/0x38
      [  440.648779] INFO: Freed in __sk_destruct+0xd3/0xdf age=3815 cpu=1 pid=1047
      [  440.648782] 	__slab_free+0x4b/0x27a
      [  440.648784] 	kfree+0x12e/0x155
      [  440.648787] 	__sk_destruct+0xd3/0xdf
      [  440.648790] 	sk_destruct+0x27/0x29
      [  440.648793] 	__sk_free+0x75/0x91
      [  440.648795] 	sk_free+0x1c/0x1e
      [  440.648810] 	sco_sock_kill+0x5a/0x5f [bluetooth]
      [  440.648825] 	sco_conn_del+0x8e/0xba [bluetooth]
      [  440.648840] 	sco_disconn_cfm+0x3a/0x41 [bluetooth]
      [  440.648855] 	hci_event_packet+0x45e/0x2326 [bluetooth]
      [  440.648868] 	hci_rx_work+0x161/0x291 [bluetooth]
      [  440.648872] 	process_one_work+0x163/0x2b2
      [  440.648875] 	worker_thread+0x1a9/0x25c
      [  440.648877] 	kthread+0xf8/0xfd
      [  440.648880] 	ret_from_fork+0x2e/0x38
      [  440.648884] INFO: Slab 0xf4718580 objects=27 used=27 fp=0x  (null) flags=0x40008100
      [  440.648886] INFO: Object 0xe70f4b88 @offset=19336 fp=0xe70f54f8
      
      When KASAN was enabled, it reported:
      
      [  210.096613] ==================================================================
      [  210.096634] BUG: KASAN: use-after-free in ex_handler_refcount+0x5b/0x127
      [  210.096641] Write of size 4 at addr ffff880107e17160 by task kworker/u9:1/2040
      
      [  210.096651] CPU: 1 PID: 2040 Comm: kworker/u9:1 Tainted: G     U     O    4.14.47-20180606+ #2
      [  210.096654] Hardware name: , BIOS 2017.01-00087-g43e04de 08/30/2017
      [  210.096693] Workqueue: hci0 hci_rx_work [bluetooth]
      [  210.096698] Call Trace:
      [  210.096711]  dump_stack+0x46/0x59
      [  210.096722]  print_address_description+0x6b/0x23b
      [  210.096729]  ? ex_handler_refcount+0x5b/0x127
      [  210.096736]  kasan_report+0x220/0x246
      [  210.096744]  ex_handler_refcount+0x5b/0x127
      [  210.096751]  ? ex_handler_clear_fs+0x85/0x85
      [  210.096757]  fixup_exception+0x8c/0x96
      [  210.096766]  do_trap+0x66/0x2c1
      [  210.096773]  do_error_trap+0x152/0x180
      [  210.096781]  ? fixup_bug+0x78/0x78
      [  210.096817]  ? hci_debugfs_create_conn+0x244/0x26a [bluetooth]
      [  210.096824]  ? __schedule+0x113b/0x1453
      [  210.096830]  ? sysctl_net_exit+0xe/0xe
      [  210.096837]  ? __wake_up_common+0x343/0x343
      [  210.096843]  ? insert_work+0x107/0x163
      [  210.096850]  invalid_op+0x1b/0x40
      [  210.096888] RIP: 0010:hci_debugfs_create_conn+0x244/0x26a [bluetooth]
      [  210.096892] RSP: 0018:ffff880094a0f970 EFLAGS: 00010296
      [  210.096898] RAX: 0000000000000000 RBX: ffff880107e170e8 RCX: ffff880107e17160
      [  210.096902] RDX: 000000000000002f RSI: ffff88013b80ed40 RDI: ffffffffa058b940
      [  210.096906] RBP: ffff88011b2b0578 R08: 00000000852f0ec9 R09: ffffffff81cfcf9b
      [  210.096909] R10: 00000000d21bdad7 R11: 0000000000000001 R12: ffff8800967b0488
      [  210.096913] R13: ffff880107e17168 R14: 0000000000000068 R15: ffff8800949c0008
      [  210.096920]  ? __sk_destruct+0x2c6/0x2d4
      [  210.096959]  hci_event_packet+0xff5/0x7de2 [bluetooth]
      [  210.096969]  ? __local_bh_enable_ip+0x43/0x5b
      [  210.097004]  ? l2cap_sock_recv_cb+0x158/0x166 [bluetooth]
      [  210.097039]  ? hci_le_meta_evt+0x2bb3/0x2bb3 [bluetooth]
      [  210.097075]  ? l2cap_ertm_init+0x94e/0x94e [bluetooth]
      [  210.097093]  ? xhci_urb_enqueue+0xbd8/0xcf5 [xhci_hcd]
      [  210.097102]  ? __accumulate_pelt_segments+0x24/0x33
      [  210.097109]  ? __accumulate_pelt_segments+0x24/0x33
      [  210.097115]  ? __update_load_avg_se.isra.2+0x217/0x3a4
      [  210.097122]  ? set_next_entity+0x7c3/0x12cd
      [  210.097128]  ? pick_next_entity+0x25e/0x26c
      [  210.097135]  ? pick_next_task_fair+0x2ca/0xc1a
      [  210.097141]  ? switch_mm_irqs_off+0x346/0xb4f
      [  210.097147]  ? __switch_to+0x769/0xbc4
      [  210.097153]  ? compat_start_thread+0x66/0x66
      [  210.097188]  ? hci_conn_check_link_mode+0x1cd/0x1cd [bluetooth]
      [  210.097195]  ? finish_task_switch+0x392/0x431
      [  210.097228]  ? hci_rx_work+0x154/0x487 [bluetooth]
      [  210.097260]  hci_rx_work+0x154/0x487 [bluetooth]
      [  210.097269]  process_one_work+0x579/0x9e9
      [  210.097277]  worker_thread+0x68f/0x804
      [  210.097285]  kthread+0x31c/0x32b
      [  210.097292]  ? rescuer_thread+0x70c/0x70c
      [  210.097299]  ? kthread_create_on_node+0xa3/0xa3
      [  210.097306]  ret_from_fork+0x35/0x40
      
      [  210.097314] Allocated by task 2040:
      [  210.097323]  kasan_kmalloc.part.1+0x51/0xc7
      [  210.097328]  __kmalloc+0x17f/0x1b6
      [  210.097335]  sk_prot_alloc+0xf2/0x1a3
      [  210.097340]  sk_alloc+0x22/0x297
      [  210.097375]  sco_sock_alloc.constprop.7+0x23/0x202 [bluetooth]
      [  210.097410]  sco_connect_cfm+0x2d0/0x566 [bluetooth]
      [  210.097443]  hci_conn_request_evt.isra.53+0x6d3/0x762 [bluetooth]
      [  210.097476]  hci_event_packet+0x85e/0x7de2 [bluetooth]
      [  210.097507]  hci_rx_work+0x154/0x487 [bluetooth]
      [  210.097512]  process_one_work+0x579/0x9e9
      [  210.097517]  worker_thread+0x68f/0x804
      [  210.097523]  kthread+0x31c/0x32b
      [  210.097529]  ret_from_fork+0x35/0x40
      
      [  210.097533] Freed by task 2040:
      [  210.097539]  kasan_slab_free+0xb3/0x15e
      [  210.097544]  kfree+0x103/0x1a9
      [  210.097549]  __sk_destruct+0x2c6/0x2d4
      [  210.097584]  sco_conn_del.isra.1+0xba/0x10e [bluetooth]
      [  210.097617]  hci_event_packet+0xff5/0x7de2 [bluetooth]
      [  210.097648]  hci_rx_work+0x154/0x487 [bluetooth]
      [  210.097653]  process_one_work+0x579/0x9e9
      [  210.097658]  worker_thread+0x68f/0x804
      [  210.097663]  kthread+0x31c/0x32b
      [  210.097670]  ret_from_fork+0x35/0x40
      
      [  210.097676] The buggy address belongs to the object at ffff880107e170e8
       which belongs to the cache kmalloc-1024 of size 1024
      [  210.097681] The buggy address is located 120 bytes inside of
       1024-byte region [ffff880107e170e8, ffff880107e174e8)
      [  210.097683] The buggy address belongs to the page:
      [  210.097689] page:ffffea00041f8400 count:1 mapcount:0 mapping:          (null) index:0xffff880107e15b68 compound_mapcount: 0
      [  210.110194] flags: 0x8000000000008100(slab|head)
      [  210.115441] raw: 8000000000008100 0000000000000000 ffff880107e15b68 0000000100170016
      [  210.115448] raw: ffffea0004a47620 ffffea0004b48e20 ffff88013b80ed40 0000000000000000
      [  210.115451] page dumped because: kasan: bad access detected
      
      [  210.115454] Memory state around the buggy address:
      [  210.115460]  ffff880107e17000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  210.115465]  ffff880107e17080: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
      [  210.115469] >ffff880107e17100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  210.115472]                                                        ^
      [  210.115477]  ffff880107e17180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  210.115481]  ffff880107e17200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [  210.115483] ==================================================================
      
      And finally when BT_DBG() and ftrace was enabled it showed:
      
             <...>-14979 [001] ....   186.104191: sco_sock_kill <-sco_sock_close
             <...>-14979 [001] ....   186.104191: sco_sock_kill <-sco_sock_release
             <...>-14979 [001] ....   186.104192: sco_sock_kill: sk ef0497a0 state 9
             <...>-14979 [001] ....   186.104193: bt_sock_unlink <-sco_sock_kill
      kworker/u9:2-792   [001] ....   186.104246: sco_sock_kill <-sco_conn_del
      kworker/u9:2-792   [001] ....   186.104248: sco_sock_kill: sk ef0497a0 state 9
      kworker/u9:2-792   [001] ....   186.104249: bt_sock_unlink <-sco_sock_kill
      kworker/u9:2-792   [001] ....   186.104250: sco_sock_destruct <-__sk_destruct
      kworker/u9:2-792   [001] ....   186.104250: sco_sock_destruct: sk ef0497a0
      kworker/u9:2-792   [001] ....   186.104860: hci_conn_del <-hci_event_packet
      kworker/u9:2-792   [001] ....   186.104864: hci_conn_del: hci0 hcon ef0484c0 handle 266
      
      Only in the failed case, sco_sock_kill() gets called with the same sock
      pointer two times. Add a check for SOCK_DEAD to avoid continue killing
      a socket which has already been killed.
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b9ffbf2
    • Xiubo Li's avatar
      Revert "uio: use request_threaded_irq instead" · a34e4f42
      Xiubo Li authored
      commit 3d27c4de upstream.
      
      Since mutex lock in irq hanler is useless currently, here will
      remove it together with it.
      
      This reverts commit 9421e45f
      
      .
      
      Reported-by: james.r.harris@intel.com
      CC: Ahsan Atta <ahsan.atta@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a34e4f42
    • Johan Hovold's avatar
      misc: sram: fix resource leaks in probe error path · 93e5f3d1
      Johan Hovold authored
      commit f294d009 upstream.
      
      Make sure to disable clocks and deregister any exported partitions
      before returning on late probe errors.
      
      Note that since commit ee895ccd
      
       ("misc: sram: fix enabled clock leak
      on error path"), partitions are deliberately exported before enabling
      the clock so we stick to that logic here. A follow up patch will address
      this.
      
      Cc: stable <stable@vger.kernel.org>     # 4.9
      Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93e5f3d1
    • Hailong Liu's avatar
      uio: fix wrong return value from uio_mmap() · 421483e0
      Hailong Liu authored
      commit e7de2590 upstream.
      
      uio_mmap has multiple fail paths to set return value to nonzero then
      goto out. However, it always returns *0* from the *out* at end, and
      this will mislead callers who check the return value of this function.
      
      Fixes: 57c5f4df
      
       ("uio: fix crash after the device is unregistered")
      CC: Xiubo Li <xiubli@redhat.com>
      Signed-off-by: default avatarHailong Liu <liu.hailong6@zte.com.cn>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJiang Biao <jiang.biao2@zte.com.cn>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      421483e0
    • Srinath Mannam's avatar
      serial: 8250_dw: Add ACPI support for uart on Broadcom SoC · 1d5fb78f
      Srinath Mannam authored
      commit 784c29ed
      
       upstream.
      
      Add ACPI identifier HID for UART DW 8250 on Broadcom SoCs
      to match the HID passed through ACPI tables to enable
      UART controller.
      Signed-off-by: default avatarSrinath Mannam <srinath.mannam@broadcom.com>
      Reviewed-by: default avatarVladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
      Tested-by: default avatarVladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d5fb78f
    • Chen Hu's avatar
      serial: 8250_dw: always set baud rate in dw8250_set_termios · 1964062d
      Chen Hu authored
      commit dfcab6ba
      
       upstream.
      
      dw8250_set_termios() doesn't set baud rate if the arg "old ktermios" is
      NULL. This happens during resume.
      Call Trace:
      ...
      [   54.928108] dw8250_set_termios+0x162/0x170
      [   54.928114] serial8250_set_termios+0x17/0x20
      [   54.928117] uart_change_speed+0x64/0x160
      [   54.928119] uart_resume_port
      ...
      
      So the baud rate is not restored after S3 and breaks the apps who use
      UART, for example, console and bluetooth etc.
      
      We address this issue by setting the baud rate irrespective of arg
      "old", just like the drivers for other 8250 IPs. This is tested with
      Intel Broxton platform.
      Signed-off-by: default avatarChen Hu <hu1.chen@intel.com>
      Fixes: 4e26b134
      
       ("serial: 8250_dw: clock rate handling for all ACPI platforms")
      Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1964062d
    • Aaron Sierra's avatar
      serial: 8250_exar: Read INT0 from slave device, too · 73f85a14
      Aaron Sierra authored
      commit 60ab0faf upstream.
      
      The sleep wake-up refactoring that I introduced in
      
        commit c7e1b405 ("tty: serial: exar: Relocate sleep wake-up handling")
      
      did not account for devices with a slave device on the expansion port.
      This patch pokes the INT0 register in the slave device, if present, in
      order to ensure that MSI interrupts don't get permanently "stuck"
      because of a sleep wake-up interrupt as described here:
      
        commit 2c0ac5b4
      
       ("serial: exar: Fix stuck MSIs")
      
      This also converts an ioread8() to readb() in order to provide visual
      consistency with the MMIO-only accessors used elsewhere in the driver.
      Reported-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarAaron Sierra <asierra@xes-inc.com>
      Fixes: c7e1b405
      
       ("tty: serial: exar: Relocate sleep wake-up handling")
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73f85a14
    • Mark's avatar
      tty: serial: 8250: Revert NXP SC16C2552 workaround · 47f7d1da
      Mark authored
      commit 47ac7666 upstream.
      
      Revert commit ecb988a3
      
      : tty: serial:
      8250: 8250_core: NXP SC16C2552 workaround
      
      The above commit causes userland application to no longer write
      correctly its first write to a dumb terminal connected to /dev/ttyS0.
      This commit seems to be the culprit. It's as though the TX FIFO is being
      reset during that write. What should be displayed is:
      
      PSW 80000000 INST 00000000                           HALT
      //
      
      What is displayed is some variation of:
      
      T 00000000           HAL//
      
      Reverting this commit via this patch fixes my problem.
      Signed-off-by: default avatarMark Hounschell <dmarkh@cfl.rr.com>
      Fixes: ecb988a3
      
       ("tty: serial: 8250: 8250_core: NXP SC16C2552 workaround")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47f7d1da