1. 29 Oct, 2019 40 commits
    • Patrick Williams's avatar
      pinctrl: armada-37xx: fix control of pins 32 and up · e0e489aa
      Patrick Williams authored
      commit 20504fa1 upstream.
      
      The 37xx configuration registers are only 32 bits long, so
      pins 32-35 spill over into the next register.  The calculation
      for the register address was done, but the bitmask was not, so
      any configuration to pin 32 or above resulted in a bitmask that
      overflowed and performed no action.
      
      Fix the register / offset calculation to also adjust the offset.
      
      Fixes: 5715092a ("pinctrl: armada-37xx: Add gpio support")
      Signed-off-by: default avatarPatrick Williams <alpawi@amazon.com>
      Acked-by: default avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191001154634.96165-1-alpawi@amazon.comSigned-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0e489aa
    • Dmitry Torokhov's avatar
      pinctrl: cherryview: restore Strago DMI workaround for all versions · 5e9d7180
      Dmitry Torokhov authored
      commit 260996c3 upstream.
      
      This is essentially a revert of:
      
      e3f72b74 pinctrl: cherryview: fix Strago DMI workaround
      86c5dd68 pinctrl: cherryview: limit Strago DMI workarounds to version 1.0
      
      because even with 1.1 versions of BIOS there are some pins that are
      configured as interrupts but not claimed by any driver, and they
      sometimes fire up and result in interrupt storms that cause touchpad
      stop functioning and other issues.
      
      Given that we are unlikely to qualify another firmware version for a
      while it is better to keep the workaround active on all Strago boards.
      Reported-by: default avatarAlex Levin <levinale@chromium.org>
      Fixes: 86c5dd68 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Tested-by: default avatarAlex Levin <levinale@chromium.org>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e9d7180
    • Sean Christopherson's avatar
      x86/apic/x2apic: Fix a NULL pointer deref when handling a dying cpu · 4dedaa73
      Sean Christopherson authored
      commit 7a22e03b upstream.
      
      Check that the per-cpu cluster mask pointer has been set prior to
      clearing a dying cpu's bit.  The per-cpu pointer is not set until the
      target cpu reaches smp_callin() during CPUHP_BRINGUP_CPU, whereas the
      teardown function, x2apic_dead_cpu(), is associated with the earlier
      CPUHP_X2APIC_PREPARE.  If an error occurs before the cpu is awakened,
      e.g. if do_boot_cpu() itself fails, x2apic_dead_cpu() will dereference
      the NULL pointer and cause a panic.
      
        smpboot: do_boot_cpu failed(-22) to wakeup CPU#1
        BUG: kernel NULL pointer dereference, address: 0000000000000008
        RIP: 0010:x2apic_dead_cpu+0x1a/0x30
        Call Trace:
         cpuhp_invoke_callback+0x9a/0x580
         _cpu_up+0x10d/0x140
         do_cpu_up+0x69/0xb0
         smp_init+0x63/0xa9
         kernel_init_freeable+0xd7/0x229
         ? rest_init+0xa0/0xa0
         kernel_init+0xa/0x100
         ret_from_fork+0x35/0x40
      
      Fixes: 023a6117 ("x86/apic/x2apic: Simplify cluster management")
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20191001205019.5789-1-sean.j.christopherson@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dedaa73
    • Steve Wahl's avatar
      x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area · 17099172
      Steve Wahl authored
      commit 2aa85f24 upstream.
      
      Our hardware (UV aka Superdome Flex) has address ranges marked
      reserved by the BIOS. Access to these ranges is caught as an error,
      causing the BIOS to halt the system.
      
      Initial page tables mapped a large range of physical addresses that
      were not checked against the list of BIOS reserved addresses, and
      sometimes included reserved addresses in part of the mapped range.
      Including the reserved range in the map allowed processor speculative
      accesses to the reserved range, triggering a BIOS halt.
      
      Used early in booting, the page table level2_kernel_pgt addresses 1
      GiB divided into 2 MiB pages, and it was set up to linearly map a full
       1 GiB of physical addresses that included the physical address range
      of the kernel image, as chosen by KASLR.  But this also included a
      large range of unused addresses on either side of the kernel image.
      And unlike the kernel image's physical address range, this extra
      mapped space was not checked against the BIOS tables of usable RAM
      addresses.  So there were times when the addresses chosen by KASLR
      would result in processor accessible mappings of BIOS reserved
      physical addresses.
      
      The kernel code did not directly access any of this extra mapped
      space, but having it mapped allowed the processor to issue speculative
      accesses into reserved memory, causing system halts.
      
      This was encountered somewhat rarely on a normal system boot, and much
      more often when starting the crash kernel if "crashkernel=512M,high"
      was specified on the command line (this heavily restricts the physical
      address of the crash kernel, in our case usually within 1 GiB of
      reserved space).
      
      The solution is to invalidate the pages of this table outside the kernel
      image's space before the page table is activated. It fixes this problem
      on our hardware.
      
       [ bp: Touchups. ]
      Signed-off-by: default avatarSteve Wahl <steve.wahl@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: dimitri.sivanich@hpe.com
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jordan Borgner <mail@jordan-borgner.de>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: mike.travis@hpe.com
      Cc: russ.anderson@hpe.com
      Cc: stable@vger.kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
      Link: https://lkml.kernel.org/r/9c011ee51b081534a7a15065b1681d200298b530.1569358539.git.steve.wahl@hpe.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17099172
    • Mikulas Patocka's avatar
      dm cache: fix bugs when a GFP_NOWAIT allocation fails · e49c84c5
      Mikulas Patocka authored
      commit 13bd677a upstream.
      
      GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being
      available and it fails if the mempool is exhausted and there is not enough
      memory.
      
      If we go down this path:
        map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT)
      we can see that map_bio() doesn't check the return value of mg_start(),
      and the bio is leaked.
      
      If we go down this path:
        map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell ->
        dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) ->
        mg_lock_writes -> mg_complete
      the bio is ended with an error - it is unacceptable because it could
      cause filesystem corruption if the machine ran out of memory
      temporarily.
      
      Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly
      wait until memory becomes available. mempool_alloc with GFP_NOIO can't
      fail, so remove the code paths that deal with allocation failure.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e49c84c5
    • Prateek Sood's avatar
      tracing: Fix race in perf_trace_buf initialization · 5ce7528c
      Prateek Sood authored
      commit 6b1340cc upstream.
      
      A race condition exists while initialiazing perf_trace_buf from
      perf_trace_init() and perf_kprobe_init().
      
            CPU0                                        CPU1
      perf_trace_init()
        mutex_lock(&event_mutex)
          perf_trace_event_init()
            perf_trace_event_reg()
              total_ref_count == 0
      	buf = alloc_percpu()
              perf_trace_buf[i] = buf
              tp_event->class->reg() //fails       perf_kprobe_init()
      	goto fail                              perf_trace_event_init()
                                                       perf_trace_event_reg()
              fail:
      	  total_ref_count == 0
      
                                                         total_ref_count == 0
                                                         buf = alloc_percpu()
                                                         perf_trace_buf[i] = buf
                                                         tp_event->class->reg()
                                                         total_ref_count++
      
                free_percpu(perf_trace_buf[i])
                perf_trace_buf[i] = NULL
      
      Any subsequent call to perf_trace_event_reg() will observe total_ref_count > 0,
      causing the perf_trace_buf to be always NULL. This can result in perf_trace_buf
      getting accessed from perf_trace_buf_alloc() without being initialized. Acquiring
      event_mutex in perf_kprobe_init() before calling perf_trace_event_init() should
      fix this race.
      
      The race caused the following bug:
      
       Unable to handle kernel paging request at virtual address 0000003106f2003c
       Mem abort info:
         ESR = 0x96000045
         Exception class = DABT (current EL), IL = 32 bits
         SET = 0, FnV = 0
         EA = 0, S1PTW = 0
       Data abort info:
         ISV = 0, ISS = 0x00000045
         CM = 0, WnR = 1
       user pgtable: 4k pages, 39-bit VAs, pgdp = ffffffc034b9b000
       [0000003106f2003c] pgd=0000000000000000, pud=0000000000000000
       Internal error: Oops: 96000045 [#1] PREEMPT SMP
       Process syz-executor (pid: 18393, stack limit = 0xffffffc093190000)
       pstate: 80400005 (Nzcv daif +PAN -UAO)
       pc : __memset+0x20/0x1ac
       lr : memset+0x3c/0x50
       sp : ffffffc09319fc50
      
        __memset+0x20/0x1ac
        perf_trace_buf_alloc+0x140/0x1a0
        perf_trace_sys_enter+0x158/0x310
        syscall_trace_enter+0x348/0x7c0
        el0_svc_common+0x11c/0x368
        el0_svc_handler+0x12c/0x198
        el0_svc+0x8/0xc
      
      Ramdumps showed the following:
        total_ref_count = 3
        perf_trace_buf = (
            0x0 -> NULL,
            0x0 -> NULL,
            0x0 -> NULL,
            0x0 -> NULL)
      
      Link: http://lkml.kernel.org/r/1571120245-4186-1-git-send-email-prsood@codeaurora.org
      
      Cc: stable@vger.kernel.org
      Fixes: e12f03d7 ("perf/core: Implement the 'perf_kprobe' PMU")
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarPrateek Sood <prsood@codeaurora.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ce7528c
    • Alexander Shishkin's avatar
      perf/aux: Fix AUX output stopping · 96202569
      Alexander Shishkin authored
      commit f3a519e4 upstream.
      
      Commit:
      
        8a58ddae ("perf/core: Fix exclusive events' grouping")
      
      allows CAP_EXCLUSIVE events to be grouped with other events. Since all
      of those also happen to be AUX events (which is not the case the other
      way around, because arch/s390), this changes the rules for stopping the
      output: the AUX event may not be on its PMU's context any more, if it's
      grouped with a HW event, in which case it will be on that HW event's
      context instead. If that's the case, munmap() of the AUX buffer can't
      find and stop the AUX event, potentially leaving the last reference with
      the atomic context, which will then end up freeing the AUX buffer. This
      will then trip warnings:
      
      Fix this by using the context's PMU context when looking for events
      to stop, instead of the event's PMU context.
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20191022073940.61814-1-alexander.shishkin@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96202569
    • Pavel Shilovsky's avatar
      CIFS: Fix use after free of file info structures · 01332b03
      Pavel Shilovsky authored
      commit 1a67c415 upstream.
      
      Currently the code assumes that if a file info entry belongs
      to lists of open file handles of an inode and a tcon then
      it has non-zero reference. The recent changes broke that
      assumption when putting the last reference of the file info.
      There may be a situation when a file is being deleted but
      nothing prevents another thread to reference it again
      and start using it. This happens because we do not hold
      the inode list lock while checking the number of references
      of the file info structure. Fix this by doing the proper
      locking when doing the check.
      
      Fixes: 487317c9 ("cifs: add spinlock for the openFileList to cifsInodeInfo")
      Fixes: cb248819 ("cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic")
      Cc: Stable <stable@vger.kernel.org>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01332b03
    • Roberto Bergantinos Corpas's avatar
      CIFS: avoid using MID 0xFFFF · 71cf8816
      Roberto Bergantinos Corpas authored
      commit 03d9a9fe upstream.
      
      According to MS-CIFS specification MID 0xFFFF should not be used by the
      CIFS client, but we actually do. Besides, this has proven to cause races
      leading to oops between SendReceive2/cifs_demultiplex_thread. On SMB1,
      MID is a 2 byte value easy to reach in CurrentMid which may conflict with
      an oplock break notification request coming from server
      Signed-off-by: default avatarRoberto Bergantinos Corpas <rbergant@redhat.com>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71cf8816
    • Marc Zyngier's avatar
      arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT · 42927455
      Marc Zyngier authored
      commit 93916beb upstream.
      
      It appears that the only case where we need to apply the TX2_219_TVM
      mitigation is when the core is in SMT mode. So let's condition the
      enabling on detecting a CPU whose MPIDR_EL1.Aff0 is non-zero.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42927455
    • James Morse's avatar
      EDAC/ghes: Fix Use after free in ghes_edac remove path · d97e4a6d
      James Morse authored
      commit 1e72e673 upstream.
      
      ghes_edac models a single logical memory controller, and uses a global
      ghes_init variable to ensure only the first ghes_edac_register() will
      do anything.
      
      ghes_edac is registered the first time a GHES entry in the HEST is
      probed. There may be multiple entries, so subsequent attempts to
      register ghes_edac are silently ignored as the work has already been
      done.
      
      When a GHES entry is unregistered, it calls ghes_edac_unregister(),
      which free()s the memory behind the global variables in ghes_edac.
      
      But there may be multiple GHES entries, the next call to
      ghes_edac_unregister() will dereference the free()d memory, and attempt
      to free it a second time.
      
      This may also be triggered on a platform with one GHES entry, if the
      driver is unbound/re-bound and unbound. The re-bind step will do
      nothing because of ghes_init, the second unbind will then do the same
      work as the first.
      
      Doing the unregister work on the first call is unsafe, as another
      CPU may be processing a notification in ghes_edac_report_mem_error(),
      using the memory we are about to free.
      
      ghes_init is already half of the reference counting. We only need
      to do the register work for the first call, and the unregister work
      for the last. Add the unregister check.
      
      This means we no longer free ghes_edac's memory while there are
      GHES entries that may receive a notification.
      
      This was detected by KASAN and DEBUG_TEST_DRIVER_REMOVE.
      
       [ bp: merge into a single patch. ]
      
      Fixes: 0fe5f281 ("EDAC, ghes: Model a single, logical memory controller")
      Reported-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Robert Richter <rrichter@marvell.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20191014171919.85044-2-james.morse@arm.com
      Link: https://lkml.kernel.org/r/304df85b-8b56-b77e-1a11-aa23769f2e7c@huawei.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d97e4a6d
    • Helge Deller's avatar
      parisc: Fix vmap memory leak in ioremap()/iounmap() · ca65fe21
      Helge Deller authored
      commit 513f7f74 upstream.
      
      Sven noticed that calling ioremap() and iounmap() multiple times leads
      to a vmap memory leak:
      	vmap allocation for size 4198400 failed:
      	use vmalloc=<size> to increase size
      
      It seems we missed calling vunmap() in iounmap().
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Noticed-by: default avatarSven Schnelle <svens@stackframe.org>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca65fe21
    • Max Filippov's avatar
      xtensa: drop EXPORT_SYMBOL for outs*/ins* · 19e2ed7b
      Max Filippov authored
      commit 8b39da98 upstream.
      
      Custom outs*/ins* implementations are long gone from the xtensa port,
      remove matching EXPORT_SYMBOLs.
      This fixes the following build warnings issued by modpost since commit
      15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions"):
      
        WARNING: "insb" [vmlinux] is a static EXPORT_SYMBOL
        WARNING: "insw" [vmlinux] is a static EXPORT_SYMBOL
        WARNING: "insl" [vmlinux] is a static EXPORT_SYMBOL
        WARNING: "outsb" [vmlinux] is a static EXPORT_SYMBOL
        WARNING: "outsw" [vmlinux] is a static EXPORT_SYMBOL
        WARNING: "outsl" [vmlinux] is a static EXPORT_SYMBOL
      
      Cc: stable@vger.kernel.org
      Fixes: d38efc1f ("xtensa: adopt generic io routines")
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19e2ed7b
    • Jane Chu's avatar
      mm/memory-failure: poison read receives SIGKILL instead of SIGBUS if mmaped more than once · 30cff8ab
      Jane Chu authored
      commit 3d7fed4a upstream.
      
      Mmap /dev/dax more than once, then read the poison location using
      address from one of the mappings.  The other mappings due to not having
      the page mapped in will cause SIGKILLs delivered to the process.
      SIGKILL succeeds over SIGBUS, so user process loses the opportunity to
      handle the UE.
      
      Although one may add MAP_POPULATE to mmap(2) to work around the issue,
      MAP_POPULATE makes mapping 128GB of pmem several magnitudes slower, so
      isn't always an option.
      
      Details -
      
        ndctl inject-error --block=10 --count=1 namespace6.0
      
        ./read_poison -x dax6.0 -o 5120 -m 2
        mmaped address 0x7f5bb6600000
        mmaped address 0x7f3cf3600000
        doing local read at address 0x7f3cf3601400
        Killed
      
      Console messages in instrumented kernel -
      
        mce: Uncorrected hardware memory error in user-access at edbe201400
        Memory failure: tk->addr = 7f5bb6601000
        Memory failure: address edbe201: call dev_pagemap_mapping_shift
        dev_pagemap_mapping_shift: page edbe201: no PUD
        Memory failure: tk->size_shift == 0
        Memory failure: Unable to find user space address edbe201 in read_poison
        Memory failure: tk->addr = 7f3cf3601000
        Memory failure: address edbe201: call dev_pagemap_mapping_shift
        Memory failure: tk->size_shift = 21
        Memory failure: 0xedbe201: forcibly killing read_poison:22434 because of failure to unmap corrupted page
          => to deliver SIGKILL
        Memory failure: 0xedbe201: Killing read_poison:22434 due to hardware memory corruption
          => to deliver SIGBUS
      
      Link: http://lkml.kernel.org/r/1565112345-28754-3-git-send-email-jane.chu@oracle.comSigned-off-by: default avatarJane Chu <jane.chu@oracle.com>
      Suggested-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      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>
      30cff8ab
    • David Hildenbrand's avatar
      hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic() · 91eec769
      David Hildenbrand authored
      commit f231fe42 upstream.
      
      Uninitialized memmaps contain garbage and in the worst case trigger
      kernel BUGs, especially with CONFIG_PAGE_POISONING.  They should not get
      touched.
      
      Let's make sure that we only consider online memory (managed by the
      buddy) that has initialized memmaps.  ZONE_DEVICE is not applicable.
      
      page_zone() will call page_to_nid(), which will trigger
      VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) with CONFIG_PAGE_POISONING
      and CONFIG_DEBUG_VM_PGFLAGS when called on uninitialized memmaps.  This
      can be the case when an offline memory block (e.g., never onlined) is
      spanned by a zone.
      
      Note: As explained by Michal in [1], alloc_contig_range() will verify
      the range.  So it boils down to the wrong access in this function.
      
      [1] http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz
      
      Link: http://lkml.kernel.org/r/20191015120717.4858-1-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reported-by: default avatarMichal Hocko <mhocko@kernel.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: <stable@vger.kernel.org>	[4.13+]
      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>
      91eec769
    • Qian Cai's avatar
      mm/page_owner: don't access uninitialized memmaps when reading /proc/pagetypeinfo · f712e306
      Qian Cai authored
      commit a26ee565 upstream.
      
      Uninitialized memmaps contain garbage and in the worst case trigger
      kernel BUGs, especially with CONFIG_PAGE_POISONING.  They should not get
      touched.
      
      For example, when not onlining a memory block that is spanned by a zone
      and reading /proc/pagetypeinfo with CONFIG_DEBUG_VM_PGFLAGS and
      CONFIG_PAGE_POISONING, we can trigger a kernel BUG:
      
        :/# echo 1 > /sys/devices/system/memory/memory40/online
        :/# echo 1 > /sys/devices/system/memory/memory42/online
        :/# cat /proc/pagetypeinfo > test.file
         page:fffff2c585200000 is uninitialized and poisoned
         raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
         raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
         page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
         There is not page extension available.
         ------------[ cut here ]------------
         kernel BUG at include/linux/mm.h:1107!
         invalid opcode: 0000 [#1] SMP NOPTI
      
      Please note that this change does not affect ZONE_DEVICE, because
      pagetypeinfo_showmixedcount_print() is called from
      mm/vmstat.c:pagetypeinfo_showmixedcount() only for populated zones, and
      ZONE_DEVICE is never populated (zone->present_pages always 0).
      
      [david@redhat.com: move check to outer loop, add comment, rephrase description]
      Link: http://lkml.kernel.org/r/20191011140638.8160-1-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online") # visible after d0dc12e8Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Miles Chen <miles.chen@mediatek.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Qian Cai <cai@lca.pw>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>	[4.13+]
      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>
      f712e306
    • Qian Cai's avatar
      mm/slub: fix a deadlock in show_slab_objects() · bb6932c5
      Qian Cai authored
      commit e4f8e513 upstream.
      
      A long time ago we fixed a similar deadlock in show_slab_objects() [1].
      However, it is apparently due to the commits like 01fb58bc ("slab:
      remove synchronous synchronize_sched() from memcg cache deactivation
      path") and 03afc0e2 ("slab: get_online_mems for
      kmem_cache_{create,destroy,shrink}"), this kind of deadlock is back by
      just reading files in /sys/kernel/slab which will generate a lockdep
      splat below.
      
      Since the "mem_hotplug_lock" here is only to obtain a stable online node
      mask while racing with NUMA node hotplug, in the worst case, the results
      may me miscalculated while doing NUMA node hotplug, but they shall be
      corrected by later reads of the same files.
      
        WARNING: possible circular locking dependency detected
        ------------------------------------------------------
        cat/5224 is trying to acquire lock:
        ffff900012ac3120 (mem_hotplug_lock.rw_sem){++++}, at:
        show_slab_objects+0x94/0x3a8
      
        but task is already holding lock:
        b8ff009693eee398 (kn->count#45){++++}, at: kernfs_seq_start+0x44/0xf0
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #2 (kn->count#45){++++}:
               lock_acquire+0x31c/0x360
               __kernfs_remove+0x290/0x490
               kernfs_remove+0x30/0x44
               sysfs_remove_dir+0x70/0x88
               kobject_del+0x50/0xb0
               sysfs_slab_unlink+0x2c/0x38
               shutdown_cache+0xa0/0xf0
               kmemcg_cache_shutdown_fn+0x1c/0x34
               kmemcg_workfn+0x44/0x64
               process_one_work+0x4f4/0x950
               worker_thread+0x390/0x4bc
               kthread+0x1cc/0x1e8
               ret_from_fork+0x10/0x18
      
        -> #1 (slab_mutex){+.+.}:
               lock_acquire+0x31c/0x360
               __mutex_lock_common+0x16c/0xf78
               mutex_lock_nested+0x40/0x50
               memcg_create_kmem_cache+0x38/0x16c
               memcg_kmem_cache_create_func+0x3c/0x70
               process_one_work+0x4f4/0x950
               worker_thread+0x390/0x4bc
               kthread+0x1cc/0x1e8
               ret_from_fork+0x10/0x18
      
        -> #0 (mem_hotplug_lock.rw_sem){++++}:
               validate_chain+0xd10/0x2bcc
               __lock_acquire+0x7f4/0xb8c
               lock_acquire+0x31c/0x360
               get_online_mems+0x54/0x150
               show_slab_objects+0x94/0x3a8
               total_objects_show+0x28/0x34
               slab_attr_show+0x38/0x54
               sysfs_kf_seq_show+0x198/0x2d4
               kernfs_seq_show+0xa4/0xcc
               seq_read+0x30c/0x8a8
               kernfs_fop_read+0xa8/0x314
               __vfs_read+0x88/0x20c
               vfs_read+0xd8/0x10c
               ksys_read+0xb0/0x120
               __arm64_sys_read+0x54/0x88
               el0_svc_handler+0x170/0x240
               el0_svc+0x8/0xc
      
        other info that might help us debug this:
      
        Chain exists of:
          mem_hotplug_lock.rw_sem --> slab_mutex --> kn->count#45
      
         Possible unsafe locking scenario:
      
               CPU0                    CPU1
               ----                    ----
          lock(kn->count#45);
                                       lock(slab_mutex);
                                       lock(kn->count#45);
          lock(mem_hotplug_lock.rw_sem);
      
         *** DEADLOCK ***
      
        3 locks held by cat/5224:
         #0: 9eff00095b14b2a0 (&p->lock){+.+.}, at: seq_read+0x4c/0x8a8
         #1: 0eff008997041480 (&of->mutex){+.+.}, at: kernfs_seq_start+0x34/0xf0
         #2: b8ff009693eee398 (kn->count#45){++++}, at:
        kernfs_seq_start+0x44/0xf0
      
        stack backtrace:
        Call trace:
         dump_backtrace+0x0/0x248
         show_stack+0x20/0x2c
         dump_stack+0xd0/0x140
         print_circular_bug+0x368/0x380
         check_noncircular+0x248/0x250
         validate_chain+0xd10/0x2bcc
         __lock_acquire+0x7f4/0xb8c
         lock_acquire+0x31c/0x360
         get_online_mems+0x54/0x150
         show_slab_objects+0x94/0x3a8
         total_objects_show+0x28/0x34
         slab_attr_show+0x38/0x54
         sysfs_kf_seq_show+0x198/0x2d4
         kernfs_seq_show+0xa4/0xcc
         seq_read+0x30c/0x8a8
         kernfs_fop_read+0xa8/0x314
         __vfs_read+0x88/0x20c
         vfs_read+0xd8/0x10c
         ksys_read+0xb0/0x120
         __arm64_sys_read+0x54/0x88
         el0_svc_handler+0x170/0x240
         el0_svc+0x8/0xc
      
      I think it is important to mention that this doesn't expose the
      show_slab_objects to use-after-free.  There is only a single path that
      might really race here and that is the slab hotplug notifier callback
      __kmem_cache_shrink (via slab_mem_going_offline_callback) but that path
      doesn't really destroy kmem_cache_node data structures.
      
      [1] http://lkml.iu.edu/hypermail/linux/kernel/1101.0/02850.html
      
      [akpm@linux-foundation.org: add comment explaining why we don't need mem_hotplug_lock]
      Link: http://lkml.kernel.org/r/1570192309-10132-1-git-send-email-cai@lca.pw
      Fixes: 01fb58bc ("slab: remove synchronous synchronize_sched() from memcg cache deactivation path")
      Fixes: 03afc0e2 ("slab: get_online_mems for kmem_cache_{create,destroy,shrink}")
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Roman Gushchin <guro@fb.com>
      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>
      bb6932c5
    • David Hildenbrand's avatar
      mm/memory-failure.c: don't access uninitialized memmaps in memory_failure() · 9792afbd
      David Hildenbrand authored
      commit 96c804a6 upstream.
      
      We should check for pfn_to_online_page() to not access uninitialized
      memmaps.  Reshuffle the code so we don't have to duplicate the error
      message.
      
      Link: http://lkml.kernel.org/r/20191009142435.3975-3-david@redhat.comSigned-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: <stable@vger.kernel.org>	[4.13+]
      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>
      9792afbd
    • Faiz Abbas's avatar
      mmc: cqhci: Commit descriptors before setting the doorbell · 01a44055
      Faiz Abbas authored
      commit c07d0073 upstream.
      
      Add a write memory barrier to make sure that descriptors are actually
      written to memory, before ringing the doorbell.
      Signed-off-by: default avatarFaiz Abbas <faiz_abbas@ti.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01a44055
    • David Hildenbrand's avatar
      fs/proc/page.c: don't access uninitialized memmaps in fs/proc/page.c · 6ea856ef
      David Hildenbrand authored
      commit aad5f69b upstream.
      
      There are three places where we access uninitialized memmaps, namely:
      - /proc/kpagecount
      - /proc/kpageflags
      - /proc/kpagecgroup
      
      We have initialized memmaps either when the section is online or when the
      page was initialized to the ZONE_DEVICE.  Uninitialized memmaps contain
      garbage and in the worst case trigger kernel BUGs, especially with
      CONFIG_PAGE_POISONING.
      
      For example, not onlining a DIMM during boot and calling /proc/kpagecount
      with CONFIG_PAGE_POISONING:
      
        :/# cat /proc/kpagecount > tmp.test
        BUG: unable to handle page fault for address: fffffffffffffffe
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 114616067 P4D 114616067 PUD 114618067 PMD 0
        Oops: 0000 [#1] SMP NOPTI
        CPU: 0 PID: 469 Comm: cat Not tainted 5.4.0-rc1-next-20191004+ #11
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.4
        RIP: 0010:kpagecount_read+0xce/0x1e0
        Code: e8 09 83 e0 3f 48 0f a3 02 73 2d 4c 89 e7 48 c1 e7 06 48 03 3d ab 51 01 01 74 1d 48 8b 57 08 480
        RSP: 0018:ffffa14e409b7e78 EFLAGS: 00010202
        RAX: fffffffffffffffe RBX: 0000000000020000 RCX: 0000000000000000
        RDX: 0000000000000001 RSI: 00007f76b5595000 RDI: fffff35645000000
        RBP: 00007f76b5595000 R08: 0000000000000001 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000140000
        R13: 0000000000020000 R14: 00007f76b5595000 R15: ffffa14e409b7f08
        FS:  00007f76b577d580(0000) GS:ffff8f41bd400000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: fffffffffffffffe CR3: 0000000078960000 CR4: 00000000000006f0
        Call Trace:
         proc_reg_read+0x3c/0x60
         vfs_read+0xc5/0x180
         ksys_read+0x68/0xe0
         do_syscall_64+0x5c/0xa0
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      For now, let's drop support for ZONE_DEVICE from the three pseudo files
      in order to fix this.  To distinguish offline memory (with garbage
      memmap) from ZONE_DEVICE memory with properly initialized memmaps, we
      would have to check get_dev_pagemap() and pfn_zone_device_reserved()
      right now.  The usage of both (especially, special casing devmem) is
      frowned upon and needs to be reworked.
      
      The fundamental issue we have is:
      
      	if (pfn_to_online_page(pfn)) {
      		/* memmap initialized */
      	} else if (pfn_valid(pfn)) {
      		/*
      		 * ???
      		 * a) offline memory. memmap garbage.
      		 * b) devmem: memmap initialized to ZONE_DEVICE.
      		 * c) devmem: reserved for driver. memmap garbage.
      		 * (d) devmem: memmap currently initializing - garbage)
      		 */
      	}
      
      We'll leave the pfn_zone_device_reserved() check in stable_page_flags()
      in place as that function is also used from memory failure.  We now no
      longer dump information about pages that are not in use anymore -
      offline.
      
      Link: http://lkml.kernel.org/r/20191009142435.3975-2-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reported-by: default avatarQian Cai <cai@lca.pw>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Toshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
      Cc: Pankaj gupta <pagupta@redhat.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Anthony Yznaga <anthony.yznaga@oracle.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
      Cc: <stable@vger.kernel.org>	[4.13+]
      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>
      6ea856ef
    • David Hildenbrand's avatar
      drivers/base/memory.c: don't access uninitialized memmaps in soft_offline_page_store() · 43a2a6c2
      David Hildenbrand authored
      commit 641fe2e9 upstream.
      
      Uninitialized memmaps contain garbage and in the worst case trigger kernel
      BUGs, especially with CONFIG_PAGE_POISONING.  They should not get touched.
      
      Right now, when trying to soft-offline a PFN that resides on a memory
      block that was never onlined, one gets a misleading error with
      CONFIG_PAGE_POISONING:
      
        :/# echo 5637144576 > /sys/devices/system/memory/soft_offline_page
        [   23.097167] soft offline: 0x150000 page already poisoned
      
      But the actual result depends on the garbage in the memmap.
      
      soft_offline_page() can only work with online pages, it returns -EIO in
      case of ZONE_DEVICE.  Make sure to only forward pages that are online
      (iow, managed by the buddy) and, therefore, have an initialized memmap.
      
      Add a check against pfn_to_online_page() and similarly return -EIO.
      
      Link: http://lkml.kernel.org/r/20191010141200.8985-1-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: <stable@vger.kernel.org>	[4.13+]
      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>
      43a2a6c2
    • Hans de Goede's avatar
      drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1 · 4d5307c0
      Hans de Goede authored
      commit 984d7a92 upstream.
      
      Bail from the pci_driver probe function instead of from the drm_driver
      load function.
      
      This avoid /dev/dri/card0 temporarily getting registered and then
      unregistered again, sending unwanted add / remove udev events to
      userspace.
      
      Specifically this avoids triggering the (userspace) bug fixed by this
      plymouth merge-request:
      https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
      
      Note that despite that being a userspace bug, not sending unnecessary
      udev events is a good idea in general.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d5307c0
    • Thomas Hellstrom's avatar
      drm/ttm: Restore ttm prefaulting · 11377c3e
      Thomas Hellstrom authored
      commit 941f2f72 upstream.
      
      Commit 4daa4fba ("gpu: drm: ttm: Adding new return type vm_fault_t")
      broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
      VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
      
      Restore (almost) the original behaviour. Unfortunately we can no longer
      with the new vm_fault_t return type determine whether a prefaulting
      PTE insertion hit an already populated PTE, and terminate the insertion
      loop. Instead we continue with the pre-determined number of prefaults.
      
      Fixes: 4daa4fba ("gpu: drm: ttm: Adding new return type vm_fault_t")
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Cc: Christian König <christian.koenig@amd.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/330387/Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11377c3e
    • Kai-Heng Feng's avatar
    • Will Deacon's avatar
      mac80211: Reject malformed SSID elements · 24ca6289
      Will Deacon authored
      commit 4152561f upstream.
      
      Although this shouldn't occur in practice, it's a good idea to bounds
      check the length field of the SSID element prior to using it for things
      like allocations or memcpy operations.
      
      Cc: <stable@vger.kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Reported-by: default avatarNicolas Waisman <nico@semmle.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20191004095132.15777-1-will@kernel.orgSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24ca6289
    • Will Deacon's avatar
      cfg80211: wext: avoid copying malformed SSIDs · 73c066a9
      Will Deacon authored
      commit 4ac2813c upstream.
      
      Ensure the SSID element is bounds-checked prior to invoking memcpy()
      with its length field, when copying to userspace.
      
      Cc: <stable@vger.kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Reported-by: default avatarNicolas Waisman <nico@semmle.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20191004095132.15777-2-will@kernel.org
      [adjust commit log a bit]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73c066a9
    • John Garry's avatar
      ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit() · 83dc1670
      John Garry authored
      commit 56a0b978 upstream.
      
      When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN
      warning:
      
      [   20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8
      [   20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1
      [   20.884826]
      [   20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289
      [   20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
      [   20.903505] Call trace:
      [   20.905942]  dump_backtrace+0x0/0x200
      [   20.909593]  show_stack+0x14/0x20
      [   20.912899]  dump_stack+0xd4/0x130
      [   20.916291]  print_address_description.isra.9+0x6c/0x3b8
      [   20.921592]  __kasan_report+0x12c/0x23c
      [   20.925417]  kasan_report+0xc/0x18
      [   20.928808]  __asan_load4+0x94/0xb8
      [   20.932286]  pcc_data_alloc+0x40/0xb8
      [   20.935938]  acpi_cppc_processor_probe+0x4e8/0xb08
      [   20.940717]  __acpi_processor_start+0x48/0xb0
      [   20.945062]  acpi_processor_start+0x40/0x60
      [   20.949235]  really_probe+0x118/0x548
      [   20.952887]  driver_probe_device+0x7c/0x148
      [   20.957059]  device_driver_attach+0x94/0xa0
      [   20.961231]  __driver_attach+0xa4/0x110
      [   20.965055]  bus_for_each_dev+0xe8/0x158
      [   20.968966]  driver_attach+0x30/0x40
      [   20.972531]  bus_add_driver+0x234/0x2f0
      [   20.976356]  driver_register+0xbc/0x1d0
      [   20.980182]  acpi_processor_driver_init+0x40/0xe4
      [   20.984875]  do_one_initcall+0xb4/0x254
      [   20.988700]  kernel_init_freeable+0x24c/0x2f8
      [   20.993047]  kernel_init+0x10/0x118
      [   20.996524]  ret_from_fork+0x10/0x18
      [   21.000087]
      [   21.001567] Allocated by task 1:
      [   21.004785]  save_stack+0x28/0xc8
      [   21.008089]  __kasan_kmalloc.isra.9+0xbc/0xd8
      [   21.012435]  kasan_kmalloc+0xc/0x18
      [   21.015913]  pcc_data_alloc+0x94/0xb8
      [   21.019564]  acpi_cppc_processor_probe+0x4e8/0xb08
      [   21.024343]  __acpi_processor_start+0x48/0xb0
      [   21.028689]  acpi_processor_start+0x40/0x60
      [   21.032860]  really_probe+0x118/0x548
      [   21.036512]  driver_probe_device+0x7c/0x148
      [   21.040684]  device_driver_attach+0x94/0xa0
      [   21.044855]  __driver_attach+0xa4/0x110
      [   21.048680]  bus_for_each_dev+0xe8/0x158
      [   21.052591]  driver_attach+0x30/0x40
      [   21.056155]  bus_add_driver+0x234/0x2f0
      [   21.059980]  driver_register+0xbc/0x1d0
      [   21.063805]  acpi_processor_driver_init+0x40/0xe4
      [   21.068497]  do_one_initcall+0xb4/0x254
      [   21.072322]  kernel_init_freeable+0x24c/0x2f8
      [   21.076667]  kernel_init+0x10/0x118
      [   21.080144]  ret_from_fork+0x10/0x18
      [   21.083707]
      [   21.085186] Freed by task 1:
      [   21.088056]  save_stack+0x28/0xc8
      [   21.091360]  __kasan_slab_free+0x118/0x180
      [   21.095445]  kasan_slab_free+0x10/0x18
      [   21.099183]  kfree+0x80/0x268
      [   21.102139]  acpi_cppc_processor_exit+0x1a8/0x1b8
      [   21.106832]  acpi_processor_stop+0x70/0x80
      [   21.110917]  really_probe+0x174/0x548
      [   21.114568]  driver_probe_device+0x7c/0x148
      [   21.118740]  device_driver_attach+0x94/0xa0
      [   21.122912]  __driver_attach+0xa4/0x110
      [   21.126736]  bus_for_each_dev+0xe8/0x158
      [   21.130648]  driver_attach+0x30/0x40
      [   21.134212]  bus_add_driver+0x234/0x2f0
      [   21.0x10/0x18
      [   21.161764]
      [   21.163244] The buggy address belongs to the object at ffff00236cdeb600
      [   21.163244]  which belongs to the cache kmalloc-256 of size 256
      [   21.175750] The buggy address is located 132 bytes inside of
      [   21.175750]  256-byte region [ffff00236cdeb600, ffff00236cdeb700)
      [   21.187473] The buggy address belongs to the page:
      [   21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0
      [   21.202331] flags: 0x1ffff00000010200(slab|head)
      [   21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00
      [   21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
      [   21.222400] page dumped because: kasan: bad access detected
      [   21.227959]
      [   21.229438] Memory state around the buggy address:
      [   21.234218]  ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   21.241427]  ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.255845]                    ^
      [   21.259062]  ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   21.266272]  ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.273480] ==================================================================
      
      It seems that global pcc_data[pcc_ss_id] can be freed in
      acpi_cppc_processor_exit(), but we may later reference this value, so
      NULLify it when freed.
      
      Also remove the useless setting of data "pcc_channel_acquired", which
      we're about to free.
      
      Fixes: 85b1407b ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs")
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83dc1670
    • Junya Monden's avatar
      ASoC: rsnd: Reinitialize bit clock inversion flag for every format setting · 8e367b02
      Junya Monden authored
      commit 22e58665 upstream.
      
      Unlike other format-related DAI parameters, rdai->bit_clk_inv flag
      is not properly re-initialized when setting format for new stream
      processing. The inversion, if requested, is then applied not to default,
      but to a previous value, which leads to SCKP bit in SSICR register being
      set incorrectly.
      Fix this by re-setting the flag to its initial value, determined by format.
      
      Fixes: 1a7889ca ("ASoC: rsnd: fixup SND_SOC_DAIFMT_xB_xF behavior")
      Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com>
      Cc: Jiada Wang <jiada_wang@mentor.com>
      Cc: Timo Wischer <twischer@de.adit-jv.com>
      Cc: stable@vger.kernel.org # v3.17+
      Signed-off-by: default avatarJunya Monden <jmonden@jp.adit-jv.com>
      Signed-off-by: default avatarEugeniu Rosca <erosca@de.adit-jv.com>
      Acked-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/20191016124255.7442-1-erosca@de.adit-jv.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e367b02
    • Evan Green's avatar
      Input: synaptics-rmi4 - avoid processing unknown IRQs · b0dd6a24
      Evan Green authored
      commit 363c5387 upstream.
      
      rmi_process_interrupt_requests() calls handle_nested_irq() for
      each interrupt status bit it finds. If the irq domain mapping for
      this bit had not yet been set up, then it ends up calling
      handle_nested_irq(0), which causes a NULL pointer dereference.
      
      There's already code that masks the irq_status bits coming out of the
      hardware with current_irq_mask, presumably to avoid this situation.
      However current_irq_mask seems to more reflect the actual mask set
      in the hardware rather than the IRQs software has set up and registered
      for. For example, in rmi_driver_reset_handler(), the current_irq_mask
      is initialized based on what is read from the hardware. If the reset
      value of this mask enables IRQs that Linux has not set up yet, then
      we end up in this situation.
      
      There appears to be a third unused bitmask that used to serve this
      purpose, fn_irq_bits. Use that bitmask instead of current_irq_mask
      to avoid calling handle_nested_irq() on IRQs that have not yet been
      set up.
      Signed-off-by: default avatarEvan Green <evgreen@chromium.org>
      Reviewed-by: default avatarAndrew Duggan <aduggan@synaptics.com>
      Link: https://lore.kernel.org/r/20191008223657.163366-1-evgreen@chromium.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0dd6a24
    • Marco Felsch's avatar
      Input: da9063 - fix capability and drop KEY_SLEEP · aa9402c1
      Marco Felsch authored
      commit afce285b upstream.
      
      Since commit f889beaa ("Input: da9063 - report KEY_POWER instead of
      KEY_SLEEP during power key-press") KEY_SLEEP isn't supported anymore. This
      caused input device to not generate any events if "dlg,disable-key-power"
      is set.
      
      Fix this by unconditionally setting KEY_POWER capability, and not
      declaring KEY_SLEEP.
      
      Fixes: f889beaa ("Input: da9063 - report KEY_POWER instead of KEY_SLEEP during power key-press")
      Signed-off-by: default avatarMarco Felsch <m.felsch@pengutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa9402c1
    • Bart Van Assche's avatar
      scsi: ch: Make it possible to open a ch device multiple times again · e254d435
      Bart Van Assche authored
      commit 6a0990ea upstream.
      
      Clearing ch->device in ch_release() is wrong because that pointer must
      remain valid until ch_remove() is called. This patch fixes the following
      crash the second time a ch device is opened:
      
      BUG: kernel NULL pointer dereference, address: 0000000000000790
      RIP: 0010:scsi_device_get+0x5/0x60
      Call Trace:
       ch_open+0x4c/0xa0 [ch]
       chrdev_open+0xa2/0x1c0
       do_dentry_open+0x13a/0x380
       path_openat+0x591/0x1470
       do_filp_open+0x91/0x100
       do_sys_open+0x184/0x220
       do_syscall_64+0x5f/0x1a0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 085e5676 ("scsi: ch: add refcounting")
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191009173536.247889-1-bvanassche@acm.orgReported-by: default avatarRob Turk <robtu@rtist.nl>
      Suggested-by: default avatarRob Turk <robtu@rtist.nl>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e254d435
    • Yufen Yu's avatar
      scsi: core: try to get module before removing device · 0c690519
      Yufen Yu authored
      commit 77c30128 upstream.
      
      We have a test case like block/001 in blktests, which will create a scsi
      device by loading scsi_debug module and then try to delete the device by
      sysfs interface. At the same time, it may remove the scsi_debug module.
      
      And getting a invalid paging request BUG_ON as following:
      
      [   34.625854] BUG: unable to handle page fault for address: ffffffffa0016bb8
      [   34.629189] Oops: 0000 [#1] SMP PTI
      [   34.629618] CPU: 1 PID: 450 Comm: bash Tainted: G        W         5.4.0-rc3+ #473
      [   34.632524] RIP: 0010:scsi_proc_hostdir_rm+0x5/0xa0
      [   34.643555] CR2: ffffffffa0016bb8 CR3: 000000012cd88000 CR4: 00000000000006e0
      [   34.644545] Call Trace:
      [   34.644907]  scsi_host_dev_release+0x6b/0x1f0
      [   34.645511]  device_release+0x74/0x110
      [   34.646046]  kobject_put+0x116/0x390
      [   34.646559]  put_device+0x17/0x30
      [   34.647041]  scsi_target_dev_release+0x2b/0x40
      [   34.647652]  device_release+0x74/0x110
      [   34.648186]  kobject_put+0x116/0x390
      [   34.648691]  put_device+0x17/0x30
      [   34.649157]  scsi_device_dev_release_usercontext+0x2e8/0x360
      [   34.649953]  execute_in_process_context+0x29/0x80
      [   34.650603]  scsi_device_dev_release+0x20/0x30
      [   34.651221]  device_release+0x74/0x110
      [   34.651732]  kobject_put+0x116/0x390
      [   34.652230]  sysfs_unbreak_active_protection+0x3f/0x50
      [   34.652935]  sdev_store_delete.cold.4+0x71/0x8f
      [   34.653579]  dev_attr_store+0x1b/0x40
      [   34.654103]  sysfs_kf_write+0x3d/0x60
      [   34.654603]  kernfs_fop_write+0x174/0x250
      [   34.655165]  __vfs_write+0x1f/0x60
      [   34.655639]  vfs_write+0xc7/0x280
      [   34.656117]  ksys_write+0x6d/0x140
      [   34.656591]  __x64_sys_write+0x1e/0x30
      [   34.657114]  do_syscall_64+0xb1/0x400
      [   34.657627]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   34.658335] RIP: 0033:0x7f156f337130
      
      During deleting scsi target, the scsi_debug module have been removed. Then,
      sdebug_driver_template belonged to the module cannot be accessd, resulting
      in scsi_proc_hostdir_rm() BUG_ON.
      
      To fix the bug, we add scsi_device_get() in sdev_store_delete() to try to
      increase refcount of module, avoiding the module been removed.
      
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191015130556.18061-1-yuyufen@huawei.comSigned-off-by: default avatarYufen Yu <yuyufen@huawei.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c690519
    • Damien Le Moal's avatar
      scsi: core: save/restore command resid for error handling · 2a675e73
      Damien Le Moal authored
      commit 8f8fed0c upstream.
      
      When a non-passthrough command is terminated with CHECK CONDITION, request
      sense is executed by hijacking the command descriptor. Since
      scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() do not save/restore the
      original command resid, the value returned on failure of the original
      command is lost and replaced with the value set by the execution of the
      request sense command. This value may in many instances be unaligned to the
      device sector size, causing sd_done() to print a warning message about the
      incorrect unaligned resid before the command is retried.
      
      Fix this problem by saving the original command residual in struct
      scsi_eh_save using scsi_eh_prep_cmnd() and restoring it in
      scsi_eh_restore_cmnd(). In addition, to make sure that the request sense
      command is executed with a correctly initialized command structure, also
      reset the residual to 0 in scsi_eh_prep_cmnd() after saving the original
      command value in struct scsi_eh_save.
      
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191001074839.1994-1-damien.lemoal@wdc.comSigned-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a675e73
    • Oliver Neukum's avatar
      scsi: sd: Ignore a failure to sync cache due to lack of authorization · 0cea86f2
      Oliver Neukum authored
      commit 21e3d6c8 upstream.
      
      I've got a report about a UAS drive enclosure reporting back Sense: Logical
      unit access not authorized if the drive it holds is password protected.
      While the drive is obviously unusable in that state as a mass storage
      device, it still exists as a sd device and when the system is asked to
      perform a suspend of the drive, it will be sent a SYNCHRONIZE CACHE. If
      that fails due to password protection, the error must be ignored.
      
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20190903101840.16483-1-oneukum@suse.comSigned-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0cea86f2
    • Steffen Maier's avatar
      scsi: zfcp: fix reaction on bit error threshold notification · 3638ccda
      Steffen Maier authored
      commit 2190168a upstream.
      
      On excessive bit errors for the FCP channel ingress fibre path, the channel
      notifies us.  Previously, we only emitted a kernel message and a trace
      record.  Since performance can become suboptimal with I/O timeouts due to
      bit errors, we now stop using an FCP device by default on channel
      notification so multipath on top can timely failover to other paths.  A new
      module parameter zfcp.ber_stop can be used to get zfcp old behavior.
      
      User explanation of new kernel message:
      
       * Description:
       * The FCP channel reported that its bit error threshold has been exceeded.
       * These errors might result from a problem with the physical components
       * of the local fibre link into the FCP channel.
       * The problem might be damage or malfunction of the cable or
       * cable connection between the FCP channel and
       * the adjacent fabric switch port or the point-to-point peer.
       * Find details about the errors in the HBA trace for the FCP device.
       * The zfcp device driver closed down the FCP device
       * to limit the performance impact from possible I/O command timeouts.
       * User action:
       * Check for problems on the local fibre link, ensure that fibre optics are
       * clean and functional, and all cables are properly plugged.
       * After the repair action, you can manually recover the FCP device by
       * writing "0" into its "failed" sysfs attribute.
       * If recovery through sysfs is not possible, set the CHPID of the device
       * offline and back online on the service element.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: <stable@vger.kernel.org> #2.6.30+
      Link: https://lore.kernel.org/r/20191001104949.42810-1-maier@linux.ibm.comReviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3638ccda
    • Colin Ian King's avatar
      staging: wlan-ng: fix exit return when sme->key_idx >= NUM_WEPKEYS · d07c028d
      Colin Ian King authored
      commit 153c5d81 upstream.
      
      Currently the exit return path when sme->key_idx >= NUM_WEPKEYS is via
      label 'exit' and this checks if result is non-zero, however result has
      not been initialized and contains garbage.  Fix this by replacing the
      goto with a return with the error code.
      
      Addresses-Coverity: ("Uninitialized scalar variable")
      Fixes: 0ca6d8e7 ("Staging: wlan-ng: replace switch-case statements with macro")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191014110201.9874-1-colin.king@canonical.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d07c028d
    • Paul Burton's avatar
      MIPS: tlbex: Fix build_restore_pagemask KScratch restore · 4034a503
      Paul Burton authored
      commit b42aa3fd upstream.
      
      build_restore_pagemask() will restore the value of register $1/$at when
      its restore_scratch argument is non-zero, and aims to do so by filling a
      branch delay slot. Commit 0b24cae4 ("MIPS: Add missing EHB in mtc0
      -> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier)
      prior to restoring $1 from a KScratch register, in order to resolve a
      hazard that can result in stale values of the KScratch register being
      observed. In particular, P-class CPUs from MIPS with out of order
      execution pipelines such as the P5600 & P6600 are affected.
      
      Unfortunately this EHB instruction was inserted in the branch delay slot
      causing the MFC0 instruction which performs the restoration to no longer
      execute along with the branch. The result is that the $1 register isn't
      actually restored, ie. the TLB refill exception handler clobbers it -
      which is exactly the problem the EHB is meant to avoid for the P-class
      CPUs.
      
      Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when
      its mode argument equals refill_scratch, and suffers from the same
      problem.
      
      Fix this by in both cases moving the EHB earlier in the emitted code.
      There's no reason it needs to immediately precede the MFC0 - it simply
      needs to be between the MTC0 & MFC0.
      
      This bug only affects Cavium Octeon systems which use
      build_fast_tlb_refill_handler().
      Signed-off-by: default avatarPaul Burton <paulburton@kernel.org>
      Fixes: 0b24cae4 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
      Cc: Dmitry Korotin <dkorotin@wavecomp.com>
      Cc: stable@vger.kernel.org # v3.15+
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4034a503
    • Johan Hovold's avatar
      USB: ldusb: fix read info leaks · 9f7e1574
      Johan Hovold authored
      commit 7a6f22d7 upstream.
      
      Fix broken read implementation, which could be used to trigger slab info
      leaks.
      
      The driver failed to check if the custom ring buffer was still empty
      when waking up after having waited for more data. This would happen on
      every interrupt-in completion, even if no data had been added to the
      ring buffer (e.g. on disconnect events).
      
      Due to missing sanity checks and uninitialised (kmalloced) ring-buffer
      entries, this meant that huge slab info leaks could easily be triggered.
      
      Note that the empty-buffer check after wakeup is enough to fix the info
      leak on disconnect, but let's clear the buffer on allocation and add a
      sanity check to read() to prevent further leaks.
      
      Fixes: 2824bd25 ("[PATCH] USB: add ldusb driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.13
      Reported-by: syzbot+6fe95b826644f7f12b0b@syzkaller.appspotmail.com
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191018151955.25135-2-johan@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f7e1574
    • Johan Hovold's avatar
      USB: usblp: fix use-after-free on disconnect · 3b73a0e4
      Johan Hovold authored
      commit 7a759197 upstream.
      
      A recent commit addressing a runtime PM use-count regression, introduced
      a use-after-free by not making sure we held a reference to the struct
      usb_interface for the lifetime of the driver data.
      
      Fixes: 9a315358 ("USB: usblp: fix runtime PM after driver unbind")
      Cc: stable <stable@vger.kernel.org>
      Reported-by: syzbot+cd24df4d075c319ebfc5@syzkaller.appspotmail.com
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191015175522.18490-1-johan@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b73a0e4
    • Johan Hovold's avatar
      USB: ldusb: fix memleak on disconnect · 28ab2c5f
      Johan Hovold authored
      commit b14a3904 upstream.
      
      If disconnect() races with release() after a process has been
      interrupted, release() could end up returning early and the driver would
      fail to free its driver data.
      
      Fixes: 2824bd25 ("[PATCH] USB: add ldusb driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.13
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191010125835.27031-2-johan@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28ab2c5f