commit 4426e6017f73bbbd65270965ecc11b6b3ff4af4d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 27 13:50:51 2022 +0200

    Linux 5.4.191
    
    Link: https://lore.kernel.org/r/20220426081737.209637816@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c946909a3ed9a38806ae3e774427c021fa9eb01
Author: Marek Vasut <marex@denx.de>
Date:   Mon Apr 25 23:48:59 2022 +0200

    Revert "net: micrel: fix KS8851_MLL Kconfig"
    
    This reverts commit 4cd3c9e070d6a9a9dc76a5ffa79114953bf69087 which is
    commit c3efcedd272aa6dd5929e20cf902a52ddaa1197a upstream.
    
    The upstream commit c3efcedd272a ("net: micrel: fix KS8851_MLL Kconfig")
    depends on e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies")
    which is not part of Linux 5.4.y . Revert the aforementioned commit to
    prevent breakage in 5.4.y .
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c028b81d062ef29d2ee78564135f65cfc44d5c48
Author: Khazhismel Kumykov <khazhy@google.com>
Date:   Thu Apr 14 15:40:56 2022 -0700

    block/compat_ioctl: fix range check in BLKGETSIZE
    
    commit ccf16413e520164eb718cf8b22a30438da80ff23 upstream.
    
    kernel ulong and compat_ulong_t may not be same width. Use type directly
    to eliminate mismatches.
    
    This would result in truncation rather than EFBIG for 32bit mode for
    large disks.
    
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Link: https://lore.kernel.org/r/20220414224056.2875681-1-khazhy@google.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27da8d16e4f0a0ef37da356599eb36adec542643
Author: Lee Jones <lee.jones@linaro.org>
Date:   Mon Apr 25 16:51:54 2022 +0100

    staging: ion: Prevent incorrect reference counting behavour
    
    Supply additional check in order to prevent unexpected results.
    
    Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb158b152ea6823ac4ba8ae313d5336c2e846b46
Author: Tudor Ambarus <tudor.ambarus@microchip.com>
Date:   Wed Apr 6 16:36:03 2022 +0300

    spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controller
    
    commit 8c235cc25087495c4288d94f547e9d3061004991 upstream.
    
    Use the spi_mem_default_supports_op() core helper in order to take into
    account the buswidth specified by the user in device tree.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 0e6aae08e9ae ("spi: Add QuadSPI driver for Atmel SAMA5D2")
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Link: https://lore.kernel.org/r/20220406133604.455356-1-tudor.ambarus@microchip.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b6ad2421084375afeb5e833bba28196e62035c2
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Mar 17 22:21:37 2022 +0800

    jbd2: fix a potential race while discarding reserved buffers after an abort
    
    commit 23e3d7f7061f8682c751c46512718f47580ad8f0 upstream.
    
    we got issue as follows:
    [   72.796117] EXT4-fs error (device sda): ext4_journal_check_start:83: comm fallocate: Detected aborted journal
    [   72.826847] EXT4-fs (sda): Remounting filesystem read-only
    fallocate: fallocate failed: Read-only file system
    [   74.791830] jbd2_journal_commit_transaction: jh=0xffff9cfefe725d90 bh=0x0000000000000000 end delay
    [   74.793597] ------------[ cut here ]------------
    [   74.794203] kernel BUG at fs/jbd2/transaction.c:2063!
    [   74.794886] invalid opcode: 0000 [#1] PREEMPT SMP PTI
    [   74.795533] CPU: 4 PID: 2260 Comm: jbd2/sda-8 Not tainted 5.17.0-rc8-next-20220315-dirty #150
    [   74.798327] RIP: 0010:__jbd2_journal_unfile_buffer+0x3e/0x60
    [   74.801971] RSP: 0018:ffffa828c24a3cb8 EFLAGS: 00010202
    [   74.802694] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [   74.803601] RDX: 0000000000000001 RSI: ffff9cfefe725d90 RDI: ffff9cfefe725d90
    [   74.804554] RBP: ffff9cfefe725d90 R08: 0000000000000000 R09: ffffa828c24a3b20
    [   74.805471] R10: 0000000000000001 R11: 0000000000000001 R12: ffff9cfefe725d90
    [   74.806385] R13: ffff9cfefe725d98 R14: 0000000000000000 R15: ffff9cfe833a4d00
    [   74.807301] FS:  0000000000000000(0000) GS:ffff9d01afb00000(0000) knlGS:0000000000000000
    [   74.808338] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   74.809084] CR2: 00007f2b81bf4000 CR3: 0000000100056000 CR4: 00000000000006e0
    [   74.810047] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   74.810981] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   74.811897] Call Trace:
    [   74.812241]  <TASK>
    [   74.812566]  __jbd2_journal_refile_buffer+0x12f/0x180
    [   74.813246]  jbd2_journal_refile_buffer+0x4c/0xa0
    [   74.813869]  jbd2_journal_commit_transaction.cold+0xa1/0x148
    [   74.817550]  kjournald2+0xf8/0x3e0
    [   74.819056]  kthread+0x153/0x1c0
    [   74.819963]  ret_from_fork+0x22/0x30
    
    Above issue may happen as follows:
            write                   truncate                   kjournald2
    generic_perform_write
     ext4_write_begin
      ext4_walk_page_buffers
       do_journal_get_write_access ->add BJ_Reserved list
     ext4_journalled_write_end
      ext4_walk_page_buffers
       write_end_fn
        ext4_handle_dirty_metadata
                    ***************JBD2 ABORT**************
         jbd2_journal_dirty_metadata
     -> return -EROFS, jh in reserved_list
                                                       jbd2_journal_commit_transaction
                                                        while (commit_transaction->t_reserved_list)
                                                          jh = commit_transaction->t_reserved_list;
                            truncate_pagecache_range
                             do_invalidatepage
                              ext4_journalled_invalidatepage
                               jbd2_journal_invalidatepage
                                journal_unmap_buffer
                                 __dispose_buffer
                                  __jbd2_journal_unfile_buffer
                                   jbd2_journal_put_journal_head ->put last ref_count
                                    __journal_remove_journal_head
                                     bh->b_private = NULL;
                                     jh->b_bh = NULL;
                                                          jbd2_journal_refile_buffer(journal, jh);
                                                            bh = jh2bh(jh);
                                                            ->bh is NULL, later will trigger null-ptr-deref
                                     journal_free_journal_head(jh);
    
    After commit 96f1e0974575, we no longer hold the j_state_lock while
    iterating over the list of reserved handles in
    jbd2_journal_commit_transaction().  This potentially allows the
    journal_head to be freed by journal_unmap_buffer while the commit
    codepath is also trying to free the BJ_Reserved buffers.  Keeping
    j_state_lock held while trying extends hold time of the lock
    minimally, and solves this issue.
    
    Fixes: 96f1e0974575("jbd2: avoid long hold times of j_state_lock while committing a transaction")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220317142137.1821590-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b1ba14ab263016f447badbba4cf24e7011abadb
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Apr 14 21:57:49 2022 -0400

    ext4: force overhead calculation if the s_overhead_cluster makes no sense
    
    commit 85d825dbf4899a69407338bae462a59aa9a37326 upstream.
    
    If the file system does not use bigalloc, calculating the overhead is
    cheap, so force the recalculation of the overhead so we don't have to
    trust the precalculated overhead in the superblock.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 425301ef608a70c4cd62783326d1798ff72ed2d3
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Apr 14 21:31:27 2022 -0400

    ext4: fix overhead calculation to account for the reserved gdt blocks
    
    commit 10b01ee92df52c8d7200afead4d5e5f55a5c58b1 upstream.
    
    The kernel calculation was underestimating the overhead by not taking
    into account the reserved gdt blocks.  With this change, the overhead
    calculated by the kernel matches the overhead calculation in mke2fs.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea9c206111ead76d3d82e427888b1fe1a8543a15
Author: wangjianjian (C) <wangjianjian3@huawei.com>
Date:   Fri Apr 1 20:07:35 2022 +0800

    ext4, doc: fix incorrect h_reserved size
    
    commit 7102ffe4c166ca0f5e35137e9f9de83768c2d27d upstream.
    
    According to document and code, ext4_xattr_header's size is 32 bytes, so
    h_reserved size should be 3.
    
    Signed-off-by: Wang Jianjian <wangjianjian3@huawei.com>
    Link: https://lore.kernel.org/r/92fcc3a6-7d77-8c09-4126-377fcb4c46a5@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 259dc49deaa2c5d35841f8ea95d7c86859f629a1
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Thu Mar 31 13:05:15 2022 -0700

    ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
    
    commit 2da376228a2427501feb9d15815a45dbdbdd753e upstream.
    
    Syzbot found an issue [1] in ext4_fallocate().
    The C reproducer [2] calls fallocate(), passing size 0xffeffeff000ul,
    and offset 0x1000000ul, which, when added together exceed the
    bitmap_maxbytes for the inode. This triggers a BUG in
    ext4_ind_remove_space(). According to the comments in this function
    the 'end' parameter needs to be one block after the last block to be
    removed. In the case when the BUG is triggered it points to the last
    block. Modify the ext4_punch_hole() function and add constraint that
    caps the length to satisfy the one before laster block requirement.
    
    LINK: [1] https://syzkaller.appspot.com/bug?id=b80bd9cf348aac724a4f4dff251800106d721331
    LINK: [2] https://syzkaller.appspot.com/text?tag=ReproC&x=14ba0238700000
    
    Fixes: a4bb6b64e39a ("ext4: enable "punch hole" functionality")
    Reported-by: syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Link: https://lore.kernel.org/r/20220331200515.153214-1-tadeusz.struk@linaro.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit faadbf7ac4f2a3b98b0d939b808fa3176f07a9d4
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Mar 24 14:48:16 2022 +0800

    ext4: fix use-after-free in ext4_search_dir
    
    commit c186f0887fe7061a35cebef024550ec33ef8fbd8 upstream.
    
    We got issue as follows:
    EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue
    ==================================================================
    BUG: KASAN: use-after-free in ext4_search_dir fs/ext4/namei.c:1394 [inline]
    BUG: KASAN: use-after-free in search_dirblock fs/ext4/namei.c:1199 [inline]
    BUG: KASAN: use-after-free in __ext4_find_entry+0xdca/0x1210 fs/ext4/namei.c:1553
    Read of size 1 at addr ffff8881317c3005 by task syz-executor117/2331
    
    CPU: 1 PID: 2331 Comm: syz-executor117 Not tainted 5.10.0+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:83 [inline]
     dump_stack+0x144/0x187 lib/dump_stack.c:124
     print_address_description+0x7d/0x630 mm/kasan/report.c:387
     __kasan_report+0x132/0x190 mm/kasan/report.c:547
     kasan_report+0x47/0x60 mm/kasan/report.c:564
     ext4_search_dir fs/ext4/namei.c:1394 [inline]
     search_dirblock fs/ext4/namei.c:1199 [inline]
     __ext4_find_entry+0xdca/0x1210 fs/ext4/namei.c:1553
     ext4_lookup_entry fs/ext4/namei.c:1622 [inline]
     ext4_lookup+0xb8/0x3a0 fs/ext4/namei.c:1690
     __lookup_hash+0xc5/0x190 fs/namei.c:1451
     do_rmdir+0x19e/0x310 fs/namei.c:3760
     do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x445e59
    Code: 4d c7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 1b c7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007fff2277fac8 EFLAGS: 00000246 ORIG_RAX: 0000000000000054
    RAX: ffffffffffffffda RBX: 0000000000400280 RCX: 0000000000445e59
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000002
    R10: 00007fff2277f990 R11: 0000000000000246 R12: 0000000000000000
    R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000
    
    The buggy address belongs to the page:
    page:0000000048cd3304 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1317c3
    flags: 0x200000000000000()
    raw: 0200000000000000 ffffea0004526588 ffffea0004528088 0000000000000000
    raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8881317c2f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff8881317c2f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff8881317c3000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                       ^
     ffff8881317c3080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ffff8881317c3100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ==================================================================
    
    ext4_search_dir:
      ...
      de = (struct ext4_dir_entry_2 *)search_buf;
      dlimit = search_buf + buf_size;
      while ((char *) de < dlimit) {
      ...
        if ((char *) de + de->name_len <= dlimit &&
             ext4_match(dir, fname, de)) {
                ...
        }
      ...
        de_len = ext4_rec_len_from_disk(de->rec_len, dir->i_sb->s_blocksize);
        if (de_len <= 0)
          return -1;
        offset += de_len;
        de = (struct ext4_dir_entry_2 *) ((char *) de + de_len);
      }
    
    Assume:
    de=0xffff8881317c2fff
    dlimit=0x0xffff8881317c3000
    
    If read 'de->name_len' which address is 0xffff8881317c3005, obviously is
    out of range, then will trigger use-after-free.
    To solve this issue, 'dlimit' must reserve 8 bytes, as we will read
    'de->name_len' to judge if '(char *) de + de->name_len' out of range.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220324064816.1209985-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0309665eb244f5993b03844739047920c3ab3d9f
Author: Ye Bin <yebin10@huawei.com>
Date:   Mon Mar 21 22:44:38 2022 +0800

    ext4: fix symlink file size not match to file content
    
    commit a2b0b205d125f27cddfb4f7280e39affdaf46686 upstream.
    
    We got issue as follows:
    [home]# fsck.ext4  -fn  ram0yb
    e2fsck 1.45.6 (20-Mar-2020)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Symlink /p3/d14/d1a/l3d (inode #3494) is invalid.
    Clear? no
    Entry 'l3d' in /p3/d14/d1a (3383) has an incorrect filetype (was 7, should be 0).
    Fix? no
    
    As the symlink file size does not match the file content. If the writeback
    of the symlink data block failed, ext4_finish_bio() handles the end of IO.
    However this function fails to mark the buffer with BH_write_io_error and
    so when unmount does journal checkpoint it cannot detect the writeback
    error and will cleanup the journal. Thus we've lost the correct data in the
    journal area. To solve this issue, mark the buffer as BH_write_io_error in
    ext4_finish_bio().
    
    Cc: stable@kernel.org
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220321144438.201685-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddfe3babc5460780780845076dfb12a622250700
Author: Rob Herring <robh@kernel.org>
Date:   Fri Apr 8 15:33:30 2022 -0500

    arm_pmu: Validate single/group leader events
    
    commit e5c23779f93d45e39a52758ca593bd7e62e9b4be upstream.
    
    In the case where there is only a cycle counter available (i.e.
    PMCR_EL0.N is 0) and an event other than CPU cycles is opened, the open
    should fail as the event can never possibly be scheduled. However, the
    event validation when an event is opened is skipped when the group
    leader is opened. Fix this by always validating the group leader events.
    
    Reported-by: Al Grant <al.grant@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20220408203330.4014015-1-robh@kernel.org
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 852b02d1f8088cc76fa4c684e52799d4a120cf9e
Author: Sergey Matyukevich <sergey.matyukevich@synopsys.com>
Date:   Thu Apr 14 11:17:22 2022 +0300

    ARC: entry: fix syscall_trace_exit argument
    
    commit b1c6ecfdd06907554518ec384ce8e99889d15193 upstream.
    
    Function syscall_trace_exit expects pointer to pt_regs. However
    r0 is also used to keep syscall return value. Restore pointer
    to pt_regs before calling syscall_trace_exit.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sergey Matyukevich <sergey.matyukevich@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016ba7cbed571f5d8059e7096f0fa0b999338229
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Tue Apr 5 18:56:01 2022 +0300

    e1000e: Fix possible overflow in LTR decoding
    
    commit 04ebaa1cfddae5f240cc7404f009133bb0389a47 upstream.
    
    When we decode the latency and the max_latency, u16 value may not fit
    the required size and could lead to the wrong LTR representation.
    
    Scaling is represented as:
    scale 0 - 1         (2^(5*0)) = 2^0
    scale 1 - 32        (2^(5 *1))= 2^5
    scale 2 - 1024      (2^(5 *2)) =2^10
    scale 3 - 32768     (2^(5 *3)) =2^15
    scale 4 - 1048576   (2^(5 *4)) = 2^20
    scale 5 - 33554432  (2^(5 *4)) = 2^25
    scale 4 and scale 5 required 20 and 25 bits respectively.
    scale 6 reserved.
    
    Replace the u16 type with the u32 type and allow corrected LTR
    representation.
    
    Cc: stable@vger.kernel.org
    Fixes: 44a13a5d99c7 ("e1000e: Fix the max snoop/no-snoop latency for 10M")
    Reported-by: James Hutchinson <jahutchinson99@googlemail.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215689
    Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Tested-by: James Hutchinson <jahutchinson99@googlemail.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1217cf141b24934fc3837f6cba6fd0726c7a1506
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Tue Mar 29 09:21:34 2022 +0800

    ASoC: soc-dapm: fix two incorrect uses of list iterator
    
    commit f730a46b931d894816af34a0ff8e4ad51565b39f upstream.
    
    These two bug are here:
            list_for_each_entry_safe_continue(w, n, list,
                                            power_list);
            list_for_each_entry_safe_continue(w, n, list,
                                            power_list);
    
    After the list_for_each_entry_safe_continue() exits, the list iterator
    will always be a bogus pointer which point to an invalid struct objdect
    containing HEAD member. The funciton poniter 'w->event' will be a
    invalid value which can lead to a control-flow hijack if the 'w' can be
    controlled.
    
    The original intention was to continue the outer list_for_each_entry_safe()
    loop with the same entry if w->event is NULL, but misunderstanding the
    meaning of list_for_each_entry_safe_continue().
    
    So just add a 'continue;' to fix the bug.
    
    Cc: stable@vger.kernel.org
    Fixes: 163cac061c973 ("ASoC: Factor out DAPM sequence execution")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Link: https://lore.kernel.org/r/20220329012134.9375-1-xiam0nd.tong@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa70705560871725e963945a2d36ace7849c004e
Author: Paolo Valerio <pvalerio@redhat.com>
Date:   Fri Apr 15 10:08:41 2022 +0200

    openvswitch: fix OOB access in reserve_sfa_size()
    
    commit cefa91b2332d7009bc0be5d951d6cbbf349f90f8 upstream.
    
    Given a sufficiently large number of actions, while copying and
    reserving memory for a new action of a new flow, if next_offset is
    greater than MAX_ACTIONS_BUFSIZE, the function reserve_sfa_size() does
    not return -EMSGSIZE as expected, but it allocates MAX_ACTIONS_BUFSIZE
    bytes increasing actions_len by req_size. This can then lead to an OOB
    write access, especially when further actions need to be copied.
    
    Fix it by rearranging the flow action size check.
    
    KASAN splat below:
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in reserve_sfa_size+0x1ba/0x380 [openvswitch]
    Write of size 65360 at addr ffff888147e4001c by task handler15/836
    
    CPU: 1 PID: 836 Comm: handler15 Not tainted 5.18.0-rc1+ #27
    ...
    Call Trace:
     <TASK>
     dump_stack_lvl+0x45/0x5a
     print_report.cold+0x5e/0x5db
     ? __lock_text_start+0x8/0x8
     ? reserve_sfa_size+0x1ba/0x380 [openvswitch]
     kasan_report+0xb5/0x130
     ? reserve_sfa_size+0x1ba/0x380 [openvswitch]
     kasan_check_range+0xf5/0x1d0
     memcpy+0x39/0x60
     reserve_sfa_size+0x1ba/0x380 [openvswitch]
     __add_action+0x24/0x120 [openvswitch]
     ovs_nla_add_action+0xe/0x20 [openvswitch]
     ovs_ct_copy_action+0x29d/0x1130 [openvswitch]
     ? __kernel_text_address+0xe/0x30
     ? unwind_get_return_address+0x56/0xa0
     ? create_prof_cpu_mask+0x20/0x20
     ? ovs_ct_verify+0xf0/0xf0 [openvswitch]
     ? prep_compound_page+0x198/0x2a0
     ? __kasan_check_byte+0x10/0x40
     ? kasan_unpoison+0x40/0x70
     ? ksize+0x44/0x60
     ? reserve_sfa_size+0x75/0x380 [openvswitch]
     __ovs_nla_copy_actions+0xc26/0x2070 [openvswitch]
     ? __zone_watermark_ok+0x420/0x420
     ? validate_set.constprop.0+0xc90/0xc90 [openvswitch]
     ? __alloc_pages+0x1a9/0x3e0
     ? __alloc_pages_slowpath.constprop.0+0x1da0/0x1da0
     ? unwind_next_frame+0x991/0x1e40
     ? __mod_node_page_state+0x99/0x120
     ? __mod_lruvec_page_state+0x2e3/0x470
     ? __kasan_kmalloc_large+0x90/0xe0
     ovs_nla_copy_actions+0x1b4/0x2c0 [openvswitch]
     ovs_flow_cmd_new+0x3cd/0xb10 [openvswitch]
     ...
    
    Cc: stable@vger.kernel.org
    Fixes: f28cd2af22a0 ("openvswitch: fix flow actions reallocation")
    Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
    Acked-by: Eelco Chaudron <echaudro@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d24e0d9d691b124a2830beb0b738cdc2fe7d14cc
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Wed Apr 13 22:44:36 2022 -0700

    xtensa: fix a7 clobbering in coprocessor context load/store
    
    commit 839769c35477d4acc2369e45000ca7b0b6af39a7 upstream.
    
    Fast coprocessor exception handler saves a3..a6, but coprocessor context
    load/store code uses a4..a7 as temporaries, potentially clobbering a7.
    'Potentially' because coprocessor state load/store macros may not use
    all four temporary registers (and neither FPU nor HiFi macros do).
    Use a3..a6 as intended.
    
    Cc: stable@vger.kernel.org
    Fixes: c658eac628aa ("[XTENSA] Add support for configurable registers and coprocessors")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c26a96d0c29d3b9bd1a8b30d23082495e53411a
Author: Guo Ren <guoren@kernel.org>
Date:   Thu Apr 7 15:33:22 2022 +0800

    xtensa: patch_text: Fixup last cpu should be master
    
    commit ee69d4be8fd064cd08270b4808d2dfece3614ee0 upstream.
    
    These patch_text implementations are using stop_machine_cpuslocked
    infrastructure with atomic cpu_count. The original idea: When the
    master CPU patch_text, the others should wait for it. But current
    implementation is using the first CPU as master, which couldn't
    guarantee the remaining CPUs are waiting. This patch changes the
    last CPU as the master to solve the potential risk.
    
    Fixes: 64711f9a47d4 ("xtensa: implement jump_label support")
    Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
    Signed-off-by: Guo Ren <guoren@kernel.org>
    Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: <stable@vger.kernel.org>
    Message-Id: <20220407073323.743224-4-guoren@kernel.org>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d6937c1e0935621989dd52dd62f4368804bea73
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Tue Apr 19 17:18:27 2022 +0530

    powerpc/perf: Fix power9 event alternatives
    
    [ Upstream commit 0dcad700bb2776e3886fe0a645a4bf13b1e747cd ]
    
    When scheduling a group of events, there are constraint checks done to
    make sure all events can go in a group. Example, one of the criteria is
    that events in a group cannot use the same PMC. But platform specific
    PMU supports alternative event for some of the event codes. During
    perf_event_open(), if any event group doesn't match constraint check
    criteria, further lookup is done to find alternative event.
    
    By current design, the array of alternatives events in PMU code is
    expected to be sorted by column 0. This is because in
    find_alternative() the return criteria is based on event code
    comparison. ie. "event < ev_alt[i][0])". This optimisation is there
    since find_alternative() can be called multiple times. In power9 PMU
    code, the alternative event array is not sorted properly and hence there
    is breakage in finding alternative events.
    
    To work with existing logic, fix the alternative event array to be
    sorted by column 0 for power9-pmu.c
    
    Results:
    
    With alternative events, multiplexing can be avoided. That is, for
    example, in power9 PM_LD_MISS_L1 (0x3e054) has alternative event,
    PM_LD_MISS_L1_ALT (0x400f0). This is an identical event which can be
    programmed in a different PMC.
    
    Before:
    
     # perf stat -e r3e054,r300fc
    
     Performance counter stats for 'system wide':
    
               1057860      r3e054              (50.21%)
                   379      r300fc              (49.79%)
    
           0.944329741 seconds time elapsed
    
    Since both the events are using PMC3 in this case, they are
    multiplexed here.
    
    After:
    
     # perf stat -e r3e054,r300fc
    
     Performance counter stats for 'system wide':
    
               1006948      r3e054
                   182      r300fc
    
    Fixes: 91e0bd1e6251 ("powerpc/perf: Add PM_LD_MISS_L1 and PM_BR_2PATH to power9 event list")
    Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220419114828.89843-1-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dafb826ed704333f48110062325aa60b6b3655c
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Apr 20 21:50:07 2022 +0800

    drm/vc4: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage
    
    [ Upstream commit 3d0b93d92a2790337aa9d18cb332d02356a24126 ]
    
    If the device is already in a runtime PM enabled state
    pm_runtime_get_sync() will return 1.
    
    Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
    fails, so use pm_runtime_resume_and_get() instead. this function
    will handle this.
    
    Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220420135008.2757-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 013231f75fce10408198cf62fe620aa5cf74f2f9
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Wed Apr 20 15:08:40 2022 +1000

    KVM: PPC: Fix TCE handling for VFIO
    
    [ Upstream commit 26a62b750a4e6364b0393562f66759b1494c3a01 ]
    
    The LoPAPR spec defines a guest visible IOMMU with a variable page size.
    Currently QEMU advertises 4K, 64K, 2M, 16MB pages, a Linux VM picks
    the biggest (16MB). In the case of a passed though PCI device, there is
    a hardware IOMMU which does not support all pages sizes from the above -
    P8 cannot do 2MB and P9 cannot do 16MB. So for each emulated
    16M IOMMU page we may create several smaller mappings ("TCEs") in
    the hardware IOMMU.
    
    The code wrongly uses the emulated TCE index instead of hardware TCE
    index in error handling. The problem is easier to see on POWER8 with
    multi-level TCE tables (when only the first level is preallocated)
    as hash mode uses real mode TCE hypercalls handlers.
    The kernel starts using indirect tables when VMs get bigger than 128GB
    (depends on the max page order).
    The very first real mode hcall is going to fail with H_TOO_HARD as
    in the real mode we cannot allocate memory for TCEs (we can in the virtual
    mode) but on the way out the code attempts to clear hardware TCEs using
    emulated TCE indexes which corrupts random kernel memory because
    it_offset==1<<59 is subtracted from those indexes and the resulting index
    is out of the TCE table bounds.
    
    This fixes kvmppc_clear_tce() to use the correct TCE indexes.
    
    While at it, this fixes TCE cache invalidation which uses emulated TCE
    indexes instead of the hardware ones. This went unnoticed as 64bit DMA
    is used these days and VMs map all RAM in one go and only then do DMA
    and this is when the TCE cache gets populated.
    
    Potentially this could slow down mapping, however normally 16MB
    emulated pages are backed by 64K hardware pages so it is one write to
    the "TCE Kill" per 256 updates which is not that bad considering the size
    of the cache (1024 TCEs or so).
    
    Fixes: ca1fc489cfa0 ("KVM: PPC: Book3S: Allow backing bigger guest IOMMU pages with smaller physical pages")
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Tested-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220420050840.328223-1-aik@ozlabs.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9cf05812cb10a890b317691fd5bb182be32e10b0
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Apr 15 18:25:13 2022 +0200

    drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare
    
    [ Upstream commit 5f18c0782b99e26121efa93d20b76c19e17aa1dd ]
    
    The panel has a prepare call which is before video starts, and an
    enable call which is after.
    The Toshiba bridge should be configured before video, so move
    the relevant power and initialisation calls to prepare.
    
    Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220415162513.42190-3-stefan.wahren@i2se.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f08e85ca0fc75f977114ae75e9bfdaf9be55f48
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Apr 15 18:25:12 2022 +0200

    drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised
    
    [ Upstream commit f92055ae0acb035891e988ce345d6b81a0316423 ]
    
    If a call to rpi_touchscreen_i2c_write from rpi_touchscreen_probe
    fails before mipi_dsi_device_register_full is called, then
    in trying to log the error message if uses ts->dsi->dev when
    it is still NULL.
    
    Use ts->i2c->dev instead, which is initialised earlier in probe.
    
    Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.")
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220415162513.42190-2-stefan.wahren@i2se.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23f0ba5585a5c7e67dd08345c4920716da91f53e
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Sun Mar 27 14:11:54 2022 +0800

    dma: at_xdmac: fix a missing check on list iterator
    
    commit 206680c4e46b62fd8909385e0874a36952595b85 upstream.
    
    The bug is here:
            __func__, desc, &desc->tx_dma_desc.phys, ret, cookie, residue);
    
    The list iterator 'desc' will point to a bogus position containing
    HEAD if the list is empty or no element is found. To avoid dev_dbg()
    prints a invalid address, use a new variable 'iter' as the list
    iterator, while use the origin variable 'desc' as a dedicated
    pointer to point to the found element.
    
    Cc: stable@vger.kernel.org
    Fixes: 82e2424635f4c ("dmaengine: xdmac: fix print warning on dma_addr_t variable")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Link: https://lore.kernel.org/r/20220327061154.4867-1-xiam0nd.tong@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a22f3c99268c2ddabe83675412fffb528f00ea9f
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Thu Apr 21 09:39:20 2022 +0800

    ata: pata_marvell: Check the 'bmdma_addr' beforing reading
    
    commit aafa9f958342db36c17ac2a7f1b841032c96feb4 upstream.
    
    Before detecting the cable type on the dma bar, the driver should check
    whether the 'bmdma_addr' is zero, which means the adapter does not
    support DMA, otherwise we will get the following error:
    
    [    5.146634] Bad IO access at port 0x1 (return inb(port))
    [    5.147206] WARNING: CPU: 2 PID: 303 at lib/iomap.c:44 ioread8+0x4a/0x60
    [    5.150856] RIP: 0010:ioread8+0x4a/0x60
    [    5.160238] Call Trace:
    [    5.160470]  <TASK>
    [    5.160674]  marvell_cable_detect+0x6e/0xc0 [pata_marvell]
    [    5.161728]  ata_eh_recover+0x3520/0x6cc0
    [    5.168075]  ata_do_eh+0x49/0x3c0
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0441d3e95bca9157e0e0acfe626a2b3b05b50a43
Author: Nico Pache <npache@redhat.com>
Date:   Thu Apr 21 16:36:01 2022 -0700

    oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup
    
    commit e4a38402c36e42df28eb1a5394be87e6571fb48a upstream.
    
    The pthread struct is allocated on PRIVATE|ANONYMOUS memory [1] which
    can be targeted by the oom reaper.  This mapping is used to store the
    futex robust list head; the kernel does not keep a copy of the robust
    list and instead references a userspace address to maintain the
    robustness during a process death.
    
    A race can occur between exit_mm and the oom reaper that allows the oom
    reaper to free the memory of the futex robust list before the exit path
    has handled the futex death:
    
        CPU1                               CPU2
        --------------------------------------------------------------------
        page_fault
        do_exit "signal"
        wake_oom_reaper
                                            oom_reaper
                                            oom_reap_task_mm (invalidates mm)
        exit_mm
        exit_mm_release
        futex_exit_release
        futex_cleanup
        exit_robust_list
        get_user (EFAULT- can't access memory)
    
    If the get_user EFAULT's, the kernel will be unable to recover the
    waiters on the robust_list, leaving userspace mutexes hung indefinitely.
    
    Delay the OOM reaper, allowing more time for the exit path to perform
    the futex cleanup.
    
    Reproducer: https://gitlab.com/jsavitz/oom_futex_reproducer
    
    Based on a patch by Michal Hocko.
    
    Link: https://elixir.bootlin.com/glibc/glibc-2.35/source/nptl/allocatestack.c#L370 [1]
    Link: https://lkml.kernel.org/r/20220414144042.677008-1-npache@redhat.com
    Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
    Signed-off-by: Joel Savitz <jsavitz@redhat.com>
    Signed-off-by: Nico Pache <npache@redhat.com>
    Co-developed-by: Joel Savitz <jsavitz@redhat.com>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Rafael Aquini <aquini@redhat.com>
    Cc: Waiman Long <longman@redhat.com>
    Cc: Herton R. Krzesinski <herton@redhat.com>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ben Segall <bsegall@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Joel Savitz <jsavitz@redhat.com>
    Cc: Darren Hart <dvhart@infradead.org>
    Cc: <stable@vger.kernel.org>
    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 530d32ac52f7291a77de5495a8498d5746573247
Author: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Date:   Thu Apr 14 15:58:13 2022 +0530

    EDAC/synopsys: Read the error count from the correct register
    
    commit e2932d1f6f055b2af2114c7e64a26dc1b5593d0c upstream.
    
    Currently, the error count is read wrongly from the status register. Read
    the count from the proper error count register (ERRCNT).
    
      [ bp: Massage. ]
    
    Fixes: b500b4a029d5 ("EDAC, synopsys: Add ECC support for ZynqMP DDR controller")
    Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Michal Simek <michal.simek@xilinx.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220414102813.4468-1-shubhrajyoti.datta@xilinx.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91367af460dadab52ca009529191267af88ab9eb
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Apr 12 05:41:00 2022 -0400

    stat: fix inconsistency between struct stat and struct compat_stat
    
    [ Upstream commit 932aba1e169090357a77af18850a10c256b50819 ]
    
    struct stat (defined in arch/x86/include/uapi/asm/stat.h) has 32-bit
    st_dev and st_rdev; struct compat_stat (defined in
    arch/x86/include/asm/compat.h) has 16-bit st_dev and st_rdev followed by
    a 16-bit padding.
    
    This patch fixes struct compat_stat to match struct stat.
    
    [ Historical note: the old x86 'struct stat' did have that 16-bit field
      that the compat layer had kept around, but it was changes back in 2003
      by "struct stat - support larger dev_t":
    
        https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=e95b2065677fe32512a597a79db94b77b90c968d
    
      and back in those days, the x86_64 port was still new, and separate
      from the i386 code, and had already picked up the old version with a
      16-bit st_dev field ]
    
    Note that we can't change compat_dev_t because it is used by
    compat_loop_info.
    
    Also, if the st_dev and st_rdev values are 32-bit, we don't have to use
    old_valid_dev to test if the value fits into them.  This fixes
    -EOVERFLOW on filesystems that are on NVMe because NVMe uses the major
    number 259.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: Andreas Schwab <schwab@linux-m68k.org>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 837e319ebe62caaf6e65a63f95c01a9b74481c2c
Author: Mike Christie <michael.christie@oracle.com>
Date:   Thu Apr 7 19:13:13 2022 -0500

    scsi: qedi: Fix failed disconnect handling
    
    [ Upstream commit 857b06527f707f5df634b854898a191b5c1d0272 ]
    
    We set the qedi_ep state to EP_STATE_OFLDCONN_START when the ep is
    created. Then in qedi_set_path we kick off the offload work. If userspace
    times out the connection and calls ep_disconnect, qedi will only flush the
    offload work if the qedi_ep state has transitioned away from
    EP_STATE_OFLDCONN_START. If we can't connect we will not have transitioned
    state and will leave the offload work running, and we will free the qedi_ep
    from under it.
    
    This patch just has us init the work when we create the ep, then always
    flush it.
    
    Link: https://lore.kernel.org/r/20220408001314.5014-10-michael.christie@oracle.com
    Tested-by: Manish Rangankar <mrangankar@marvell.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Reviewed-by: Chris Leech <cleech@redhat.com>
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b813ce289edb75f9d657aeba7f7f3c8ac7ed7fb
Author: Tomas Melin <tomas.melin@vaisala.com>
Date:   Thu Apr 7 19:16:59 2022 +0300

    net: macb: Restart tx only if queue pointer is lagging
    
    [ Upstream commit 5ad7f18cd82cee8e773d40cc7a1465a526f2615c ]
    
    commit 4298388574da ("net: macb: restart tx after tx used bit read")
    added support for restarting transmission. Restarting tx does not work
    in case controller asserts TXUBR interrupt and TQBP is already at the end
    of the tx queue. In that situation, restarting tx will immediately cause
    assertion of another TXUBR interrupt. The driver will end up in an infinite
    interrupt loop which it cannot break out of.
    
    For cases where TQBP is at the end of the tx queue, instead
    only clear TX_USED interrupt. As more data gets pushed to the queue,
    transmission will resume.
    
    This issue was observed on a Xilinx Zynq-7000 based board.
    During stress test of the network interface,
    driver would get stuck on interrupt loop within seconds or minutes
    causing CPU to stall.
    
    Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
    Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20220407161659.14532-1-tomas.melin@vaisala.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1419bee4dde3c8502a349f71666844ccf192606
Author: Xiaoke Wang <xkernel.wang@foxmail.com>
Date:   Thu Apr 7 10:31:51 2022 +0800

    drm/msm/mdp5: check the return of kzalloc()
    
    [ Upstream commit 047ae665577776b7feb11bd4f81f46627cff95e7 ]
    
    kzalloc() is a memory allocation function which can return NULL when
    some internal memory errors happen. So it is better to check it to
    prevent potential wrong memory access.
    
    Besides, since mdp5_plane_reset() is void type, so we should better
    set `plane-state` to NULL after releasing it.
    
    Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/481055/
    Link: https://lore.kernel.org/r/tencent_8E2A1C78140EE1784AB2FF4B2088CC0AB908@qq.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80b188da30aaec5797a17971d05437215d609de6
Author: Lv Ruyi <lv.ruyi@zte.com.cn>
Date:   Fri Apr 8 09:49:41 2022 +0000

    dpaa_eth: Fix missing of_node_put in dpaa_get_ts_info()
    
    [ Upstream commit 1a7eb80d170c28be2928433702256fe2a0bd1e0f ]
    
    Both of of_get_parent() and of_parse_phandle() return node pointer with
    refcount incremented, use of_node_put() on it to decrease refcount
    when done.
    
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46f9fa0a663248060dae26faed7536024544a769
Author: Borislav Petkov <bp@alien8.de>
Date:   Tue Apr 5 18:55:37 2022 +0200

    brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant
    
    [ Upstream commit 6fb3a5868b2117611f41e421e10e6a8c2a13039a ]
    
    Fix:
    
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: In function ‘brcmf_sdio_drivestrengthinit’:
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:3798:2: error: case label does not reduce to an integer constant
        case SDIOD_DRVSTR_KEY(BRCM_CC_43143_CHIP_ID, 17):
        ^~~~
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:3809:2: error: case label does not reduce to an integer constant
        case SDIOD_DRVSTR_KEY(BRCM_CC_43362_CHIP_ID, 13):
        ^~~~
    
    See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory
    details as to why it triggers with older gccs only.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Arend van Spriel <aspriel@gmail.com>
    Cc: Franky Lin <franky.lin@broadcom.com>
    Cc: Hante Meuleman <hante.meuleman@broadcom.com>
    Cc: Kalle Valo <kvalo@kernel.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: brcm80211-dev-list.pdl@broadcom.com
    Cc: netdev@vger.kernel.org
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/Ykx0iRlvtBnKqtbG@zn.tnic
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 12a753edd96349b615995b1331d3de76c4571343
Author: Borislav Petkov <bp@suse.de>
Date:   Tue Apr 5 17:15:14 2022 +0200

    mt76: Fix undefined behavior due to shift overflowing the constant
    
    [ Upstream commit dbc2b1764734857d68425468ffa8486e97ab89df ]
    
    Fix:
    
      drivers/net/wireless/mediatek/mt76/mt76x2/pci.c: In function ‘mt76x2e_probe’:
      ././include/linux/compiler_types.h:352:38: error: call to ‘__compiletime_assert_946’ \
            declared with attribute error: FIELD_PREP: mask is not constant
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
    
    See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory
    details as to why it triggers with older gccs only.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Felix Fietkau <nbd@nbd.name>
    Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
    Cc: Ryder Lee <ryder.lee@mediatek.com>
    Cc: Shayne Chen <shayne.chen@mediatek.com>
    Cc: Sean Wang <sean.wang@mediatek.com>
    Cc: Kalle Valo <kvalo@kernel.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: linux-wireless@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20220405151517.29753-9-bp@alien8.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c48a6e62ddb40ece4fa92c2b33a6d7671cac30b
Author: David Howells <dhowells@redhat.com>
Date:   Thu Apr 7 00:03:14 2022 +0100

    cifs: Check the IOCB_DIRECT flag, not O_DIRECT
    
    [ Upstream commit 994fd530a512597ffcd713b0f6d5bc916c5698f0 ]
    
    Use the IOCB_DIRECT indicator flag on the I/O context rather than checking to
    see if the file was opened O_DIRECT.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Steve French <sfrench@samba.org>
    cc: Shyam Prasad N <nspmangalore@gmail.com>
    cc: Rohith Surabattula <rohiths.msft@gmail.com>
    cc: linux-cifs@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 435142fbdcc0c05134999a0f8e61aa3cbd061067
Author: Hongbin Wang <wh_bin@126.com>
Date:   Wed Apr 6 22:46:22 2022 -0400

    vxlan: fix error return code in vxlan_fdb_append
    
    [ Upstream commit 7cea5560bf656b84f9ed01c0cc829d4eecd0640b ]
    
    When kmalloc and dst_cache_init failed,
    should return ENOMEM rather than ENOBUFS.
    
    Signed-off-by: Hongbin Wang <wh_bin@126.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99c2d9a52f378f2063a507ab79aa41cd0dfe4730
Author: Borislav Petkov <bp@suse.de>
Date:   Tue Apr 5 17:15:08 2022 +0200

    ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant
    
    [ Upstream commit 1ef8715975de8bd481abbd0839ed4f49d9e5b0ff ]
    
    Fix:
    
      sound/usb/midi.c: In function ‘snd_usbmidi_out_endpoint_create’:
      sound/usb/midi.c:1389:2: error: case label does not reduce to an integer constant
        case USB_ID(0xfc08, 0x0101): /* Unknown vendor Cable */
        ^~~~
    
    See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory
    details as to why it triggers with older gccs only.
    
    [ A slight correction with parentheses around the argument by tiwai ]
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lore.kernel.org/r/20220405151517.29753-3-bp@alien8.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e28d157e5f22c585e95f79a73c4adab33feaebb
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Tue Mar 22 14:18:30 2022 +0800

    platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative
    
    [ Upstream commit 0284d4d1be753f648f28b77bdfbe6a959212af5c ]
    
    Eliminate the follow smatch warnings:
    
    drivers/platform/x86/samsung-laptop.c:1124 kbd_led_set() warn: unsigned
    'value' is never less than zero.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220322061830.105579-1-jiapeng.chong@linux.alibaba.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54be94d33660ab117adacd17b1b1e7083389414c
Author: Sameer Pujar <spujar@nvidia.com>
Date:   Wed Jan 12 19:26:46 2022 +0530

    reset: tegra-bpmp: Restore Handle errors in BPMP response
    
    [ Upstream commit d1da1052ffad63aa5181b69f20a6952e31f339c2 ]
    
    This reverts following commit 69125b4b9440 ("reset: tegra-bpmp: Revert
    Handle errors in BPMP response").
    
    The Tegra194 HDA reset failure is fixed by commit d278dc9151a0 ("ALSA:
    hda/tegra: Fix Tegra194 HDA reset failure"). The temporary revert of
    original commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
    response") can be removed now.
    
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Link: https://lore.kernel.org/r/1641995806-15245-1-git-send-email-spujar@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cb2c00dd1ab2c5cd5d076ae7d7aeb9083fb3dc6
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Mar 31 12:04:43 2022 -0700

    ARM: vexpress/spc: Avoid negative array index when !SMP
    
    [ Upstream commit b3f1dd52c991d79118f35e6d1bf4d7cb09882e38 ]
    
    When building multi_v7_defconfig+CONFIG_SMP=n, -Warray-bounds exposes
    a couple negative array index accesses:
    
    arch/arm/mach-vexpress/spc.c: In function 've_spc_clk_init':
    arch/arm/mach-vexpress/spc.c:583:21: warning: array subscript -1 is below array bounds of 'bool[2]' {aka '_Bool[2]'} [-Warray-bounds]
      583 |   if (init_opp_table[cluster])
          |       ~~~~~~~~~~~~~~^~~~~~~~~
    arch/arm/mach-vexpress/spc.c:556:7: note: while referencing 'init_opp_table'
      556 |  bool init_opp_table[MAX_CLUSTERS] = { false };
          |       ^~~~~~~~~~~~~~
    arch/arm/mach-vexpress/spc.c:592:18: warning: array subscript -1 is below array bounds of 'bool[2]' {aka '_Bool[2]'} [-Warray-bounds]
      592 |    init_opp_table[cluster] = true;
          |    ~~~~~~~~~~~~~~^~~~~~~~~
    arch/arm/mach-vexpress/spc.c:556:7: note: while referencing 'init_opp_table'
      556 |  bool init_opp_table[MAX_CLUSTERS] = { false };
          |       ^~~~~~~~~~~~~~
    
    Skip this logic when built !SMP.
    
    Link: https://lore.kernel.org/r/20220331190443.851661-1-keescook@chromium.org
    Cc: Liviu Dudau <liviu.dudau@arm.com>
    Cc: Sudeep Holla <sudeep.holla@arm.com>
    Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Acked-by: Liviu Dudau <liviu.dudau@arm.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a5ad1b8db9fd22bbf7c8dfa16fee2701e3f2c47
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Tue Apr 19 16:51:54 2022 +0300

    selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets
    
    [ Upstream commit 044011fdf162c5dd61c02841930c8f438a9adadb ]
    
    The test verifies that packets are correctly flooded by the bridge and
    the VXLAN device by matching on the encapsulated packets at the other
    end. However, if packets other than those generated by the test also
    ingress the bridge (e.g., MLD packets), they will be flooded as well and
    interfere with the expected count.
    
    Make the test more robust by making sure that only the packets generated
    by the test can ingress the bridge. Drop all the rest using tc filters
    on the egress of 'br0' and 'h1'.
    
    In the software data path, the problem can be solved by matching on the
    inner destination MAC or dropping unwanted packets at the egress of the
    VXLAN device, but this is not currently supported by mlxsw.
    
    Fixes: 94d302deae25 ("selftests: mlxsw: Add a test for VxLAN flooding")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d37295129efa182b0c053105b79ab542a714f2b7
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 15 11:14:42 2022 -0700

    netlink: reset network and mac headers in netlink_dump()
    
    [ Upstream commit 99c07327ae11e24886d552dddbe4537bfca2765d ]
    
    netlink_dump() is allocating an skb, reserves space in it
    but forgets to reset network header.
    
    This allows a BPF program, invoked later from sk_filter()
    to access uninitialized kernel memory from the reserved
    space.
    
    Theorically mac header reset could be omitted, because
    it is set to a special initial value.
    bpf_internal_load_pointer_neg_helper calls skb_mac_header()
    without checking skb_mac_header_was_set().
    Relying on skb->len not being too big seems fragile.
    We also could add a sanity check in bpf_internal_load_pointer_neg_helper()
    to avoid surprises in the future.
    
    syzbot report was:
    
    BUG: KMSAN: uninit-value in ___bpf_prog_run+0xa22b/0xb420 kernel/bpf/core.c:1637
     ___bpf_prog_run+0xa22b/0xb420 kernel/bpf/core.c:1637
     __bpf_prog_run32+0x121/0x180 kernel/bpf/core.c:1796
     bpf_dispatcher_nop_func include/linux/bpf.h:784 [inline]
     __bpf_prog_run include/linux/filter.h:626 [inline]
     bpf_prog_run include/linux/filter.h:633 [inline]
     __bpf_prog_run_save_cb+0x168/0x580 include/linux/filter.h:756
     bpf_prog_run_save_cb include/linux/filter.h:770 [inline]
     sk_filter_trim_cap+0x3bc/0x8c0 net/core/filter.c:150
     sk_filter include/linux/filter.h:905 [inline]
     netlink_dump+0xe0c/0x16c0 net/netlink/af_netlink.c:2276
     netlink_recvmsg+0x1129/0x1c80 net/netlink/af_netlink.c:2002
     sock_recvmsg_nosec net/socket.c:948 [inline]
     sock_recvmsg net/socket.c:966 [inline]
     sock_read_iter+0x5a9/0x630 net/socket.c:1039
     do_iter_readv_writev+0xa7f/0xc70
     do_iter_read+0x52c/0x14c0 fs/read_write.c:786
     vfs_readv fs/read_write.c:906 [inline]
     do_readv+0x432/0x800 fs/read_write.c:943
     __do_sys_readv fs/read_write.c:1034 [inline]
     __se_sys_readv fs/read_write.c:1031 [inline]
     __x64_sys_readv+0xe5/0x120 fs/read_write.c:1031
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Uninit was stored to memory at:
     ___bpf_prog_run+0x96c/0xb420 kernel/bpf/core.c:1558
     __bpf_prog_run32+0x121/0x180 kernel/bpf/core.c:1796
     bpf_dispatcher_nop_func include/linux/bpf.h:784 [inline]
     __bpf_prog_run include/linux/filter.h:626 [inline]
     bpf_prog_run include/linux/filter.h:633 [inline]
     __bpf_prog_run_save_cb+0x168/0x580 include/linux/filter.h:756
     bpf_prog_run_save_cb include/linux/filter.h:770 [inline]
     sk_filter_trim_cap+0x3bc/0x8c0 net/core/filter.c:150
     sk_filter include/linux/filter.h:905 [inline]
     netlink_dump+0xe0c/0x16c0 net/netlink/af_netlink.c:2276
     netlink_recvmsg+0x1129/0x1c80 net/netlink/af_netlink.c:2002
     sock_recvmsg_nosec net/socket.c:948 [inline]
     sock_recvmsg net/socket.c:966 [inline]
     sock_read_iter+0x5a9/0x630 net/socket.c:1039
     do_iter_readv_writev+0xa7f/0xc70
     do_iter_read+0x52c/0x14c0 fs/read_write.c:786
     vfs_readv fs/read_write.c:906 [inline]
     do_readv+0x432/0x800 fs/read_write.c:943
     __do_sys_readv fs/read_write.c:1034 [inline]
     __se_sys_readv fs/read_write.c:1031 [inline]
     __x64_sys_readv+0xe5/0x120 fs/read_write.c:1031
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Uninit was created at:
     slab_post_alloc_hook mm/slab.h:737 [inline]
     slab_alloc_node mm/slub.c:3244 [inline]
     __kmalloc_node_track_caller+0xde3/0x14f0 mm/slub.c:4972
     kmalloc_reserve net/core/skbuff.c:354 [inline]
     __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
     alloc_skb include/linux/skbuff.h:1158 [inline]
     netlink_dump+0x30f/0x16c0 net/netlink/af_netlink.c:2242
     netlink_recvmsg+0x1129/0x1c80 net/netlink/af_netlink.c:2002
     sock_recvmsg_nosec net/socket.c:948 [inline]
     sock_recvmsg net/socket.c:966 [inline]
     sock_read_iter+0x5a9/0x630 net/socket.c:1039
     do_iter_readv_writev+0xa7f/0xc70
     do_iter_read+0x52c/0x14c0 fs/read_write.c:786
     vfs_readv fs/read_write.c:906 [inline]
     do_readv+0x432/0x800 fs/read_write.c:943
     __do_sys_readv fs/read_write.c:1034 [inline]
     __se_sys_readv fs/read_write.c:1031 [inline]
     __x64_sys_readv+0xe5/0x120 fs/read_write.c:1031
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    CPU: 0 PID: 3470 Comm: syz-executor751 Not tainted 5.17.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: db65a3aaf29e ("netlink: Trim skb to alloc size to avoid MSG_TRUNC")
    Fixes: 9063e21fb026 ("netlink: autosize skb lengthes")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Link: https://lore.kernel.org/r/20220415181442.551228-1-eric.dumazet@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c4f2a019ff999dade535a0ef366c6c2cfe0d710
Author: David Ahern <dsahern@kernel.org>
Date:   Wed Apr 13 11:43:19 2022 -0600

    l3mdev: l3mdev_master_upper_ifindex_by_index_rcu should be using netdev_master_upper_dev_get_rcu
    
    [ Upstream commit 83daab06252ee5d0e1f4373ff28b79304945fc19 ]
    
    Next patch uses l3mdev_master_upper_ifindex_by_index_rcu which throws
    a splat with debug kernels:
    
    [13783.087570] ------------[ cut here ]------------
    [13783.093974] RTNL: assertion failed at net/core/dev.c (6702)
    [13783.100761] WARNING: CPU: 3 PID: 51132 at net/core/dev.c:6702 netdev_master_upper_dev_get+0x16a/0x1a0
    
    [13783.184226] CPU: 3 PID: 51132 Comm: kworker/3:3 Not tainted 5.17.0-custom-100090-g6f963aafb1cc #682
    [13783.194788] Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017
    [13783.204755] Workqueue: mld mld_ifc_work [ipv6]
    [13783.210338] RIP: 0010:netdev_master_upper_dev_get+0x16a/0x1a0
    [13783.217209] Code: 0f 85 e3 fe ff ff e8 65 ac ec fe ba 2e 1a 00 00 48 c7 c6 60 6f 38 83 48 c7 c7 c0 70 38 83 c6 05 5e b5 d7 01 01 e8 c6 29 52 00 <0f> 0b e9 b8 fe ff ff e8 5a 6c 35 ff e9 1c ff ff ff 48 89 ef e8 7d
    [13783.238659] RSP: 0018:ffffc9000b37f5a8 EFLAGS: 00010286
    [13783.244995] RAX: 0000000000000000 RBX: ffff88812ee5c000 RCX: 0000000000000000
    [13783.253379] RDX: ffff88811ce09d40 RSI: ffffffff812d0fcd RDI: fffff5200166fea7
    [13783.261769] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff8882375f4287
    [13783.270138] R10: ffffed1046ebe850 R11: 0000000000000001 R12: dffffc0000000000
    [13783.278510] R13: 0000000000000275 R14: ffffc9000b37f688 R15: ffff8881273b4af8
    [13783.286870] FS:  0000000000000000(0000) GS:ffff888237400000(0000) knlGS:0000000000000000
    [13783.296352] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [13783.303177] CR2: 00007ff25fc9b2e8 CR3: 0000000174d23000 CR4: 00000000001006e0
    [13783.311546] Call Trace:
    [13783.314660]  <TASK>
    [13783.317553]  l3mdev_master_upper_ifindex_by_index_rcu+0x43/0xe0
    ...
    
    Change l3mdev_master_upper_ifindex_by_index_rcu to use
    netdev_master_upper_dev_get_rcu.
    
    Fixes: 6a6d6681ac1a ("l3mdev: add function to retreive upper master")
    Signed-off-by: Ido Schimmel <idosch@idosch.org>
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Cc: Alexis Bauvin <abauvin@scaleway.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c5ca6492a86e18ff9ae39f742285996c2209ac9
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Apr 13 10:35:42 2022 -0700

    net/sched: cls_u32: fix possible leak in u32_init_knode()
    
    [ Upstream commit ec5b0f605b105457f257f2870acad4a5d463984b ]
    
    While investigating a related syzbot report,
    I found that whenever call to tcf_exts_init()
    from u32_init_knode() is failing, we end up
    with an elevated refcount on ht->refcnt
    
    To avoid that, only increase the refcount after
    all possible errors have been evaluated.
    
    Fixes: b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f883def546541f53145f8d0591881dc5dd5341d4
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Apr 14 16:49:25 2022 +0800

    net/packet: fix packet_sock xmit return value checking
    
    [ Upstream commit 29e8e659f984be00d75ec5fef4e37c88def72712 ]
    
    packet_sock xmit could be dev_queue_xmit, which also returns negative
    errors. So only checking positive errors is not enough, or userspace
    sendmsg may return success while packet is not send out.
    
    Move the net_xmit_errno() assignment in the braces as checkpatch.pl said
    do not use assignment in if condition.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Flavio Leitner <fbl@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1bc684c81f1b9f935d2c4f3a760823cd6ba824b
Author: Tony Lu <tonylu@linux.alibaba.com>
Date:   Thu Apr 14 15:51:03 2022 +0800

    net/smc: Fix sock leak when release after smc_shutdown()
    
    [ Upstream commit 1a74e99323746353bba11562a2f2d0aa8102f402 ]
    
    Since commit e5d5aadcf3cd ("net/smc: fix sk_refcnt underflow on linkdown
    and fallback"), for a fallback connection, __smc_release() does not call
    sock_put() if its state is already SMC_CLOSED.
    
    When calling smc_shutdown() after falling back, its state is set to
    SMC_CLOSED but does not call sock_put(), so this patch calls it.
    
    Reported-and-tested-by: syzbot+6e29a053eb165bd50de5@syzkaller.appspotmail.com
    Fixes: e5d5aadcf3cd ("net/smc: fix sk_refcnt underflow on linkdown and fallback")
    Signed-off-by: Tony Lu <tonylu@linux.alibaba.com>
    Acked-by: Karsten Graul <kgraul@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f10e5c9f226cf90fcf796e590b75dea85d3bdfd8
Author: David Howells <dhowells@redhat.com>
Date:   Wed Apr 13 11:16:25 2022 +0100

    rxrpc: Restore removed timer deletion
    
    [ Upstream commit ee3b0826b4764f6c13ad6db67495c5a1c38e9025 ]
    
    A recent patch[1] from Eric Dumazet flipped the order in which the
    keepalive timer and the keepalive worker were cancelled in order to fix a
    syzbot reported issue[2].  Unfortunately, this enables the mirror image bug
    whereby the timer races with rxrpc_exit_net(), restarting the worker after
    it has been cancelled:
    
            CPU 1           CPU 2
            =============== =====================
                            if (rxnet->live)
                            <INTERRUPT>
            rxnet->live = false;
            cancel_work_sync(&rxnet->peer_keepalive_work);
                            rxrpc_queue_work(&rxnet->peer_keepalive_work);
            del_timer_sync(&rxnet->peer_keepalive_timer);
    
    Fix this by restoring the removed del_timer_sync() so that we try to remove
    the timer twice.  If the timer runs again, it should see ->live == false
    and not restart the worker.
    
    Fixes: 1946014ca3b1 ("rxrpc: fix a race in rxrpc_exit_net()")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/20220404183439.3537837-1-eric.dumazet@gmail.com/ [1]
    Link: https://syzkaller.appspot.com/bug?extid=724378c4bb58f703b09a [2]
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a9c481593650bbe4066e2185de6b68a82a4110f
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Wed Mar 9 08:19:19 2022 +0200

    igc: Fix BUG: scheduling while atomic
    
    [ Upstream commit c80a29f0fe9b6f5457e0788e27d1110577eba99b ]
    
    Replace usleep_range() method with udelay() method to allow atomic contexts
    in low-level MDIO access functions.
    
    The following issue can be seen by doing the following:
    $ modprobe -r bonding
    $ modprobe -v bonding max_bonds=1 mode=1 miimon=100 use_carrier=0
    $ ip link set bond0 up
    $ ifenslave bond0 eth0 eth1
    
    [  982.357308] BUG: scheduling while atomic: kworker/u64:0/9/0x00000002
    [  982.364431] INFO: lockdep is turned off.
    [  982.368824] Modules linked in: bonding sctp ip6_udp_tunnel udp_tunnel mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core nfp tls sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support mxm_wmi dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate intel_uncore pcspkr lpc_ich mei_me ipmi_ssif mei ipmi_si ipmi_devintf ipmi_msghandler wmi acpi_power_meter xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci crc32c_intel libata i2c_algo_bit tg3 megaraid_sas igc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: bonding]
    [  982.437941] CPU: 25 PID: 9 Comm: kworker/u64:0 Kdump: loaded Tainted: G        W        --------- -  - 4.18.0-348.el8.x86_64+debug #1
    [  982.451333] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 2.7.0 12/005/2017
    [  982.459791] Workqueue: bond0 bond_mii_monitor [bonding]
    [  982.465622] Call Trace:
    [  982.468355]  dump_stack+0x8e/0xd0
    [  982.472056]  __schedule_bug.cold.60+0x3a/0x60
    [  982.476919]  __schedule+0x147b/0x1bc0
    [  982.481007]  ? firmware_map_remove+0x16b/0x16b
    [  982.485967]  ? hrtimer_fixup_init+0x40/0x40
    [  982.490625]  schedule+0xd9/0x250
    [  982.494227]  schedule_hrtimeout_range_clock+0x10d/0x2c0
    [  982.500058]  ? hrtimer_nanosleep_restart+0x130/0x130
    [  982.505598]  ? hrtimer_init_sleeper_on_stack+0x90/0x90
    [  982.511332]  ? usleep_range+0x88/0x130
    [  982.515514]  ? recalibrate_cpu_khz+0x10/0x10
    [  982.520279]  ? ktime_get+0xab/0x1c0
    [  982.524175]  ? usleep_range+0x88/0x130
    [  982.528355]  usleep_range+0xdd/0x130
    [  982.532344]  ? console_conditional_schedule+0x30/0x30
    [  982.537987]  ? igc_put_hw_semaphore+0x17/0x60 [igc]
    [  982.543432]  igc_read_phy_reg_gpy+0x111/0x2b0 [igc]
    [  982.548887]  igc_phy_has_link+0xfa/0x260 [igc]
    [  982.553847]  ? igc_get_phy_id+0x210/0x210 [igc]
    [  982.558894]  ? lock_acquire+0x34d/0x890
    [  982.563187]  ? lock_downgrade+0x710/0x710
    [  982.567659]  ? rcu_read_unlock+0x50/0x50
    [  982.572039]  igc_check_for_copper_link+0x106/0x210 [igc]
    [  982.577970]  ? igc_config_fc_after_link_up+0x840/0x840 [igc]
    [  982.584286]  ? rcu_read_unlock+0x50/0x50
    [  982.588661]  ? lock_release+0x591/0xb80
    [  982.592939]  ? lock_release+0x591/0xb80
    [  982.597220]  igc_has_link+0x113/0x330 [igc]
    [  982.601887]  ? lock_downgrade+0x710/0x710
    [  982.606362]  igc_ethtool_get_link+0x6d/0x90 [igc]
    [  982.611614]  bond_check_dev_link+0x131/0x2c0 [bonding]
    [  982.617350]  ? bond_time_in_interval+0xd0/0xd0 [bonding]
    [  982.623277]  ? rcu_read_lock_held+0x62/0xc0
    [  982.627944]  ? rcu_read_lock_sched_held+0xe0/0xe0
    [  982.633198]  bond_mii_monitor+0x314/0x2500 [bonding]
    [  982.638738]  ? lock_contended+0x880/0x880
    [  982.643214]  ? bond_miimon_link_change+0xa0/0xa0 [bonding]
    [  982.649336]  ? lock_acquire+0x34d/0x890
    [  982.653615]  ? lock_downgrade+0x710/0x710
    [  982.658089]  ? debug_object_deactivate+0x221/0x340
    [  982.663436]  ? rcu_read_unlock+0x50/0x50
    [  982.667811]  ? debug_print_object+0x2b0/0x2b0
    [  982.672672]  ? __switch_to_asm+0x41/0x70
    [  982.677049]  ? __switch_to_asm+0x35/0x70
    [  982.681426]  ? _raw_spin_unlock_irq+0x24/0x40
    [  982.686288]  ? trace_hardirqs_on+0x20/0x195
    [  982.690956]  ? _raw_spin_unlock_irq+0x24/0x40
    [  982.695818]  process_one_work+0x8f0/0x1770
    [  982.700390]  ? pwq_dec_nr_in_flight+0x320/0x320
    [  982.705443]  ? debug_show_held_locks+0x50/0x50
    [  982.710403]  worker_thread+0x87/0xb40
    [  982.714489]  ? process_one_work+0x1770/0x1770
    [  982.719349]  kthread+0x344/0x410
    [  982.722950]  ? kthread_insert_work_sanity_check+0xd0/0xd0
    [  982.728975]  ret_from_fork+0x3a/0x50
    
    Fixes: 5586838fe9ce ("igc: Add code for PHY support")
    Reported-by: Corinna Vinschen <vinschen@redhat.com>
    Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Corinna Vinschen <vinschen@redhat.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9d5d17d234faf072bb7f759bb7e6cb9ab6ad247
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Tue Mar 1 15:32:10 2022 +0200

    igc: Fix infinite loop in release_swfw_sync
    
    [ Upstream commit 907862e9aef75bf89e2b265efcc58870be06081e ]
    
    An infinite loop may occur if we fail to acquire the HW semaphore,
    which is needed for resource release.
    This will typically happen if the hardware is surprise-removed.
    At this stage there is nothing to do, except log an error and quit.
    
    Fixes: c0071c7aa5fe ("igc: Add HW initialization code")
    Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d6271dbbbe5ee53c3233ea5377bb2b823c761be
Author: zhangqilong <zhangqilong3@huawei.com>
Date:   Sat Mar 19 10:21:42 2022 +0800

    dmaengine: mediatek:Fix PM usage reference leak of mtk_uart_apdma_alloc_chan_resources
    
    [ Upstream commit 545b2baac89b859180e51215468c05d85ea8465a ]
    
    pm_runtime_get_sync will increment pm usage counter even it failed.
    Forgetting to putting operation will result in reference leak here.
    We fix it:
    1) Replacing it with pm_runtime_resume_and_get to keep usage counter
       balanced.
    2) Add putting operation before returning error.
    
    Fixes:9135408c3ace4 ("dmaengine: mediatek: Add MediaTek UART APDMA support")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20220319022142.142709-1-zhangqilong3@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65c36555bd7df7426bf49bcdf911e959f76f761c
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Mar 8 06:49:51 2022 +0000

    dmaengine: imx-sdma: Fix error checking in sdma_event_remap
    
    [ Upstream commit 7104b9cb35a33ad803a1adbbfa50569b008faf15 ]
    
    of_parse_phandle() returns NULL on errors, rather than error
    pointers. Using NULL check on grp_np to fix this.
    
    Fixes: d078cd1b4185 ("dmaengine: imx-sdma: Add imx6sx platform support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220308064952.15743-1-linmq006@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccf554d148ebf4e24641df77b2b7bd8d231617df
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Apr 3 11:52:39 2022 +0000

    ASoC: msm8916-wcd-digital: Check failure for devm_snd_soc_register_component
    
    [ Upstream commit e927b05f3cc20de87f6b7d912a5bbe556931caca ]
    
    devm_snd_soc_register_component() may fails, we should check the error
    and do the corresponding error handling.
    
    Fixes: 150db8c5afa1 ("ASoC: codecs: Add msm8916-wcd digital codec")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220403115239.30140-1-linmq006@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a20bf46c6254e4e99613309c334519a5f54be53
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Mar 25 15:42:39 2022 +0000

    ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek
    
    [ Upstream commit c775cbf62ed4911e4f0f23880f01815753123690 ]
    
    The MCLK of the WM8731 on the AT91SAM9G20-EK board is connected to the
    PCK0 output of the SoC, intended in the reference software to be supplied
    using PLLB and programmed to 12MHz. As originally written for use with a
    board file the audio driver was responsible for configuring the entire tree
    but in the conversion to the common clock framework the registration of
    the named pck0 and pllb clocks was removed so the driver has failed to
    instantiate ever since.
    
    Since the WM8731 driver has had support for managing a MCLK provided via
    the common clock framework for some time we can simply drop all the clock
    management code from the machine driver other than configuration of the
    sysclk rate, the CODEC driver still respects that configuration from the
    machine driver.
    
    Fixes: ff78a189b0ae55f ("ARM: at91: remove old at91-specific clock driver")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Link: https://lore.kernel.org/r/20220325154241.1600757-2-broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a54979c7830e0e13126fd5ca2128797b7266858
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Apr 20 15:02:47 2022 +0200

    ALSA: usb-audio: Clear MIDI port active flag after draining
    
    commit 0665886ad1392e6b5bae85d7a6ccbed48dca1522 upstream.
    
    When a rawmidi output stream is closed, it calls the drain at first,
    then does trigger-off only when the drain returns -ERESTARTSYS as a
    fallback.  It implies that each driver should turn off the stream
    properly after the drain.  Meanwhile, USB-audio MIDI interface didn't
    change the port->active flag after the drain.  This may leave the
    output work picking up the port that is closed right now, which
    eventually leads to a use-after-free for the already released rawmidi
    object.
    
    This patch fixes the bug by properly clearing the port->active flag
    after the output drain.
    
    Reported-by: syzbot+70e777a39907d6d5fd0a@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/00000000000011555605dceaff03@google.com
    Link: https://lore.kernel.org/r/20220420130247.22062-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c99aacfb4c6ddad4678e4d3965e575804021d4f
Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Date:   Mon Jan 18 14:59:20 2021 +0900

    tcp: Fix potential use-after-free due to double kfree()
    
    commit c89dffc70b340780e5b933832d8c3e045ef3791e upstream.
    
    Receiving ACK with a valid SYN cookie, cookie_v4_check() allocates struct
    request_sock and then can allocate inet_rsk(req)->ireq_opt. After that,
    tcp_v4_syn_recv_sock() allocates struct sock and copies ireq_opt to
    inet_sk(sk)->inet_opt. Normally, tcp_v4_syn_recv_sock() inserts the full
    socket into ehash and sets NULL to ireq_opt. Otherwise,
    tcp_v4_syn_recv_sock() has to reset inet_opt by NULL and free the full
    socket.
    
    The commit 01770a1661657 ("tcp: fix race condition when creating child
    sockets from syncookies") added a new path, in which more than one cores
    create full sockets for the same SYN cookie. Currently, the core which
    loses the race frees the full socket without resetting inet_opt, resulting
    in that both sock_put() and reqsk_put() call kfree() for the same memory:
    
      sock_put
        sk_free
          __sk_free
            sk_destruct
              __sk_destruct
                sk->sk_destruct/inet_sock_destruct
                  kfree(rcu_dereference_protected(inet->inet_opt, 1));
    
      reqsk_put
        reqsk_free
          __reqsk_free
            req->rsk_ops->destructor/tcp_v4_reqsk_destructor
              kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));
    
    Calling kmalloc() between the double kfree() can lead to use-after-free, so
    this patch fixes it by setting NULL to inet_opt before sock_put().
    
    As a side note, this kind of issue does not happen for IPv6. This is
    because tcp_v6_syn_recv_sock() clones both ipv6_opt and pktopts which
    correspond to ireq_opt in IPv4.
    
    Fixes: 01770a166165 ("tcp: fix race condition when creating child sockets from syncookies")
    CC: Ricardo Dias <rdias@singlestore.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
    Reviewed-by: Benjamin Herrenschmidt <benh@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20210118055920.82516-1-kuniyu@amazon.co.jp
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a4f3eba211a532b2eb5045102ad3ceea5e9f0f9
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Apr 13 10:35:41 2022 -0700

    net/sched: cls_u32: fix netns refcount changes in u32_change()
    
    commit 3db09e762dc79584a69c10d74a6b98f89a9979f8 upstream.
    
    We are now able to detect extra put_net() at the moment
    they happen, instead of much later in correct code paths.
    
    u32_init_knode() / tcf_exts_init() populates the ->exts.net
    pointer, but as mentioned in tcf_exts_init(),
    the refcount on netns has not been elevated yet.
    
    The refcount is taken only once tcf_exts_get_net()
    is called.
    
    So the two u32_destroy_key() calls from u32_change()
    are attempting to release an invalid reference on the netns.
    
    syzbot report:
    
    refcount_t: decrement hit 0; leaking memory.
    WARNING: CPU: 0 PID: 21708 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
    Modules linked in:
    CPU: 0 PID: 21708 Comm: syz-executor.5 Not tainted 5.18.0-rc2-next-20220412-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
    Code: 1d 14 b6 b2 09 31 ff 89 de e8 6d e9 89 fd 84 db 75 e0 e8 84 e5 89 fd 48 c7 c7 40 aa 26 8a c6 05 f4 b5 b2 09 01 e8 e5 81 2e 05 <0f> 0b eb c4 e8 68 e5 89 fd 0f b6 1d e3 b5 b2 09 31 ff 89 de e8 38
    RSP: 0018:ffffc900051af1b0 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000040000 RSI: ffffffff8160a0c8 RDI: fffff52000a35e28
    RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffffff81604a9e R11: 0000000000000000 R12: 1ffff92000a35e3b
    R13: 00000000ffffffef R14: ffff8880211a0194 R15: ffff8880577d0a00
    FS:  00007f25d183e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f19c859c028 CR3: 0000000051009000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __refcount_dec include/linux/refcount.h:344 [inline]
     refcount_dec include/linux/refcount.h:359 [inline]
     ref_tracker_free+0x535/0x6b0 lib/ref_tracker.c:118
     netns_tracker_free include/net/net_namespace.h:327 [inline]
     put_net_track include/net/net_namespace.h:341 [inline]
     tcf_exts_put_net include/net/pkt_cls.h:255 [inline]
     u32_destroy_key.isra.0+0xa7/0x2b0 net/sched/cls_u32.c:394
     u32_change+0xe01/0x3140 net/sched/cls_u32.c:909
     tc_new_tfilter+0x98d/0x2200 net/sched/cls_api.c:2148
     rtnetlink_rcv_msg+0x80d/0xb80 net/core/rtnetlink.c:6016
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2495
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:725
     ____sys_sendmsg+0x6e2/0x800 net/socket.c:2413
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f25d0689049
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f25d183e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f25d079c030 RCX: 00007f25d0689049
    RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000005
    RBP: 00007f25d06e308d R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffd0b752e3f R14: 00007f25d183e300 R15: 0000000000022000
     </TASK>
    
    Fixes: 35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before call_rcu()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b01b700e0c5a3d820c4884f67708112b034bd6da
Author: Ricardo Dias <rdias@singlestore.com>
Date:   Fri Nov 20 11:11:33 2020 +0000

    tcp: fix race condition when creating child sockets from syncookies
    
    [ Upstream commit 01770a166165738a6e05c3d911fb4609cc4eb416 ]
    
    When the TCP stack is in SYN flood mode, the server child socket is
    created from the SYN cookie received in a TCP packet with the ACK flag
    set.
    
    The child socket is created when the server receives the first TCP
    packet with a valid SYN cookie from the client. Usually, this packet
    corresponds to the final step of the TCP 3-way handshake, the ACK
    packet. But is also possible to receive a valid SYN cookie from the
    first TCP data packet sent by the client, and thus create a child socket
    from that SYN cookie.
    
    Since a client socket is ready to send data as soon as it receives the
    SYN+ACK packet from the server, the client can send the ACK packet (sent
    by the TCP stack code), and the first data packet (sent by the userspace
    program) almost at the same time, and thus the server will equally
    receive the two TCP packets with valid SYN cookies almost at the same
    instant.
    
    When such event happens, the TCP stack code has a race condition that
    occurs between the momement a lookup is done to the established
    connections hashtable to check for the existence of a connection for the
    same client, and the moment that the child socket is added to the
    established connections hashtable. As a consequence, this race condition
    can lead to a situation where we add two child sockets to the
    established connections hashtable and deliver two sockets to the
    userspace program to the same client.
    
    This patch fixes the race condition by checking if an existing child
    socket exists for the same client when we are adding the second child
    socket to the established connections socket. If an existing child
    socket exists, we drop the packet and discard the second child socket
    to the same client.
    
    Signed-off-by: Ricardo Dias <rdias@singlestore.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20201120111133.GA67501@rdias-suse-pc.lan
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebb3b84596bd8e598cd7277e10d46cdac685d34d
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Mon Jan 17 10:25:07 2022 -0500

    gfs2: assign rgrp glock before compute_bitstructs
    
    commit 428f651cb80b227af47fc302e4931791f2fb4741 upstream.
    
    Before this patch, function read_rindex_entry called compute_bitstructs
    before it allocated a glock for the rgrp. But if compute_bitstructs found
    a problem with the rgrp, it called gfs2_consist_rgrpd, and that called
    gfs2_dump_glock for rgd->rd_gl which had not yet been assigned.
    
    read_rindex_entry
       compute_bitstructs
          gfs2_consist_rgrpd
             gfs2_dump_glock <---------rgd->rd_gl was not set.
    
    This patch changes read_rindex_entry so it assigns an rgrp glock before
    calling compute_bitstructs so gfs2_dump_glock does not reference an
    unassigned pointer. If an error is discovered, the glock must also be
    put, so a new goto and label were added.
    
    Reported-by: syzbot+c6fd14145e2f62ca0784@syzkaller.appspotmail.com
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 660784e7194ac2953aebe874c1f75f2441ba3d19
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Fri Mar 11 16:06:14 2022 +0800

    can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path
    
    commit 3d3925ff6433f98992685a9679613a2cc97f3ce2 upstream.
    
    There is no need to call dev_kfree_skb() when usb_submit_urb() fails
    because can_put_echo_skb() deletes original skb and
    can_free_echo_skb() deletes the cloned skb.
    
    Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
    Link: https://lore.kernel.org/all/20220311080614.45229-1-hbh25y@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [DP: adjusted params of can_free_echo_skb() for 5.4 stable]
    Signed-off-by: Dragos-Marian Panait <dragos.panait@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2da11442a1e3317e7cfdda94e7ca90b9274dfe33
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Sun Feb 20 23:49:57 2022 +0100

    tracing: Dump stacktrace trigger to the corresponding instance
    
    commit ce33c845b030c9cf768370c951bc699470b09fa7 upstream.
    
    The stacktrace event trigger is not dumping the stacktrace to the instance
    where it was enabled, but to the global "instance."
    
    Use the private_data, pointing to the trigger file, to figure out the
    corresponding trace instance, and use it in the trigger action, like
    snapshot_trigger does.
    
    Link: https://lkml.kernel.org/r/afbb0b4f18ba92c276865bc97204d438473f4ebc.1645396236.git.bristot@kernel.org
    
    Cc: stable@vger.kernel.org
    Fixes: ae63b31e4d0e2 ("tracing: Separate out trace events from global variables")
    Reviewed-by: Tom Zanussi <zanussi@kernel.org>
    Tested-by: Tom Zanussi <zanussi@kernel.org>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bad7ed55756f418536ab16fadccaa330d280d2f1
Author: Xiongwei Song <sxwjean@gmail.com>
Date:   Fri Jan 14 14:07:24 2022 -0800

    mm: page_alloc: fix building error on -Werror=array-compare
    
    commit ca831f29f8f25c97182e726429b38c0802200c8f upstream.
    
    Arthur Marsh reported we would hit the error below when building kernel
    with gcc-12:
    
      CC      mm/page_alloc.o
      mm/page_alloc.c: In function `mem_init_print_info':
      mm/page_alloc.c:8173:27: error: comparison between two arrays [-Werror=array-compare]
       8173 |                 if (start <= pos && pos < end && size > adj) \
            |
    
    In C++20, the comparision between arrays should be warned.
    
    Link: https://lkml.kernel.org/r/20211125130928.32465-1-sxwjean@me.com
    Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
    Reported-by: Arthur Marsh <arthur.marsh@internode.on.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Khem Raj <raj.khem@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac94e87675b2f80adc0201a2537d07c7598b51cc
Author: Kees Cook <keescook@chromium.org>
Date:   Sat Feb 12 09:14:49 2022 -0800

    etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
    
    commit 2618a0dae09ef37728dab89ff60418cbe25ae6bd upstream.
    
    With GCC 12, -Wstringop-overread was warning about an implicit cast from
    char[6] to char[8]. However, the extra 2 bytes are always thrown away,
    alignment doesn't matter, and the risk of hitting the edge of unallocated
    memory has been accepted, so this prototype can just be converted to a
    regular char *. Silences:
    
    net/core/dev.c: In function ‘bpf_prog_run_generic_xdp’: net/core/dev.c:4618:21: warning: ‘ether_addr_equal_64bits’ reading 8 bytes from a region of size 6 [-Wstringop-overread]
     4618 |         orig_host = ether_addr_equal_64bits(eth->h_dest, > skb->dev->dev_addr);
          |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    net/core/dev.c:4618:21: note: referencing argument 1 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’}
    net/core/dev.c:4618:21: note: referencing argument 2 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’}
    In file included from net/core/dev.c:91: include/linux/etherdevice.h:375:20: note: in a call to function ‘ether_addr_equal_64bits’
      375 | static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
          |                    ^~~~~~~~~~~~~~~~~~~~~~~
    
    Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Link: https://lore.kernel.org/netdev/20220212090811.uuzk6d76agw2vv73@pengutronix.de
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: netdev@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Khem Raj <raj.khem@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>