commit b3060a1a313ff7a545d658378f62fe9c250acdee
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 4 09:30:58 2019 +0200

    Linux 4.19.64

commit 4736bb27774449cf759ee81663b4126a297ba9d4
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Jun 17 21:34:13 2019 +0800

    ip_tunnel: allow not to count pkts on tstats by setting skb's dev to NULL
    
    commit 5684abf7020dfc5f0b6ba1d68eda3663871fce52 upstream.
    
    iptunnel_xmit() works as a common function, also used by a udp tunnel
    which doesn't have to have a tunnel device, like how TIPC works with
    udp media.
    
    In these cases, we should allow not to count pkts on dev's tstats, so
    that udp tunnel can work with no tunnel device safely.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 475f7781a8047d5fc5a16b1f6148cd0bc62d8a69
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Fri Mar 15 16:27:58 2019 -0700

    scsi: core: Avoid that a kernel warning appears during system resume
    
    commit 17605afaae825b0291f80c62a7f6565879edaa8a upstream.
    
    Since scsi_device_quiesce() skips SCSI devices that have another state than
    RUNNING, OFFLINE or TRANSPORT_OFFLINE, scsi_device_resume() should not
    complain about SCSI devices that have been skipped. Hence this patch.  This
    patch avoids that the following warning appears during resume:
    
    WARNING: CPU: 3 PID: 1039 at blk_clear_pm_only+0x2a/0x30
    CPU: 3 PID: 1039 Comm: kworker/u8:49 Not tainted 5.0.0+ #1
    Hardware name: LENOVO 4180F42/4180F42, BIOS 83ET75WW (1.45 ) 05/10/2013
    Workqueue: events_unbound async_run_entry_fn
    RIP: 0010:blk_clear_pm_only+0x2a/0x30
    Call Trace:
     ? scsi_device_resume+0x28/0x50
     ? scsi_dev_type_resume+0x2b/0x80
     ? async_run_entry_fn+0x2c/0xd0
     ? process_one_work+0x1f0/0x3f0
     ? worker_thread+0x28/0x3c0
     ? process_one_work+0x3f0/0x3f0
     ? kthread+0x10c/0x130
     ? __kthread_create_on_node+0x150/0x150
     ? ret_from_fork+0x1f/0x30
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
    Cc: Martin Steigerwald <martin@lichtvoll.de>
    Cc: <stable@vger.kernel.org>
    Reported-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Tested-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c58a6507363b7d9b5ac3aefeb4b54172eafa3bc6
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Sep 26 14:01:04 2018 -0700

    block, scsi: Change the preempt-only flag into a counter
    
    commit cd84a62e0078dce09f4ed349bec84f86c9d54b30 upstream.
    
    The RQF_PREEMPT flag is used for three purposes:
    - In the SCSI core, for making sure that power management requests
      are executed even if a device is in the "quiesced" state.
    - For domain validation by SCSI drivers that use the parallel port.
    - In the IDE driver, for IDE preempt requests.
    Rename "preempt-only" into "pm-only" because the primary purpose of
    this mode is power management. Since the power management core may
    but does not have to resume a runtime suspended device before
    performing system-wide suspend and since a later patch will set
    "pm-only" mode as long as a block device is runtime suspended, make
    it possible to set "pm-only" mode from more than one context. Since
    with this change scsi_device_quiesce() is no longer idempotent, make
    that function return early if it is called for a quiesced queue.
    
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Cc: Jianchao Wang <jianchao.w.wang@oracle.com>
    Cc: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b17512d9165668eb71c3d51e36ef8ab4c5f2edc
Author: Yan, Zheng <zyan@redhat.com>
Date:   Thu May 23 11:01:37 2019 +0800

    ceph: hold i_ceph_lock when removing caps for freeing inode
    
    commit d6e47819721ae2d9d090058ad5570a66f3c42e39 upstream.
    
    ceph_d_revalidate(, LOOKUP_RCU) may call __ceph_caps_issued_mask()
    on a freeing inode.
    
    Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6c3b6a2c66280a5a7c272adce5f30733de6bfc1
Author: Yoshinori Sato <ysato@users.sourceforge.jp>
Date:   Sun Apr 21 22:53:58 2019 +0900

    Fix allyesconfig output.
    
    commit 1b496469d0c020e09124e03e66a81421c21272a7 upstream.
    
    Conflict JCore-SoC and SolutionEngine 7619.
    
    Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 135e7737e21f9fa23917be0dc5a594b50340590f
Author: Miroslav Lichvar <mlichvar@redhat.com>
Date:   Tue Jul 16 16:30:09 2019 -0700

    drivers/pps/pps.c: clear offset flags in PPS_SETPARAMS ioctl
    
    commit 5515e9a6273b8c02034466bcbd717ac9f53dab99 upstream.
    
    The PPS assert/clear offset corrections are set by the PPS_SETPARAMS
    ioctl in the pps_ktime structs, which also contain flags.  The flags are
    not initialized by applications (using the timepps.h header) and they
    are not used by the kernel for anything except returning them back in
    the PPS_GETPARAMS ioctl.
    
    Set the flags to zero to make it clear they are unused and avoid leaking
    uninitialized data of the PPS_SETPARAMS caller to other applications
    that have a read access to the PPS device.
    
    Link: http://lkml.kernel.org/r/20190702092251.24303-1-mlichvar@redhat.com
    Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Rodolfo Giometti <giometti@enneenne.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54695343b4910a3a6e09513a3231336ede39484a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jul 13 14:27:14 2019 -0700

    /proc/<pid>/cmdline: add back the setproctitle() special case
    
    commit d26d0cd97c88eb1a5704b42e41ab443406807810 upstream.
    
    This makes the setproctitle() special case very explicit indeed, and
    handles it with a separate helper function entirely.  In the process, it
    re-instates the original semantics of simply stopping at the first NUL
    character when the original last NUL character is no longer there.
    
    [ The original semantics can still be seen in mm/util.c: get_cmdline()
      that is limited to a fixed-size buffer ]
    
    This makes the logic about when we use the string lengths etc much more
    obvious, and makes it easier to see what we do and what the two very
    different cases are.
    
    Note that even when we allow walking past the end of the argument array
    (because the setproctitle() might have overwritten and overflowed the
    original argv[] strings), we only allow it when it overflows into the
    environment region if it is immediately adjacent.
    
    [ Fixed for missing 'count' checks noted by Alexey Izbyshev ]
    
    Link: https://lore.kernel.org/lkml/alpine.LNX.2.21.1904052326230.3249@kich.toxcorp.com/
    Fixes: 5ab827189965 ("fs/proc: simplify and clarify get_mm_cmdline() function")
    Cc: Jakub Jankowski <shasta@toxcorp.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Alexey Izbyshev <izbyshev@ispras.ru>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54ffaa53e785ad72df597bf0544b65f0dfd19cdc
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jul 13 13:40:13 2019 -0700

    /proc/<pid>/cmdline: remove all the special cases
    
    commit 3d712546d8ba9f25cdf080d79f90482aa4231ed4 upstream.
    
    Start off with a clean slate that only reads exactly from arg_start to
    arg_end, without any oddities.  This simplifies the code and in the
    process removes the case that caused us to potentially leak an
    uninitialized byte from the temporary kernel buffer.
    
    Note that in order to start from scratch with an understandable base,
    this simplifies things _too_ much, and removes all the legacy logic to
    handle setproctitle() having changed the argument strings.
    
    We'll add back those special cases very differently in the next commit.
    
    Link: https://lore.kernel.org/lkml/20190712160913.17727-1-izbyshev@ispras.ru/
    Fixes: f5b65348fd77 ("proc: fix missing final NUL in get_mm_cmdline() rewrite")
    Cc: Alexey Izbyshev <izbyshev@ispras.ru>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a3915f17ab7746a4c7499e086fb7318bda9461
Author: Jann Horn <jannh@google.com>
Date:   Tue Jul 16 17:20:47 2019 +0200

    sched/fair: Use RCU accessors consistently for ->numa_group
    
    commit cb361d8cdef69990f6b4504dc1fd9a594d983c97 upstream.
    
    The old code used RCU annotations and accessors inconsistently for
    ->numa_group, which can lead to use-after-frees and NULL dereferences.
    
    Let all accesses to ->numa_group use proper RCU helpers to prevent such
    issues.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will@kernel.org>
    Fixes: 8c8a743c5087 ("sched/numa: Use {cpu, pid} to create task groups for shared faults")
    Link: https://lkml.kernel.org/r/20190716152047.14424-3-jannh@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48046e092ad557a01d7daf53205624944793b19d
Author: Jann Horn <jannh@google.com>
Date:   Tue Jul 16 17:20:45 2019 +0200

    sched/fair: Don't free p->numa_faults with concurrent readers
    
    commit 16d51a590a8ce3befb1308e0e7ab77f3b661af33 upstream.
    
    When going through execve(), zero out the NUMA fault statistics instead of
    freeing them.
    
    During execve, the task is reachable through procfs and the scheduler. A
    concurrent /proc/*/sched reader can read data from a freed ->numa_faults
    allocation (confirmed by KASAN) and write it back to userspace.
    I believe that it would also be possible for a use-after-free read to occur
    through a race between a NUMA fault and execve(): task_numa_fault() can
    lead to task_numa_compare(), which invokes task_weight() on the currently
    running task of a different CPU.
    
    Another way to fix this would be to make ->numa_faults RCU-managed or add
    extra locking, but it seems easier to wipe the NUMA fault statistics on
    execve.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will@kernel.org>
    Fixes: 82727018b0d3 ("sched/numa: Call task_numa_free() from do_execve()")
    Link: https://lkml.kernel.org/r/20190716152047.14424-1-jannh@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02cdc166128cf9cb2be4786b997eebbc0b976bfa
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri May 17 00:29:52 2019 -0400

    vhost: scsi: add weight support
    
    commit c1ea02f15ab5efb3e93fc3144d895410bf79fcf2 upstream.
    
    This patch will check the weight and exit the loop if we exceeds the
    weight. This is useful for preventing scsi kthread from hogging cpu
    which is guest triggerable.
    
    This addresses CVE-2019-3900.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Fixes: 057cbf49a1f0 ("tcm_vhost: Initial merge for vhost level target fabric driver")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    [jwang: backport to 4.19]
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 239910101c4ebf91a00e6f4a81ac3144b121f0c4
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri May 17 00:29:51 2019 -0400

    vhost: vsock: add weight support
    
    commit e79b431fb901ba1106670bcc80b9b617b25def7d upstream.
    
    This patch will check the weight and exit the loop if we exceeds the
    weight. This is useful for preventing vsock kthread from hogging cpu
    which is guest triggerable. The weight can help to avoid starving the
    request from on direction while another direction is being processed.
    
    The value of weight is picked from vhost-net.
    
    This addresses CVE-2019-3900.
    
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3af3b843aee41ed22343b011a4cf3812a80d2f38
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri May 17 00:29:50 2019 -0400

    vhost_net: fix possible infinite loop
    
    commit e2412c07f8f3040593dfb88207865a3cd58680c0 upstream.
    
    When the rx buffer is too small for a packet, we will discard the vq
    descriptor and retry it for the next packet:
    
    while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk,
                                                  &busyloop_intr))) {
    ...
            /* On overrun, truncate and discard */
            if (unlikely(headcount > UIO_MAXIOV)) {
                    iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
                    err = sock->ops->recvmsg(sock, &msg,
                                             1, MSG_DONTWAIT | MSG_TRUNC);
                    pr_debug("Discarded rx packet: len %zd\n", sock_len);
                    continue;
            }
    ...
    }
    
    This makes it possible to trigger a infinite while..continue loop
    through the co-opreation of two VMs like:
    
    1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the
       vhost process as much as possible e.g using indirect descriptors or
       other.
    2) Malicious VM2 generate packets to VM1 as fast as possible
    
    Fixing this by checking against weight at the end of RX and TX
    loop. This also eliminate other similar cases when:
    
    - userspace is consuming the packets in the meanwhile
    - theoretical TOCTOU attack if guest moving avail index back and forth
      to hit the continue after vhost find guest just add new buffers
    
    This addresses CVE-2019-3900.
    
    Fixes: d8316f3991d20 ("vhost: fix total length when packets are too short")
    Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    [jwang: backport to 4.19]
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad5fc8953d61b99f445db447ac1eadc99a00d47e
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri May 17 00:29:49 2019 -0400

    vhost: introduce vhost_exceeds_weight()
    
    commit e82b9b0727ff6d665fff2d326162b460dded554d upstream.
    
    We used to have vhost_exceeds_weight() for vhost-net to:
    
    - prevent vhost kthread from hogging the cpu
    - balance the time spent between TX and RX
    
    This function could be useful for vsock and scsi as well. So move it
    to vhost.c. Device must specify a weight which counts the number of
    requests, or it can also specific a byte_weight which counts the
    number of bytes that has been processed.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    [jwang: backport to 4.19, fix conflict in net.c]
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56966212e23f82ced10831f7cca02f7339147428
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Tue Jul 30 11:33:45 2019 +0200

    Bluetooth: hci_uart: check for missing tty operations
    
    commit b36a1552d7319bbfd5cf7f08726c23c5c66d4f73 upstream.
    
    Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
    functions which are called by the certain HCI UART protocols (hci_ath,
    hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
    or directly. This leads to an execution at NULL and can be triggered by
    an unprivileged user. Fix this by adding a helper function and a check
    for the missing tty operations in the protocols code.
    
    This fixes CVE-2019-10207. The Fixes: lines list commits where calls to
    tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART
    protocols.
    
    Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
    Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org # v2.6.36+
    Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip")
    Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions")
    Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support")
    Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support")
    Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Reviewed-by: Yu-Chen, Cho <acho@suse.com>
    Tested-by: Yu-Chen, Cho <acho@suse.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a0c22cbc5d0b570a2cc9a7cffa1ac715fe564b7
Author: Joerg Roedel <jroedel@suse.de>
Date:   Tue Jul 23 09:51:00 2019 +0200

    iommu/iova: Fix compilation error with !CONFIG_IOMMU_IOVA
    
    commit 201c1db90cd643282185a00770f12f95da330eca upstream.
    
    The stub function for !CONFIG_IOMMU_IOVA needs to be
    'static inline'.
    
    Fixes: effa467870c76 ('iommu/vt-d: Don't queue_iova() if there is no flush queue')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fd0eb60bad18067b6ebc2764913697b9a373bf3
Author: Dmitry Safonov <dima@arista.com>
Date:   Tue Jul 16 22:38:05 2019 +0100

    iommu/vt-d: Don't queue_iova() if there is no flush queue
    
    commit effa467870c7612012885df4e246bdb8ffd8e44c upstream.
    
    Intel VT-d driver was reworked to use common deferred flushing
    implementation. Previously there was one global per-cpu flush queue,
    afterwards - one per domain.
    
    Before deferring a flush, the queue should be allocated and initialized.
    
    Currently only domains with IOMMU_DOMAIN_DMA type initialize their flush
    queue. It's probably worth to init it for static or unmanaged domains
    too, but it may be arguable - I'm leaving it to iommu folks.
    
    Prevent queuing an iova flush if the domain doesn't have a queue.
    The defensive check seems to be worth to keep even if queue would be
    initialized for all kinds of domains. And is easy backportable.
    
    On 4.19.43 stable kernel it has a user-visible effect: previously for
    devices in si domain there were crashes, on sata devices:
    
     BUG: spinlock bad magic on CPU#6, swapper/0/1
      lock: 0xffff88844f582008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
     CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #1
     Call Trace:
      <IRQ>
      dump_stack+0x61/0x7e
      spin_bug+0x9d/0xa3
      do_raw_spin_lock+0x22/0x8e
      _raw_spin_lock_irqsave+0x32/0x3a
      queue_iova+0x45/0x115
      intel_unmap+0x107/0x113
      intel_unmap_sg+0x6b/0x76
      __ata_qc_complete+0x7f/0x103
      ata_qc_complete+0x9b/0x26a
      ata_qc_complete_multiple+0xd0/0xe3
      ahci_handle_port_interrupt+0x3ee/0x48a
      ahci_handle_port_intr+0x73/0xa9
      ahci_single_level_irq_intr+0x40/0x60
      __handle_irq_event_percpu+0x7f/0x19a
      handle_irq_event_percpu+0x32/0x72
      handle_irq_event+0x38/0x56
      handle_edge_irq+0x102/0x121
      handle_irq+0x147/0x15c
      do_IRQ+0x66/0xf2
      common_interrupt+0xf/0xf
     RIP: 0010:__do_softirq+0x8c/0x2df
    
    The same for usb devices that use ehci-pci:
     BUG: spinlock bad magic on CPU#0, swapper/0/1
      lock: 0xffff88844f402008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #4
     Call Trace:
      <IRQ>
      dump_stack+0x61/0x7e
      spin_bug+0x9d/0xa3
      do_raw_spin_lock+0x22/0x8e
      _raw_spin_lock_irqsave+0x32/0x3a
      queue_iova+0x77/0x145
      intel_unmap+0x107/0x113
      intel_unmap_page+0xe/0x10
      usb_hcd_unmap_urb_setup_for_dma+0x53/0x9d
      usb_hcd_unmap_urb_for_dma+0x17/0x100
      unmap_urb_for_dma+0x22/0x24
      __usb_hcd_giveback_urb+0x51/0xc3
      usb_giveback_urb_bh+0x97/0xde
      tasklet_action_common.isra.4+0x5f/0xa1
      tasklet_action+0x2d/0x30
      __do_softirq+0x138/0x2df
      irq_exit+0x7d/0x8b
      smp_apic_timer_interrupt+0x10f/0x151
      apic_timer_interrupt+0xf/0x20
      </IRQ>
     RIP: 0010:_raw_spin_unlock_irqrestore+0x17/0x39
    
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Lu Baolu <baolu.lu@linux.intel.com>
    Cc: iommu@lists.linux-foundation.org
    Cc: <stable@vger.kernel.org> # 4.14+
    Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing")
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    [v4.14-port notes:
    o minor conflict with untrusted IOMMU devices check under if-condition]
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3836af8560e27cd0d27940ff9c5a08b90b8d256
Author: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Date:   Fri Jun 21 21:04:38 2019 -0400

    media: radio-raremono: change devm_k*alloc to k*alloc
    
    commit c666355e60ddb4748ead3bdd983e3f7f2224aaf0 upstream.
    
    Change devm_k*alloc to k*alloc to manually allocate memory
    
    The manual allocation and freeing of memory is necessary because when
    the USB radio is disconnected, the memory associated with devm_k*alloc
    is freed. Meaning if we still have unresolved references to the radio
    device, then we get use-after-free errors.
    
    This patch fixes this by manually allocating memory, and freeing it in
    the v4l2.release callback that gets called when the last radio device
    exits.
    
    Reported-and-tested-by: syzbot+a4387f5b6b799f6becbf@syzkaller.appspotmail.com
    
    Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    [hverkuil-cisco@xs4all.nl: cleaned up two small checkpatch.pl warnings]
    [hverkuil-cisco@xs4all.nl: prefix subject with driver name]
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afb5340f9438f15312de8dd5ef6de1960a30f74d
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Tue Jun 11 12:57:52 2019 -0400

    NFS: Cleanup if nfs_match_client is interrupted
    
    commit 9f7761cf0409465075dadb875d5d4b8ef2f890c8 upstream.
    
    Don't bail out before cleaning up a new allocation if the wait for
    searching for a matching nfs client is interrupted.  Memory leaks.
    
    Reported-by: syzbot+7fe11b49c1cc30e3fce2@syzkaller.appspotmail.com
    Fixes: 950a578c6128 ("NFS: make nfs_match_client killable")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8edcabb2c2e9c3f8234718918c8808c79fd74aeb
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu May 2 12:09:26 2019 -0400

    media: pvrusb2: use a different format for warnings
    
    commit 1753c7c4367aa1201e1e5d0a601897ab33444af1 upstream.
    
    When the pvrusb2 driver detects that there's something wrong with the
    device, it prints a warning message. Right now those message are
    printed in two different formats:
    
    1. ***WARNING*** message here
    2. WARNING: message here
    
    There's an issue with the second format. Syzkaller recognizes it as a
    message produced by a WARN_ON(), which is used to indicate a bug in the
    kernel. However pvrusb2 prints those warnings to indicate an issue with
    the device, not the bug in the kernel.
    
    This patch changes the pvrusb2 driver to consistently use the first
    warning message format. This will unblock syzkaller testing of this
    driver.
    
    Reported-by: syzbot+af8f8d2ac0d39b0ed3a0@syzkaller.appspotmail.com
    Reported-by: syzbot+170a86bf206dd2c6217e@syzkaller.appspotmail.com
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b44cc225e6024174508164931cab9f01c79dca2
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu May 9 04:57:09 2019 -0400

    media: cpia2_usb: first wake up, then free in disconnect
    
    commit eff73de2b1600ad8230692f00bc0ab49b166512a upstream.
    
    Kasan reported a use after free in cpia2_usb_disconnect()
    It first freed everything and then woke up those waiting.
    The reverse order is correct.
    
    Fixes: 6c493f8b28c67 ("[media] cpia2: major overhaul to get it in a working state again")
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reported-by: syzbot+0c90fc937c84f97d0aa6@syzkaller.appspotmail.com
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 693019ee7d98b4d6233e64af82d531c574d5c53b
Author: Fabio Estevam <festevam@gmail.com>
Date:   Thu May 9 09:15:00 2019 -0300

    ath10k: Change the warning message string
    
    commit 265df32eae5845212ad9f55f5ae6b6dcb68b187b upstream.
    
    The "WARNING" string confuses syzbot, which thinks it found
    a crash [1].
    
    Change the string to avoid such problem.
    
    [1] https://lkml.org/lkml/2019/5/9/243
    
    Reported-by: syzbot+c1b25598aa60dcd47e78@syzkaller.appspotmail.com
    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cf6a070708895b1f7b1d54a8519ea46fdd4262b
Author: Sean Young <sean@mess.org>
Date:   Sun May 19 15:28:22 2019 -0400

    media: au0828: fix null dereference in error path
    
    commit 6d0d1ff9ff21fbb06b867c13a1d41ce8ddcd8230 upstream.
    
    au0828_usb_disconnect() gets the au0828_dev struct via usb_get_intfdata,
    so it needs to set up for the error paths.
    
    Reported-by: syzbot+357d86bcb4cca1a2f572@syzkaller.appspotmail.com
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f13ee5ae0b2f3c0e2e26287394de7c645d0d8d7d
Author: Phong Tran <tranmanphong@gmail.com>
Date:   Mon Jul 15 22:08:14 2019 +0700

    ISDN: hfcsusb: checking idx of ep configuration
    
    commit f384e62a82ba5d85408405fdd6aeff89354deaa9 upstream.
    
    The syzbot test with random endpoint address which made the idx is
    overflow in the table of endpoint configuations.
    
    this adds the checking for fixing the error report from
    syzbot
    
    KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
    The patch tested by syzbot [2]
    
    Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
    
    [1]:
    https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
    [2]:
    https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
    
    Signed-off-by: Phong Tran <tranmanphong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22068d49d09d2b3890e19d7b2048a33340f992da
Author: Todd Kjos <tkjos@android.com>
Date:   Wed Jun 12 13:29:27 2019 -0700

    binder: fix possible UAF when freeing buffer
    
    commit a370003cc301d4361bae20c9ef615f89bf8d1e8a upstream.
    
    There is a race between the binder driver cleaning
    up a completed transaction via binder_free_transaction()
    and a user calling binder_ioctl(BC_FREE_BUFFER) to
    release a buffer. It doesn't matter which is first but
    they need to be protected against running concurrently
    which can result in a UAF.
    
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba2c247a451570c2bbc9f248b0a8730dcd4146a2
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Sep 5 15:34:43 2018 +0100

    arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ
    
    commit 24951465cbd279f60b1fdc2421b3694405bcff42 upstream.
    
    arch/arm/ defines a SIGMINSTKSZ of 2k, so we should use the same value
    for compat tasks.
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: Dave Martin <Dave.Martin@arm.com>
    Reported-by: Steve McIntyre <steve.mcintyre@arm.com>
    Tested-by: Steve McIntyre <93sam@debian.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b544a6855dfb7afee0ad498ce7d57ef4ce3a2dd8
Author: Minas Harutyunyan <minas.harutyunyan@synopsys.com>
Date:   Mon Dec 10 18:09:32 2018 +0400

    usb: dwc2: Fix disable all EP's on disconnect
    
    commit 4fe4f9fecc36956fd53c8edf96dd0c691ef98ff9 upstream.
    
    Disabling all EP's allow to reset EP's to initial state.
    Introduced new function dwc2_hsotg_ep_disable_lock() which
    before calling dwc2_hsotg_ep_disable() function acquire
    hsotg->lock and release on exiting.
    From dwc2_hsotg_ep_disable() function removed acquiring
    hsotg->lock.
    In dwc2_hsotg_core_init_disconnected() function when USB
    reset interrupt asserted disabling all ep’s by
    dwc2_hsotg_ep_disable() function.
    This updates eliminating sparse imbalance warnings.
    
    Reverted changes in dwc2_hostg_disconnect() function.
    Introduced new function dwc2_hsotg_ep_disable_lock().
    Changed dwc2_hsotg_ep_ops. Now disable point to
    dwc2_hsotg_ep_disable_lock() function.
    In functions dwc2_hsotg_udc_stop() and dwc2_hsotg_suspend()
    dwc2_hsotg_ep_disable() function replaced by
    dwc2_hsotg_ep_disable_lock() function.
    In dwc2_hsotg_ep_disable() function removed acquiring
    of hsotg->lock.
    
    Fixes: dccf1bad4be7 ("usb: dwc2: Disable all EP's on disconnect")
    Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec58bfa2d4120ea39ef39c8e54abcde461f94248
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Wed Sep 19 18:13:52 2018 +0400

    usb: dwc2: Disable all EP's on disconnect
    
    commit dccf1bad4be7eaa096c1f3697bd37883f9a08ecb upstream.
    
    Disabling all EP's allow to reset EP's to initial state.
    On disconnect disable all EP's instead of just killing
    all requests. Because of some platform didn't catch
    disconnect event, same stuff added to
    dwc2_hsotg_core_init_disconnected() function when USB
    reset detected on the bus.
    
    Changed from version 1:
    Changed lock acquire flow in dwc2_hsotg_ep_disable()
    function.
    
    Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e441c7844a6223e20105a9e4316079f7b26f15c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Sep 28 12:42:51 2018 -0400

    NFSv4: Fix lookup revalidate of regular files
    
    commit c7944ebb9ce9461079659e9e6ec5baaf73724b3b upstream.
    
    If we're revalidating an existing dentry in order to open a file, we need
    to ensure that we check the directory has not changed before we optimise
    away the lookup.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Qian Lu <luqia@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24acd93f59955956c1ae825ed7773f63ff5cbfdb
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Sep 28 09:04:05 2018 -0400

    NFS: Refactor nfs_lookup_revalidate()
    
    commit 5ceb9d7fdaaf6d8ced6cd7861cf1deb9cd93fa47 upstream.
    
    Refactor the code in nfs_lookup_revalidate() as a stepping stone towards
    optimising and fixing nfs4_lookup_revalidate().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Qian Lu <luqia@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01eea1cbba9d8309851f63356fa2f20a790af98f
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Sep 27 17:12:33 2018 -0400

    NFS: Fix dentry revalidation on NFSv4 lookup
    
    commit be189f7e7f03de35887e5a85ddcf39b91b5d7fc1 upstream.
    
    We need to ensure that inode and dentry revalidation occurs correctly
    on reopen of a file that is already open. Currently, we can end up
    not revalidating either in the case of NFSv4.0, due to the 'cached open'
    path.
    Let's fix that by ensuring that we only do cached open for the special
    cases of open recovery and delegation return.
    
    Reported-by: Stan Hu <stanhu@gmail.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Qian Lu <luqia@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a474bc4e6135cfdcd1573f0071e0b1b4318b307
Author: Sunil Muthuswamy <sunilmut@microsoft.com>
Date:   Thu Jun 13 03:52:27 2019 +0000

    vsock: correct removal of socket from the list
    
    commit d5afa82c977ea06f7119058fa0eb8519ea501031 upstream.
    
    The current vsock code for removal of socket from the list is both
    subject to race and inefficient. It takes the lock, checks whether
    the socket is in the list, drops the lock and if the socket was on the
    list, deletes it from the list. This is subject to race because as soon
    as the lock is dropped once it is checked for presence, that condition
    cannot be relied upon for any decision. It is also inefficient because
    if the socket is present in the list, it takes the lock twice.
    
    Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d3586bcdae3ad6be352e5f551894c66c41e6dcd
Author: Sunil Muthuswamy <sunilmut@microsoft.com>
Date:   Wed May 15 00:56:05 2019 +0000

    hv_sock: Add support for delayed close
    
    commit a9eeb998c28d5506616426bd3a216bd5735a18b8 upstream.
    
    Currently, hvsock does not implement any delayed or background close
    logic. Whenever the hvsock socket is closed, a FIN is sent to the peer, and
    the last reference to the socket is dropped, which leads to a call to
    .destruct where the socket can hang indefinitely waiting for the peer to
    close it's side. The can cause the user application to hang in the close()
    call.
    
    This change implements proper STREAM(TCP) closing handshake mechanism by
    sending the FIN to the peer and the waiting for the peer's FIN to arrive
    for a given timeout. On timeout, it will try to terminate the connection
    (i.e. a RST). This is in-line with other socket providers such as virtio.
    
    This change does not address the hang in the vmbus_hvsock_device_unregister
    where it waits indefinitely for the host to rescind the channel. That
    should be taken up as a separate fix.
    
    Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
