commit c13f051b7fc041d3163a96b10441b421ddecd123
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 15 12:59:57 2021 +0200

    Linux 4.4.281
    
    Link: https://lore.kernel.org/r/20210813150520.718161915@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6e8810d25295acb40a7b69ed3962ff181919571
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Aug 9 10:19:47 2021 +0200

    ovl: prevent private clone if bind mount is not allowed
    
    commit 427215d85e8d1476da1a86b8d67aceb485eb3631 upstream.
    
    Add the following checks from __do_loopback() to clone_private_mount() as
    well:
    
     - verify that the mount is in the current namespace
    
     - verify that there are no locked children
    
    Reported-by: Alois Wohlschlager <alois1@gmx-topmail.de>
    Fixes: c771d683a62e ("vfs: introduce clone_private_mount()")
    Cc: <stable@vger.kernel.org> # v3.18
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d4ba14fc5ffbe5712055af09a5c0cbab93c0f44
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed May 19 10:47:04 2021 +0800

    net: xilinx_emaclite: Do not print real IOMEM pointer
    
    commit d0d62baa7f505bd4c59cd169692ff07ec49dde37 upstream.
    
    Printing kernel pointers is discouraged because they might leak kernel
    memory layout.  This fixes smatch warning:
    
    drivers/net/ethernet/xilinx/xilinx_emaclite.c:1191 xemaclite_of_probe() warn:
     argument 4 to %08lX specifier is cast from pointer
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Pavel Machek (CIP) <pavel@denx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c643a57ca5bcb01cd97193555f67a2b506739e59
Author: Longfang Liu <liulongfang@huawei.com>
Date:   Fri Apr 9 16:48:01 2021 +0800

    USB:ehci:fix Kunpeng920 ehci hardware problem
    
    commit 26b75952ca0b8b4b3050adb9582c8e2f44d49687 upstream.
    
    Kunpeng920's EHCI controller does not have SBRN register.
    Reading the SBRN register when the controller driver is
    initialized will get 0.
    
    When rebooting the EHCI driver, ehci_shutdown() will be called.
    if the sbrn flag is 0, ehci_shutdown() will return directly.
    The sbrn flag being 0 will cause the EHCI interrupt signal to
    not be turned off after reboot. this interrupt that is not closed
    will cause an exception to the device sharing the interrupt.
    
    Therefore, the EHCI controller of Kunpeng920 needs to skip
    the read operation of the SBRN register.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Longfang Liu <liulongfang@huawei.com>
    Link: https://lore.kernel.org/r/1617958081-17999-1-git-send-email-liulongfang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7392701d8615e923cc7ce55cd10e7155189a0062
Author: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Date:   Thu Aug 5 10:40:47 2021 -0400

    pipe: increase minimum default pipe size to 2 pages
    
    commit 46c4c9d1beb7f5b4cec4dd90e7728720583ee348 upstream.
    
    This program always prints 4096 and hangs before the patch, and always
    prints 8192 and exits successfully after:
    
      int main()
      {
          int pipefd[2];
          for (int i = 0; i < 1025; i++)
              if (pipe(pipefd) == -1)
                  return 1;
          size_t bufsz = fcntl(pipefd[1], F_GETPIPE_SZ);
          printf("%zd\n", bufsz);
          char *buf = calloc(bufsz, 1);
          write(pipefd[1], buf, bufsz);
          read(pipefd[0], buf, bufsz-1);
          write(pipefd[1], buf, 1);
      }
    
    Note that you may need to increase your RLIMIT_NOFILE before running the
    program.
    
    Fixes: 759c01142a ("pipe: limit the per-user amount of pages allocated in pipes")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/lkml/1628086770.5rn8p04n6j.none@localhost/
    Link: https://lore.kernel.org/lkml/1628127094.lxxn016tj7.none@localhost/
    Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07d4712300d9e2da54675ce10831a7996b4e939e
Author: Letu Ren <fantasquex@gmail.com>
Date:   Sun Jul 25 21:45:12 2021 +0800

    net/qla3xxx: fix schedule while atomic in ql_wait_for_drvr_lock and ql_adapter_reset
    
    [ Upstream commit 92766c4628ea349c8ddab0cd7bd0488f36e5c4ce ]
    
    When calling the 'ql_wait_for_drvr_lock' and 'ql_adapter_reset', the driver
    has already acquired the spin lock, so the driver should not call 'ssleep'
    in atomic context.
    
    This bug can be fixed by using 'mdelay' instead of 'ssleep'.
    
    Reported-by: Letu Ren <fantasquex@gmail.com>
    Signed-off-by: Letu Ren <fantasquex@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edecf9a90bd8e90325122cbc57636662e99b54ad
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Tue Jan 5 10:16:27 2021 -0500

    alpha: Send stop IPI to send to online CPUs
    
    [ Upstream commit caace6ca4e06f09413fb8f8a63319594cfb7d47d ]
    
    This issue was noticed while debugging a shutdown issue where some
    secondary CPUs are not being shutdown correctly.  A fix for that [1] requires
    that secondary cpus be offlined using the cpu_online_mask so that the
    stop operation is a no-op if CPU HOTPLUG is disabled.  I, like the author in
    [1] looked at the architectures and found that alpha is one of two
    architectures that executes smp_send_stop() on all possible CPUs.
    
    On alpha, smp_send_stop() sends an IPI to all possible CPUs but only needs
    to send them to online CPUs.
    
    Send the stop IPI to only the online CPUs.
    
    [1] https://lkml.org/lkml/2020/1/10/250
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ababa17d7a14fd79eb92a5c135a999a6a51413f
Author: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
Date:   Fri Jul 9 20:59:29 2021 +0530

    reiserfs: check directory items on read from disk
    
    [ Upstream commit 13d257503c0930010ef9eed78b689cec417ab741 ]
    
    While verifying the leaf item that we read from the disk, reiserfs
    doesn't check the directory items, this could cause a crash when we
    read a directory item from the disk that has an invalid deh_location.
    
    This patch adds a check to the directory items read from the disk that
    does a bounds check on deh_location for the directory entries. Any
    directory entry header with a directory entry offset greater than the
    item length is considered invalid.
    
    Link: https://lore.kernel.org/r/20210709152929.766363-1-chouhan.shreyansh630@gmail.com
    Reported-by: syzbot+c31a48e6702ccb3d64c9@syzkaller.appspotmail.com
    Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbddd8fc929d04158aa9c1931736a05d27dee1ec
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Jul 2 12:07:43 2021 +0800

    reiserfs: add check for root_inode in reiserfs_fill_super
    
    [ Upstream commit 2acf15b94d5b8ea8392c4b6753a6ffac3135cd78 ]
    
    Our syzcaller report a NULL pointer dereference:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    PGD 116e95067 P4D 116e95067 PUD 1080b5067 PMD 0
    Oops: 0010 [#1] SMP KASAN
    CPU: 7 PID: 592 Comm: a.out Not tainted 5.13.0-next-20210629-dirty #67
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-p4
    RIP: 0010:0x0
    Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
    RSP: 0018:ffff888114e779b8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 1ffff110229cef39 RCX: ffffffffaa67e1aa
    RDX: 0000000000000000 RSI: ffff88810a58ee00 RDI: ffff8881233180b0
    RBP: ffffffffac38e9c0 R08: ffffffffaa67e17e R09: 0000000000000001
    R10: ffffffffb91c5557 R11: fffffbfff7238aaa R12: ffff88810a58ee00
    R13: ffff888114e77aa0 R14: 0000000000000000 R15: ffff8881233180b0
    FS:  00007f946163c480(0000) GS:ffff88839f1c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffffffffd6 CR3: 00000001099c1000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     __lookup_slow+0x116/0x2d0
     ? page_put_link+0x120/0x120
     ? __d_lookup+0xfc/0x320
     ? d_lookup+0x49/0x90
     lookup_one_len+0x13c/0x170
     ? __lookup_slow+0x2d0/0x2d0
     ? reiserfs_schedule_old_flush+0x31/0x130
     reiserfs_lookup_privroot+0x64/0x150
     reiserfs_fill_super+0x158c/0x1b90
     ? finish_unfinished+0xb10/0xb10
     ? bprintf+0xe0/0xe0
     ? __mutex_lock_slowpath+0x30/0x30
     ? __kasan_check_write+0x20/0x30
     ? up_write+0x51/0xb0
     ? set_blocksize+0x9f/0x1f0
     mount_bdev+0x27c/0x2d0
     ? finish_unfinished+0xb10/0xb10
     ? reiserfs_kill_sb+0x120/0x120
     get_super_block+0x19/0x30
     legacy_get_tree+0x76/0xf0
     vfs_get_tree+0x49/0x160
     ? capable+0x1d/0x30
     path_mount+0xacc/0x1380
     ? putname+0x97/0xd0
     ? finish_automount+0x450/0x450
     ? kmem_cache_free+0xf8/0x5a0
     ? putname+0x97/0xd0
     do_mount+0xe2/0x110
     ? path_mount+0x1380/0x1380
     ? copy_mount_options+0x69/0x140
     __x64_sys_mount+0xf0/0x190
     do_syscall_64+0x35/0x80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    This is because 'root_inode' is initialized with wrong mode, and
    it's i_op is set to 'reiserfs_special_inode_operations'. Thus add
    check for 'root_inode' to fix the problem.
    
    Link: https://lore.kernel.org/r/20210702040743.1918552-1-yukuai3@huawei.com
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e595b468db73bb4632a6151c1d5b6374b4daf5ba
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Tue Jun 22 07:11:31 2021 +0000

    pcmcia: i82092: fix a null pointer dereference bug
    
    commit e39cdacf2f664b09029e7c1eb354c91a20c367af upstream.
    
    During the driver loading process, the 'dev' field was not assigned, but
    the 'dev' field was referenced in the subsequent 'i82092aa_set_mem_map'
    function.
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    CC: <stable@vger.kernel.org>
    [linux@dominikbrodowski.net: shorten commit message, add Cc to stable]
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c824d48e2ec220e669c166e18b17678f3ba324d
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Sat Jun 26 06:11:13 2021 +0200

    MIPS: Malta: Do not byte-swap accesses to the CBUS UART
    
    commit 9a936d6c3d3d6c33ecbadf72dccdb567b5cd3c72 upstream.
    
    Correct big-endian accesses to the CBUS UART, a Malta on-board discrete
    TI16C550C part wired directly to the system controller's device bus, and
    do not use byte swapping with the 32-bit accesses to the device.
    
    The CBUS is used for devices such as the boot flash memory needed early
    on in system bootstrap even before PCI has been initialised.  Therefore
    it uses the system controller's device bus, which follows the endianness
    set with the CPU, which means no byte-swapping is ever required for data
    accesses to CBUS, unlike with PCI.
    
    The CBUS UART uses the UPIO_MEM32 access method, that is the `readl' and
    `writel' MMIO accessors, which on the MIPS platform imply byte-swapping
    with PCI systems.  Consequently the wrong byte lane is accessed with the
    big-endian configuration and the UART is not correctly accessed.
    
    As it happens the UPIO_MEM32BE access method makes use of the `ioread32'
    and `iowrite32' MMIO accessors, which still use `readl' and `writel'
    respectively, however they byte-swap data passed, effectively cancelling
    swapping done with the accessors themselves and making it suitable for
    the CBUS UART.
    
    Make the CBUS UART switch between UPIO_MEM32 and UPIO_MEM32BE then,
    based on the endianness selected.  With this change in place the device
    is correctly recognised with big-endian Malta at boot, along with the
    Super I/O devices behind PCI:
    
    Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
    printk: console [ttyS0] disabled
    serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
    printk: console [ttyS0] enabled
    printk: bootconsole [uart8250] disabled
    serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
    serial8250.0: ttyS2 at MMIO 0x1f000900 (irq = 20, base_baud = 230400) is a 16550A
    
    Fixes: e7c4782f92fc ("[MIPS] Put an end to <asm/serial.h>'s long and annyoing existence")
    Cc: stable@vger.kernel.org # v2.6.23+
    Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260524430.37803@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1174bff45000ed817b4afc6544398090ec08e7d
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Sat Jun 26 06:11:05 2021 +0200

    serial: 8250: Mask out floating 16/32-bit bus bits
    
    commit e5227c51090e165db4b48dcaa300605bfced7014 upstream.
    
    Make sure only actual 8 bits of the IIR register are used in determining
    the port type in `autoconfig'.
    
    The `serial_in' port accessor returns the `unsigned int' type, meaning
    that with UPIO_AU, UPIO_MEM16, UPIO_MEM32, and UPIO_MEM32BE access types
    more than 8 bits of data are returned, of which the high order bits will
    often come from bus lines that are left floating in the data phase.  For
    example with the MIPS Malta board's CBUS UART, where the registers are
    aligned on 8-byte boundaries and which uses 32-bit accesses, data as
    follows is returned:
    
    YAMON> dump -32 0xbf000900 0x40
    
    BF000900: 1F000942 1F000942 1F000900 1F000900  ...B...B........
    BF000910: 1F000901 1F000901 1F000900 1F000900  ................
    BF000920: 1F000900 1F000900 1F000960 1F000960  ...........`...`
    BF000930: 1F000900 1F000900 1F0009FF 1F0009FF  ................
    
    YAMON>
    
    Evidently high-order 24 bits return values previously driven in the
    address phase (the 3 highest order address bits used with the command
    above are masked out in the simple virtual address mapping used here and
    come out at zeros on the external bus), a common scenario with bus lines
    left floating, due to bus capacitance.
    
    Consequently when the value of IIR, mapped at 0x1f000910, is retrieved
    in `autoconfig', it comes out at 0x1f0009c1 and when it is right-shifted
    by 6 and then assigned to 8-bit `scratch' variable, the value calculated
    is 0x27, not one of 0, 1, 2, 3 expected in port type determination.
    
    Fix the issue then, by assigning the value returned from `serial_in' to
    `scratch' first, which masks out 24 high-order bits retrieved, and only
    then right-shift the resulting 8-bit data quantity, producing the value
    of 3 in this case, as expected.  Fix the same issue in `serial_dl_read'.
    
    The problem first appeared with Linux 2.6.9-rc3 which predates our repo
    history, but the origin could be identified with the old MIPS/Linux repo
    also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git>
    as commit e0d2356c0777 ("Merge with Linux 2.6.9-rc3."), where code in
    `serial_in' was updated with this case:
    
    +       case UPIO_MEM32:
    +               return readl(up->port.membase + offset);
    +
    
    which made it produce results outside the unsigned 8-bit range for the
    first time, though obviously it is system dependent what actual values
    appear in the high order bits retrieved and it may well have been zeros
    in the relevant positions with the system the change originally was
    intended for.  It is at that point that code in `autoconf' should have
    been updated accordingly, but clearly it was overlooked.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org # v2.6.12+
    Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260516220.37803@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d1a1fec9e3f70b5baa1fb98f7f326b943640977
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jun 23 10:45:21 2021 +0200

    media: rtl28xxu: fix zero-length control request
    
    commit 76f22c93b209c811bd489950f17f8839adb31901 upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Control transfers without a data stage are treated as OUT requests by
    the USB stack and should be using usb_sndctrlpipe(). Failing to do so
    will now trigger a warning.
    
    The driver uses a zero-length i2c-read request for type detection so
    update the control-request code to use usb_sndctrlpipe() in this case.
    
    Note that actually trying to read the i2c register in question does not
    work as the register might not exist (e.g. depending on the demodulator)
    as reported by Eero Lehtinen <debiangamer2@gmail.com>.
    
    Reported-by: syzbot+faf11bbadc5a372564da@syzkaller.appspotmail.com
    Reported-by: Eero Lehtinen <debiangamer2@gmail.com>
    Tested-by: Eero Lehtinen <debiangamer2@gmail.com>
    Fixes: d0f232e823af ("[media] rtl28xxu: add heuristic to detect chip type")
    Cc: stable@vger.kernel.org      # 4.0
    Cc: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8caad9087a3b39f6eb38e31a7aa2521239d50589
Author: Hui Su <suhui@zeku.com>
Date:   Fri Jun 11 10:21:07 2021 +0800

    scripts/tracing: fix the bug that can't parse raw_trace_func
    
    commit 1c0cec64a7cc545eb49f374a43e9f7190a14defa upstream.
    
    Since commit 77271ce4b2c0 ("tracing: Add irq, preempt-count and need resched info
    to default trace output"), the default trace output format has been changed to:
              <idle>-0       [009] d.h. 22420.068695: _raw_spin_lock_irqsave <-hrtimer_interrupt
              <idle>-0       [000] ..s. 22420.068695: _nohz_idle_balance <-run_rebalance_domains
              <idle>-0       [011] d.h. 22420.068695: account_process_tick <-update_process_times
    
    origin trace output format:(before v3.2.0)
         # tracer: nop
         #
         #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
         #              | |       |          |         |
              migration/0-6     [000]    50.025810: rcu_note_context_switch <-__schedule
              migration/0-6     [000]    50.025812: trace_rcu_utilization <-rcu_note_context_switch
              migration/0-6     [000]    50.025813: rcu_sched_qs <-rcu_note_context_switch
              migration/0-6     [000]    50.025815: rcu_preempt_qs <-rcu_note_context_switch
              migration/0-6     [000]    50.025817: trace_rcu_utilization <-rcu_note_context_switch
              migration/0-6     [000]    50.025818: debug_lockdep_rcu_enabled <-__schedule
              migration/0-6     [000]    50.025820: debug_lockdep_rcu_enabled <-__schedule
    
    The draw_functrace.py(introduced in v2.6.28) can't parse the new version format trace_func,
    So we need modify draw_functrace.py to adapt the new version trace output format.
    
    Link: https://lkml.kernel.org/r/20210611022107.608787-1-suhui@zeku.com
    
    Cc: stable@vger.kernel.org
    Fixes: 77271ce4b2c0 tracing: Add irq, preempt-count and need resched info to default trace output
    Signed-off-by: Hui Su <suhui@zeku.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f3d03fb02354b3560a8d062df0607b9879c46d1
Author: David Bauer <mail@david-bauer.net>
Date:   Thu Aug 5 01:25:22 2021 +0200

    USB: serial: ftdi_sio: add device ID for Auto-M3 OP-COM v2
    
    commit 8da0e55c7988ef9f08a708c38e5c75ecd8862cf8 upstream.
    
    The Auto-M3 OP-COM v2 is a OBD diagnostic device using a FTD232 for the
    USB connection.
    
    Signed-off-by: David Bauer <mail@david-bauer.net>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e8a43985a2dbac92922f25b40e16fab81959749
Author: Willy Tarreau <w@1wt.eu>
Date:   Sat Jul 24 17:27:39 2021 +0200

    USB: serial: ch341: fix character loss at high transfer rates
    
    commit 3c18e9baee0ef97510dcda78c82285f52626764b upstream.
    
    The chip supports high transfer rates, but with the small default buffers
    (64 bytes read), some entire blocks are regularly lost. This typically
    happens at 1.5 Mbps (which is the default speed on Rockchip devices) when
    used as a console to access U-Boot where the output of the "help" command
    misses many lines and where "printenv" mangles the environment.
    
    The FTDI driver doesn't suffer at all from this. One difference is that
    it uses 512 bytes rx buffers and 256 bytes tx buffers. Adopting these
    values completely resolved the issue, even the output of "dmesg" is
    reliable. I preferred to leave the Tx value unchanged as it is not
    involved in this issue, while a change could increase the risk of
    triggering the same issue with other devices having too small buffers.
    
    I verified that it backports well (and works) at least to 5.4. It's of
    low importance enough to be dropped where it doesn't trivially apply
    anymore.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Link: https://lore.kernel.org/r/20210724152739.18726-1-w@1wt.eu
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1c5bfb10b50505ec4a082dfa88815f3ee23e661
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Aug 3 21:47:11 2021 +0200

    USB: serial: option: add Telit FD980 composition 0x1056
    
    commit 5648c073c33d33a0a19d0cb1194a4eb88efe2b71 upstream.
    
    Add the following Telit FD980 composition 0x1056:
    
    Cfg #1: mass storage
    Cfg #2: rndis, tty, adb, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20210803194711.3036-1-dnlplm@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6ef8bb00aa65eceb413fc165a55086459863e38
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Wed Aug 4 19:26:56 2021 +0900

    Bluetooth: defer cleanup of resources in hci_unregister_dev()
    
    [ Upstream commit e04480920d1eec9c061841399aa6f35b6f987d8b ]
    
    syzbot is hitting might_sleep() warning at hci_sock_dev_event() due to
    calling lock_sock() with rw spinlock held [1].
    
    It seems that history of this locking problem is a trial and error.
    
    Commit b40df5743ee8 ("[PATCH] bluetooth: fix socket locking in
    hci_sock_dev_event()") in 2.6.21-rc4 changed bh_lock_sock() to
    lock_sock() as an attempt to fix lockdep warning.
    
    Then, commit 4ce61d1c7a8e ("[BLUETOOTH]: Fix locking in
    hci_sock_dev_event().") in 2.6.22-rc2 changed lock_sock() to
    local_bh_disable() + bh_lock_sock_nested() as an attempt to fix the
    sleep in atomic context warning.
    
    Then, commit 4b5dd696f81b ("Bluetooth: Remove local_bh_disable() from
    hci_sock.c") in 3.3-rc1 removed local_bh_disable().
    
    Then, commit e305509e678b ("Bluetooth: use correct lock to prevent UAF
    of hdev object") in 5.13-rc5 again changed bh_lock_sock_nested() to
    lock_sock() as an attempt to fix CVE-2021-3573.
    
    This difficulty comes from current implementation that
    hci_sock_dev_event(HCI_DEV_UNREG) is responsible for dropping all
    references from sockets because hci_unregister_dev() immediately
    reclaims resources as soon as returning from
    hci_sock_dev_event(HCI_DEV_UNREG).
    
    But the history suggests that hci_sock_dev_event(HCI_DEV_UNREG) was not
    doing what it should do.
    
    Therefore, instead of trying to detach sockets from device, let's accept
    not detaching sockets from device at hci_sock_dev_event(HCI_DEV_UNREG),
    by moving actual cleanup of resources from hci_unregister_dev() to
    hci_cleanup_dev() which is called by bt_host_release() when all
    references to this unregistered device (which is a kobject) are gone.
    
    Since hci_sock_dev_event(HCI_DEV_UNREG) no longer resets
    hci_pi(sk)->hdev, we need to check whether this device was unregistered
    and return an error based on HCI_UNREGISTER flag.  There might be subtle
    behavioral difference in "monitor the hdev" functionality; please report
    if you found something went wrong due to this patch.
    
    Link: https://syzkaller.appspot.com/bug?extid=a5df189917e79d5e59c9 [1]
    Reported-by: syzbot <syzbot+a5df189917e79d5e59c9@syzkaller.appspotmail.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Fixes: e305509e678b ("Bluetooth: use correct lock to prevent UAF of hdev object")
    Acked-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 914054dc07500ed7836562001f1b9cb0e96c7d5e
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Wed Aug 4 18:52:20 2021 +0300

    net: vxge: fix use-after-free in vxge_device_unregister
    
    [ Upstream commit 942e560a3d3862dd5dee1411dbdd7097d29b8416 ]
    
    Smatch says:
    drivers/net/ethernet/neterion/vxge/vxge-main.c:3518 vxge_device_unregister() error: Using vdev after free_{netdev,candev}(dev);
    drivers/net/ethernet/neterion/vxge/vxge-main.c:3518 vxge_device_unregister() error: Using vdev after free_{netdev,candev}(dev);
    drivers/net/ethernet/neterion/vxge/vxge-main.c:3520 vxge_device_unregister() error: Using vdev after free_{netdev,candev}(dev);
    drivers/net/ethernet/neterion/vxge/vxge-main.c:3520 vxge_device_unregister() error: Using vdev after free_{netdev,candev}(dev);
    
    Since vdev pointer is netdev private data accessing it after free_netdev()
    call can cause use-after-free bug. Fix it by moving free_netdev() call at
    the end of the function
    
    Fixes: 6cca200362b4 ("vxge: cleanup probe error paths")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6dde2ac56c566fff5d91ae58bd6a1409e6e3895f
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Wed Aug 4 17:30:05 2021 +0300

    net: pegasus: fix uninit-value in get_interrupt_interval
    
    [ Upstream commit af35fc37354cda3c9c8cc4961b1d24bdc9d27903 ]
    
    Syzbot reported uninit value pegasus_probe(). The problem was in missing
    error handling.
    
    get_interrupt_interval() internally calls read_eprom_word() which can
    fail in some cases. For example: failed to receive usb control message.
    These cases should be handled to prevent uninit value bug, since
    read_eprom_word() will not initialize passed stack variable in case of
    internal failure.
    
    Fail log:
    
    BUG: KMSAN: uninit-value in get_interrupt_interval drivers/net/usb/pegasus.c:746 [inline]
    BUG: KMSAN: uninit-value in pegasus_probe+0x10e7/0x4080 drivers/net/usb/pegasus.c:1152
    CPU: 1 PID: 825 Comm: kworker/1:1 Not tainted 5.12.0-rc6-syzkaller #0
    ...
    Workqueue: usb_hub_wq hub_event
    Call Trace:
     __dump_stack lib/dump_stack.c:79 [inline]
     dump_stack+0x24c/0x2e0 lib/dump_stack.c:120
     kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118
     __msan_warning+0x5c/0xa0 mm/kmsan/kmsan_instr.c:197
     get_interrupt_interval drivers/net/usb/pegasus.c:746 [inline]
     pegasus_probe+0x10e7/0x4080 drivers/net/usb/pegasus.c:1152
    ....
    
    Local variable ----data.i@pegasus_probe created at:
     get_interrupt_interval drivers/net/usb/pegasus.c:1151 [inline]
     pegasus_probe+0xe57/0x4080 drivers/net/usb/pegasus.c:1152
     get_interrupt_interval drivers/net/usb/pegasus.c:1151 [inline]
     pegasus_probe+0xe57/0x4080 drivers/net/usb/pegasus.c:1152
    
    Reported-and-tested-by: syzbot+02c9f70f3afae308464a@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/20210804143005.439-1-paskripkin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bc5fdab77e1f8de4c09741ebf9fae92d23d3d66
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 5 13:38:26 2021 +0300

    bnx2x: fix an error code in bnx2x_nic_load()
    
    [ Upstream commit fb653827c758725b149b5c924a5eb50ab4812750 ]
    
    Set the error code if bnx2x_alloc_fw_stats_mem() fails.  The current
    code returns success.
    
    Fixes: ad5afc89365e ("bnx2x: Separate VF and PF logic")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2386d801f2e70a851c057f1ce0f775018cbb540
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Thu Jul 8 10:57:10 2021 +0200

    mips: Fix non-POSIX regexp
    
    [ Upstream commit 28bbbb9875a35975904e46f9b06fa689d051b290 ]
    
    When cross compiling a MIPS kernel on a BSD based HOSTCC leads
    to errors like
    
      SYNC    include/config/auto.conf.cmd - due to: .config
    egrep: empty (sub)expression
      UPD     include/config/kernel.release
      HOSTCC  scripts/dtc/dtc.o - due to target missing
    
    It turns out that egrep uses this egrep pattern:
    
                    (|MINOR_|PATCHLEVEL_)
    
    This is not valid syntax or gives undefined results according
    to POSIX 9.5.3 ERE Grammar
    
            https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html
    
    It seems to be silently accepted by the Linux egrep implementation
    while a BSD host complains.
    
    Such patterns can be replaced by a transformation like
    
            "(|p1|p2)" -> "(p1|p2)?"
    
    Fixes: 48c35b2d245f ("[MIPS] There is no __GNUC_MAJOR__")
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 995abf774fadf2ed4bb823343c38827de9354a50
Author: Wang Hai <wanghai38@huawei.com>
Date:   Sat Jul 31 14:38:01 2021 +0800

    net: natsemi: Fix missing pci_disable_device() in probe and remove
    
    [ Upstream commit 7fe74dfd41c428afb24e2e615470832fa997ff14 ]
    
    Replace pci_enable_device() with pcim_enable_device(),
    pci_disable_device() and pci_release_regions() will be
    called in release automatically.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dd09c612e0b05f4516079957cd3a8de75f54199
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Jun 30 09:58:23 2021 +0200

    media: videobuf2-core: dequeue if start_streaming fails
    
    [ Upstream commit c592b46907adbeb81243f7eb7a468c36692658b8 ]
    
    If a vb2_queue sets q->min_buffers_needed then when the number of
    queued buffers reaches q->min_buffers_needed, vb2_core_qbuf() will call
    the start_streaming() callback. If start_streaming() returns an error,
    then that error was just returned by vb2_core_qbuf(), but the buffer
    was still queued. However, userspace expects that if VIDIOC_QBUF fails,
    the buffer is returned dequeued.
    
    So if start_streaming() fails, then remove the buffer from the queue,
    thus avoiding this unwanted side-effect.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Fixes: b3379c6201bb ("[media] vb2: only call start_streaming if sufficient buffers are queued")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1991e00436b7db31bc99640b26d0ee0e3ef2c235
Author: Li Manyi <limanyi@uniontech.com>
Date:   Mon Jul 26 19:49:13 2021 +0800

    scsi: sr: Return correct event when media event code is 3
    
    [ Upstream commit 5c04243a56a7977185b00400e59ca7e108004faf ]
    
    Media event code 3 is defined in the MMC-6 spec as follows:
    
      "MediaRemoval: The media has been removed from the specified slot, and
       the Drive is unable to access the media without user intervention. This
       applies to media changers only."
    
    This indicated that treating the condition as an EJECT_REQUEST was
    appropriate. However, doing so had the unfortunate side-effect of causing
    the drive tray to be physically ejected on resume. Instead treat the event
    as a MEDIA_CHANGE request.
    
    Fixes: 7dd753ca59d6 ("scsi: sr: Return appropriate error code when disk is ejected")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=213759
    Link: https://lore.kernel.org/r/20210726114913.6760-1-limanyi@uniontech.com
    Signed-off-by: Li Manyi <limanyi@uniontech.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fdbffde43c5c6a057c5f3b5f982306226f57f02
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 3 13:43:12 2021 +0200

    ALSA: seq: Fix racy deletion of subscriber
    
    commit 97367c97226aab8b298ada954ce12659ee3ad2a4 upstream.
    
    It turned out that the current implementation of the port subscription
    is racy.  The subscription contains two linked lists, and we have to
    add to or delete from both lists.  Since both connection and
    disconnection procedures perform the same order for those two lists
    (i.e. src list, then dest list), when a deletion happens during a
    connection procedure, the src list may be deleted before the dest list
    addition completes, and this may lead to a use-after-free or an Oops,
    even though the access to both lists are protected via mutex.
    
    The simple workaround for this race is to change the access order for
    the disconnection, namely, dest list, then src list.  This assures
    that the connection has been established when disconnecting, and also
    the concurrent deletion can be avoided.
    
    Reported-and-tested-by: folkert <folkert@vanheusden.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210801182754.GP890690@belle.intranet.vanheusden.com
    Link: https://lore.kernel.org/r/20210803114312.2536-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>