commit d98bf8b949c03b840010c5a4f2671b7c79019d76
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 10 12:42:37 2021 +0200

    Linux 4.9.272
    
    Link: https://lore.kernel.org/r/20210608175927.821075974@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a12c2d8efb55b95f736b6fe0d077aaf9640878cb
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue May 18 18:13:42 2021 +0200

    xen-pciback: redo VF placement in the virtual topology
    
    The commit referenced below was incomplete: It merely affected what
    would get written to the vdev-<N> xenstore node. The guest would still
    find the function at the original function number as long as
    __xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt
    __xen_pcibk_get_pcifront_dev().
    
    Undo overriding the function to zero and instead make sure that VFs at
    function zero remain alone in their slot. This has the added benefit of
    improving overall capacity, considering that there's only a total of 32
    slots available right now (PCI segment and bus can both only ever be
    zero at present).
    
    This is upstream commit 4ba50e7c423c29639878c00573288869aa627068.
    
    Fixes: 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to
    separate virtual slots")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: https://lore.kernel.org/r/8def783b-404c-3452-196d-3f3fd4d72c9e@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61a912d51d7db2b94301f7f1b057507ad97b07a2
Author: Michael Weiser <michael.weiser@gmx.de>
Date:   Thu Feb 1 23:13:36 2018 +0100

    arm64: Remove unimplemented syscall log message
    
    commit 1962682d2b2fbe6cfa995a85c53c069fadda473e upstream.
    
    Stop printing a (ratelimited) kernel message for each instance of an
    unimplemented syscall being called. Userland making an unimplemented
    syscall is not necessarily misbehaviour and to be expected with a
    current userland running on an older kernel. Also, the current message
    looks scary to users but does not actually indicate a real problem nor
    help them narrow down the cause. Just rely on sys_ni_syscall() to return
    -ENOSYS.
    
    Cc: <stable@vger.kernel.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 124d79bb04c90211f160e4ae5762a056d4557af8
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Apr 21 19:21:22 2021 -0700

    KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode
    
    commit 0884335a2e653b8a045083aa1d57ce74269ac81d upstream.
    
    Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not
    in 64-bit mode.  The APM states bits 63:32 are dropped for both DRs and
    CRs:
    
      In 64-bit mode, the operand size is fixed at 64 bits without the need
      for a REX prefix. In non-64-bit mode, the operand size is fixed at 32
      bits and the upper 32 bits of the destination are forced to 0.
    
    Fixes: 7ff76d58a9dc ("KVM: SVM: enhance MOV CR intercept handler")
    Fixes: cae3797a4639 ("KVM: SVM: enhance mov DR intercept handler")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210422022128.3464144-4-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [sudip: manual backport to old file]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1eee552fe00e2fe4ac4e6d0d935db469815bb8da
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Mon Jan 27 04:56:15 2020 -0500

    bnxt_en: Remove the setting of dev_port.
    
    commit 1d86859fdf31a0d50cc82b5d0d6bfb5fe98f6c00 upstream.
    
    The dev_port is meant to distinguish the network ports belonging to
    the same PCI function.  Our devices only have one network port
    associated with each PCI function and so we should not set it for
    correctness.
    
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a7ccd02dcb9f09550f95e9d697c31af35d1a60b
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed May 19 13:13:15 2021 -0400

    btrfs: fixup error handling in fixup_inode_link_counts
    
    commit 011b28acf940eb61c000059dd9e2cfcbf52ed96b upstream.
    
    This function has the following pattern
    
            while (1) {
                    ret = whatever();
                    if (ret)
                            goto out;
            }
            ret = 0
    out:
            return ret;
    
    However several places in this while loop we simply break; when there's
    a problem, thus clearing the return value, and in one case we do a
    return -EIO, and leak the memory for the path.
    
    Fix this by re-arranging the loop to deal with ret == 1 coming from
    btrfs_search_slot, and then simply delete the
    
            ret = 0;
    out:
    
    bit so everybody can break if there is an error, which will allow for
    proper error handling to occur.
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 247dcb0f56753a45e280592a24fd86b12200d5d8
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed May 19 10:52:45 2021 -0400

    btrfs: fix error handling in btrfs_del_csums
    
    commit b86652be7c83f70bf406bed18ecf55adb9bfb91b upstream.
    
    Error injection stress would sometimes fail with checksums on disk that
    did not have a corresponding extent.  This occurred because the pattern
    in btrfs_del_csums was
    
            while (1) {
                    ret = btrfs_search_slot();
                    if (ret < 0)
                            break;
            }
            ret = 0;
    out:
            btrfs_free_path(path);
            return ret;
    
    If we got an error from btrfs_search_slot we'd clear the error because
    we were breaking instead of goto out.  Instead of using goto out, simply
    handle the cases where we may leave a random value in ret, and get rid
    of the
    
            ret = 0;
    out:
    
    pattern and simply allow break to have the proper error reporting.  With
    this fix we properly abort the transaction and do not commit thinking we
    successfully deleted the csum.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39c15bd2e5d11bcf7f4c3dba2aad9e1e110a5d94
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Mon May 31 09:21:38 2021 +0200

    nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect
    
    commit 4ac06a1e013cf5fdd963317ffd3b968560f33bba upstream.
    
    It's possible to trigger NULL pointer dereference by local unprivileged
    user, when calling getsockname() after failed bind() (e.g. the bind
    fails because LLCP_SAP_MAX used as SAP):
    
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      CPU: 1 PID: 426 Comm: llcp_sock_getna Not tainted 5.13.0-rc2-next-20210521+ #9
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
      Call Trace:
       llcp_sock_getname+0xb1/0xe0
       __sys_getpeername+0x95/0xc0
       ? lockdep_hardirqs_on_prepare+0xd5/0x180
       ? syscall_enter_from_user_mode+0x1c/0x40
       __x64_sys_getpeername+0x11/0x20
       do_syscall_64+0x36/0x70
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    This can be reproduced with Syzkaller C repro (bind followed by
    getpeername):
    https://syzkaller.appspot.com/x/repro.c?x=14def446e00000
    
    Cc: <stable@vger.kernel.org>
    Fixes: d646960f7986 ("NFC: Initial LLCP support")
    Reported-by: syzbot+80fb126e7f7d8b1a5914@syzkaller.appspotmail.com
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210531072138.5219-1-krzysztof.kozlowski@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33e03adafb29eedae1bae9cdb50c1385279fcf65
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Fri Jun 4 20:01:42 2021 -0700

    ocfs2: fix data corruption by fallocate
    
    commit 6bba4471f0cc1296fe3c2089b9e52442d3074b2e upstream.
    
    When fallocate punches holes out of inode size, if original isize is in
    the middle of last cluster, then the part from isize to the end of the
    cluster will be zeroed with buffer write, at that time isize is not yet
    updated to match the new size, if writeback is kicked in, it will invoke
    ocfs2_writepage()->block_write_full_page() where the pages out of inode
    size will be dropped.  That will cause file corruption.  Fix this by
    zero out eof blocks when extending the inode size.
    
    Running the following command with qemu-image 4.2.1 can get a corrupted
    coverted image file easily.
    
        qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
                 -O qcow2 -o compat=1.1 $qcow_image.conv
    
    The usage of fallocate in qemu is like this, it first punches holes out
    of inode size, then extend the inode size.
    
        fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
        fallocate(11, 0, 2276196352, 65536) = 0
    
    v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html
    v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/
    
    Link: https://lkml.kernel.org/r/20210528210648.9124-1-junxiao.bi@oracle.com
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    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 f86c80515a8a3703e0ca2e56deb50fc2879c5ea4
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Jun 4 20:01:14 2021 -0700

    pid: take a reference when initializing `cad_pid`
    
    commit 0711f0d7050b9e07c44bc159bbc64ac0a1022c7f upstream.
    
    During boot, kernel_init_freeable() initializes `cad_pid` to the init
    task's struct pid.  Later on, we may change `cad_pid` via a sysctl, and
    when this happens proc_do_cad_pid() will increment the refcount on the
    new pid via get_pid(), and will decrement the refcount on the old pid
    via put_pid().  As we never called get_pid() when we initialized
    `cad_pid`, we decrement a reference we never incremented, can therefore
    free the init task's struct pid early.  As there can be dangling
    references to the struct pid, we can later encounter a use-after-free
    (e.g.  when delivering signals).
    
    This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to
    have been around since the conversion of `cad_pid` to struct pid in
    commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the
    pre-KASAN stone age of v2.6.19.
    
    Fix this by getting a reference to the init task's struct pid when we
    assign it to `cad_pid`.
    
    Full KASAN splat below.
    
       ==================================================================
       BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline]
       BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
       Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273
    
       CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1
       Hardware name: linux,dummy-virt (DT)
       Call trace:
        ns_of_pid include/linux/pid.h:153 [inline]
        task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
        do_notify_parent+0x308/0xe60 kernel/signal.c:1950
        exit_notify kernel/exit.c:682 [inline]
        do_exit+0x2334/0x2bd0 kernel/exit.c:845
        do_group_exit+0x108/0x2c8 kernel/exit.c:922
        get_signal+0x4e4/0x2a88 kernel/signal.c:2781
        do_signal arch/arm64/kernel/signal.c:882 [inline]
        do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936
        work_pending+0xc/0x2dc
    
       Allocated by task 0:
        slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516
        slab_alloc_node mm/slub.c:2907 [inline]
        slab_alloc mm/slub.c:2915 [inline]
        kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920
        alloc_pid+0xdc/0xc00 kernel/pid.c:180
        copy_process+0x2794/0x5e18 kernel/fork.c:2129
        kernel_clone+0x194/0x13c8 kernel/fork.c:2500
        kernel_thread+0xd4/0x110 kernel/fork.c:2552
        rest_init+0x44/0x4a0 init/main.c:687
        arch_call_rest_init+0x1c/0x28
        start_kernel+0x520/0x554 init/main.c:1064
        0x0
    
       Freed by task 270:
        slab_free_hook mm/slub.c:1562 [inline]
        slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600
        slab_free mm/slub.c:3161 [inline]
        kmem_cache_free+0x224/0x8e0 mm/slub.c:3177
        put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114
        put_pid+0x30/0x48 kernel/pid.c:109
        proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401
        proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591
        proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617
        call_write_iter include/linux/fs.h:1977 [inline]
        new_sync_write+0x3ac/0x510 fs/read_write.c:518
        vfs_write fs/read_write.c:605 [inline]
        vfs_write+0x9c4/0x1018 fs/read_write.c:585
        ksys_write+0x124/0x240 fs/read_write.c:658
        __do_sys_write fs/read_write.c:670 [inline]
        __se_sys_write fs/read_write.c:667 [inline]
        __arm64_sys_write+0x78/0xb0 fs/read_write.c:667
        __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
        invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]
        el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129
        do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168
        el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416
        el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432
        el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701
    
       The buggy address belongs to the object at ffff23794dda0000
        which belongs to the cache pid of size 224
       The buggy address is located 4 bytes inside of
        224-byte region [ffff23794dda0000, ffff23794dda00e0)
       The buggy address belongs to the page:
       page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4dda0
       head:(____ptrval____) order:1 compound_mapcount:0
       flags: 0x3fffc0000010200(slab|head)
       raw: 03fffc0000010200 dead000000000100 dead000000000122 ffff23794d40d080
       raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
    
       Memory state around the buggy address:
        ffff23794dd9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff23794dd9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       >ffff23794dda0000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
        ffff23794dda0080: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
        ffff23794dda0100: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
       ==================================================================
    
    Link: https://lkml.kernel.org/r/20210524172230.38715-1-mark.rutland@arm.com
    Fixes: 9ec52099e4b8678a ("[PATCH] replace cad_pid by a struct pid")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Cedric Le Goater <clg@fr.ibm.com>
    Cc: Christian Brauner <christian@brauner.io>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Kees Cook <keescook@chromium.org
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Paul Mackerras <paulus@samba.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 5b3a9a2be59478b013a430ac57b0f3d65471b071
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu May 6 22:10:42 2021 +0800

    ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed
    
    commit 082cd4ec240b8734a82a89ffb890216ac98fec68 upstream.
    
    We got follow bug_on when run fsstress with injecting IO fault:
    [130747.323114] kernel BUG at fs/ext4/extents_status.c:762!
    [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP
    ......
    [130747.334329] Call trace:
    [130747.334553]  ext4_es_cache_extent+0x150/0x168 [ext4]
    [130747.334975]  ext4_cache_extents+0x64/0xe8 [ext4]
    [130747.335368]  ext4_find_extent+0x300/0x330 [ext4]
    [130747.335759]  ext4_ext_map_blocks+0x74/0x1178 [ext4]
    [130747.336179]  ext4_map_blocks+0x2f4/0x5f0 [ext4]
    [130747.336567]  ext4_mpage_readpages+0x4a8/0x7a8 [ext4]
    [130747.336995]  ext4_readpage+0x54/0x100 [ext4]
    [130747.337359]  generic_file_buffered_read+0x410/0xae8
    [130747.337767]  generic_file_read_iter+0x114/0x190
    [130747.338152]  ext4_file_read_iter+0x5c/0x140 [ext4]
    [130747.338556]  __vfs_read+0x11c/0x188
    [130747.338851]  vfs_read+0x94/0x150
    [130747.339110]  ksys_read+0x74/0xf0
    
    This patch's modification is according to Jan Kara's suggestion in:
    https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/
    "I see. Now I understand your patch. Honestly, seeing how fragile is trying
    to fix extent tree after split has failed in the middle, I would probably
    go even further and make sure we fix the tree properly in case of ENOSPC
    and EDQUOT (those are easily user triggerable).  Anything else indicates a
    HW problem or fs corruption so I'd rather leave the extent tree as is and
    don't try to fix it (which also means we will not create overlapping
    extents)."
    
    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/20210506141042.3298679-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc7892c38f48b2ad125439e5d4c86eefd85d1005
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jun 2 13:38:23 2021 +0200

    ALSA: timer: Fix master timer notification
    
    commit 9c1fe96bded935369f8340c2ac2e9e189f697d5d upstream.
    
    snd_timer_notify1() calls the notification to each slave for a master
    event, but it passes a wrong event number.  It should be +10 offset,
    corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with
    +100 offset.  Casually this was spotted by UBSAN check via syzkaller.
    
    Reported-by: syzbot+d102fa5b35335a7e544e@syzkaller.appspotmail.com
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com
    Link: https://lore.kernel.org/r/20210602113823.23777-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81afc61cb6e2b553f2c5f992fa79e0ae73857141
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:39:35 2021 +0300

    net: caif: fix memory leak in cfusbl_device_notify
    
    commit 7f5d86669fa4d485523ddb1d212e0a2d90bd62bb upstream.
    
    In case of caif_enroll_dev() fail, allocated
    link_support won't be assigned to the corresponding
    structure. So simply free allocated pointer in case
    of error.
    
    Fixes: 7ad65bf68d70 ("caif: Add support for CAIF over CDC NCM USB interface")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9348c1f10932f13b299cbc8b1bd5f780751fae49
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:39:11 2021 +0300

    net: caif: fix memory leak in caif_device_notify
    
    commit b53558a950a89824938e9811eddfc8efcd94e1bb upstream.
    
    In case of caif_enroll_dev() fail, allocated
    link_support won't be assigned to the corresponding
    structure. So simply free allocated pointer in case
    of error
    
    Fixes: 7c18d2205ea7 ("caif: Restructure how link caif link layer enroll")
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: syzbot+7ec324747ce876a29db6@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f6da6c526a0bf470536b59fdb219d11336e390e
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:38:51 2021 +0300

    net: caif: add proper error handling
    
    commit a2805dca5107d5603f4bbc027e81e20d93476e96 upstream.
    
    caif_enroll_dev() can fail in some cases. Ingnoring
    these cases can lead to memory leak due to not assigning
    link_support pointer to anywhere.
    
    Fixes: 7c18d2205ea7 ("caif: Restructure how link caif link layer enroll")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eb4fd7fb51166b2fdda0fda330c03902dca89ac
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:38:12 2021 +0300

    net: caif: added cfserl_release function
    
    commit bce130e7f392ddde8cfcb09927808ebd5f9c8669 upstream.
    
    Added cfserl_release() function.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c62132da179fd30531958d51c68ba4915996556
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun May 30 21:37:43 2021 +0800

    Bluetooth: use correct lock to prevent UAF of hdev object
    
    commit e305509e678b3a4af2b3cfd410f409f7cdaabb52 upstream.
    
    The hci_sock_dev_event() function will cleanup the hdev object for
    sockets even if this object may still be in used within the
    hci_sock_bound_ioctl() function, result in UAF vulnerability.
    
    This patch replace the BH context lock to serialize these affairs
    and prevent the race condition.
    
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75aa7baab3e18a98f232f14dd9cc6965bcf9b31a
Author: Lin Ma <linma@zju.edu.cn>
Date:   Tue May 25 14:39:02 2021 +0200

    Bluetooth: fix the erroneous flush_work() order
    
    commit 6a137caec23aeb9e036cdfd8a46dd8a366460e5d upstream.
    
    In the cleanup routine for failed initialization of HCI device,
    the flush_work(&hdev->rx_work) need to be finished before the
    flush_work(&hdev->cmd_work). Otherwise, the hci_rx_work() can
    possibly invoke new cmd_work and cause a bug, like double free,
    in late processings.
    
    This was assigned CVE-2021-3564.
    
    This patch reorder the flush_work() to fix this bug.
    
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: linux-bluetooth@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: Hao Xiong <mart1n@zju.edu.cn>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ddb013195bfc5c516f6aa2480accf0a6af03a04
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Wed May 19 14:16:14 2021 +0000

    ieee802154: fix error return code in ieee802154_llsec_getparams()
    
    [ Upstream commit 373e864cf52403b0974c2f23ca8faf9104234555 ]
    
    Fix to return negative error code -ENOBUFS from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Link: https://lore.kernel.org/r/20210519141614.3040055-1-weiyongjun1@huawei.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dcf3f8837dd86ef6ff9068696a42b8ae1183fdb
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 14:25:17 2021 +0800

    ieee802154: fix error return code in ieee802154_add_iface()
    
    [ Upstream commit 79c6b8ed30e54b401c873dbad2511f2a1c525fd5 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: be51da0f3e34 ("ieee802154: Stop using NLA_PUT*().")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210508062517.2574-1-thunder.leizhen@huawei.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bae62325a062ae88f0922d1762d0bc1efbf66b57
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri May 28 13:45:16 2021 +0200

    netfilter: nfnetlink_cthelper: hit EBUSY on updates if size mismatches
    
    [ Upstream commit 8971ee8b087750a23f3cd4dc55bff2d0303fd267 ]
    
    The private helper data size cannot be updated. However, updates that
    contain NFCTH_PRIV_DATA_LEN might bogusly hit EBUSY even if the size is
    the same.
    
    Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd010b8ca50fb4414a957bd3f0339eb8692f061f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 14 15:58:50 2021 +0200

    HID: i2c-hid: fix format string mismatch
    
    [ Upstream commit dc5f9f55502e13ba05731d5046a14620aa2ff456 ]
    
    clang doesn't like printing a 32-bit integer using %hX format string:
    
    drivers/hid/i2c-hid/i2c-hid-core.c:994:18: error: format specifies type 'unsigned short' but the argument has type '__u32' (aka 'unsigned int') [-Werror,-Wformat]
                     client->name, hid->vendor, hid->product);
                                   ^~~~~~~~~~~
    drivers/hid/i2c-hid/i2c-hid-core.c:994:31: error: format specifies type 'unsigned short' but the argument has type '__u32' (aka 'unsigned int') [-Werror,-Wformat]
                     client->name, hid->vendor, hid->product);
                                                ^~~~~~~~~~~~
    
    Use an explicit cast to truncate it to the low 16 bits instead.
    
    Fixes: 9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain devices")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9d2aec67fbb3361813f32bb790d92ac794c0671
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 10:47:37 2021 +0800

    HID: pidff: fix error return code in hid_pidff_init()
    
    [ Upstream commit 3dd653c077efda8152f4dd395359617d577a54cd ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24b12c130a7a20f122fd895e10ea665c6b0937a1
Author: Julian Anastasov <ja@ssi.bg>
Date:   Mon May 24 22:54:57 2021 +0300

    ipvs: ignore IP_VS_SVC_F_HASHED flag when adding service
    
    [ Upstream commit 56e4ee82e850026d71223262c07df7d6af3bd872 ]
    
    syzbot reported memory leak [1] when adding service with
    HASHED flag. We should ignore this flag both from sockopt
    and netlink provided data, otherwise the service is not
    hashed and not visible while releasing resources.
    
    [1]
    BUG: memory leak
    unreferenced object 0xffff888115227800 (size 512):
      comm "syz-executor263", pid 8658, jiffies 4294951882 (age 12.560s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff83977188>] kmalloc include/linux/slab.h:556 [inline]
        [<ffffffff83977188>] kzalloc include/linux/slab.h:686 [inline]
        [<ffffffff83977188>] ip_vs_add_service+0x598/0x7c0 net/netfilter/ipvs/ip_vs_ctl.c:1343
        [<ffffffff8397d770>] do_ip_vs_set_ctl+0x810/0xa40 net/netfilter/ipvs/ip_vs_ctl.c:2570
        [<ffffffff838449a8>] nf_setsockopt+0x68/0xa0 net/netfilter/nf_sockopt.c:101
        [<ffffffff839ae4e9>] ip_setsockopt+0x259/0x1ff0 net/ipv4/ip_sockglue.c:1435
        [<ffffffff839fa03c>] raw_setsockopt+0x18c/0x1b0 net/ipv4/raw.c:857
        [<ffffffff83691f20>] __sys_setsockopt+0x1b0/0x360 net/socket.c:2117
        [<ffffffff836920f2>] __do_sys_setsockopt net/socket.c:2128 [inline]
        [<ffffffff836920f2>] __se_sys_setsockopt net/socket.c:2125 [inline]
        [<ffffffff836920f2>] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2125
        [<ffffffff84350efa>] do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
        [<ffffffff84400068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Reported-and-tested-by: syzbot+e562383183e4b1766930@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Reviewed-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80c307771ad702e312106147eea2dfe5a296de8d
Author: Max Gurtovoy <mgurtovoy@nvidia.com>
Date:   Tue May 18 22:21:31 2021 +0300

    vfio/platform: fix module_put call in error flow
    
    [ Upstream commit dc51ff91cf2d1e9a2d941da483602f71d4a51472 ]
    
    The ->parent_module is the one that use in try_module_get. It should
    also be the one the we use in module_put during vfio_platform_open().
    
    Fixes: 32a2d71c4e80 ("vfio: platform: introduce vfio-platform-base module")
    Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Message-Id: <20210518192133.59195-1-mgurtovoy@nvidia.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f48d16bc835261ffb607c61718fd9892629b6552
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat May 15 12:08:56 2021 -0700

    vfio/pci: zap_vma_ptes() needs MMU
    
    [ Upstream commit 2a55ca37350171d9b43d561528f23d4130097255 ]
    
    zap_vma_ptes() is only available when CONFIG_MMU is set/enabled.
    Without CONFIG_MMU, vfio_pci.o has build errors, so make
    VFIO_PCI depend on MMU.
    
    riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `vfio_pci_mmap_open':
    vfio_pci.c:(.text+0x1ec): undefined reference to `zap_vma_ptes'
    riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `.L0 ':
    vfio_pci.c:(.text+0x165c): undefined reference to `zap_vma_ptes'
    
    Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Cornelia Huck <cohuck@redhat.com>
    Cc: kvm@vger.kernel.org
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Cc: Eric Auger <eric.auger@redhat.com>
    Message-Id: <20210515190856.2130-1-rdunlap@infradead.org>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a84e9a33cf960334c3ee6ed03118e7be784d12f
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 15 10:04:58 2021 +0800

    vfio/pci: Fix error return code in vfio_ecap_init()
    
    [ Upstream commit d1ce2c79156d3baf0830990ab06d296477b93c26 ]
    
    The error code returned from vfio_ext_cap_len() is stored in 'len', not
    in 'ret'.
    
    Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Message-Id: <20210515020458.6771-1-thunder.leizhen@huawei.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc0138fa0c1ef6ff795b8b995e39c390f25586b5
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Wed Apr 21 21:46:36 2021 +0200

    efi: cper: fix snprintf() use in cper_dimm_err_location()
    
    [ Upstream commit 942859d969de7f6f7f2659a79237a758b42782da ]
    
    snprintf() should be given the full buffer size, not one less. And it
    guarantees nul-termination, so doing it manually afterwards is
    pointless.
    
    It's even potentially harmful (though probably not in practice because
    CPER_REC_LEN is 256), due to the "return how much would have been
    written had the buffer been big enough" semantics. I.e., if the bank
    and/or device strings are long enough that the "DIMM location ..."
    output gets truncated, writing to msg[n] is a buffer overflow.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Fixes: 3760cd20402d4 ("CPER: Adjust code flow of some functions")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b30423ce2984298df783737fe52e8c69c8982f0
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Fri Apr 30 16:22:51 2021 +0200

    efi: Allow EFI_MEMORY_XP and EFI_MEMORY_RO both to be cleared
    
    [ Upstream commit 45add3cc99feaaf57d4b6f01d52d532c16a1caee ]
    
    UEFI spec 2.9, p.108, table 4-1 lists the scenario that both attributes
    are cleared with the description "No memory access protection is
    possible for Entry". So we can have valid entries where both attributes
    are cleared, so remove the check.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory Attributes table")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7246d9cfe11b818c35bfb6780ef319e3298f0bd2
Author: Grant Grundler <grundler@chromium.org>
Date:   Tue Jan 19 17:12:08 2021 -0800

    net: usb: cdc_ncm: don't spew notifications
    
    [ Upstream commit de658a195ee23ca6aaffe197d1d2ea040beea0a2 ]
    
    RTL8156 sends notifications about every 32ms.
    Only display/log notifications when something changes.
    
    This issue has been reported by others:
            https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832472
            https://lkml.org/lkml/2020/8/27/1083
    
    ...
    [785962.779840] usb 1-1: new high-speed USB device number 5 using xhci_hcd
    [785962.929944] usb 1-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=30.00
    [785962.929949] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
    [785962.929952] usb 1-1: Product: USB 10/100/1G/2.5G LAN
    [785962.929954] usb 1-1: Manufacturer: Realtek
    [785962.929956] usb 1-1: SerialNumber: 000000001
    [785962.991755] usbcore: registered new interface driver cdc_ether
    [785963.017068] cdc_ncm 1-1:2.0: MAC-Address: 00:24:27:88:08:15
    [785963.017072] cdc_ncm 1-1:2.0: setting rx_max = 16384
    [785963.017169] cdc_ncm 1-1:2.0: setting tx_max = 16384
    [785963.017682] cdc_ncm 1-1:2.0 usb0: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, 00:24:27:88:08:15
    [785963.019211] usbcore: registered new interface driver cdc_ncm
    [785963.023856] usbcore: registered new interface driver cdc_wdm
    [785963.025461] usbcore: registered new interface driver cdc_mbim
    [785963.038824] cdc_ncm 1-1:2.0 enx002427880815: renamed from usb0
    [785963.089586] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected
    [785963.121673] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected
    [785963.153682] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected
    ...
    
    This is about 2KB per second and will overwrite all contents of a 1MB
    dmesg buffer in under 10 minutes rendering them useless for debugging
    many kernel problems.
    
    This is also an extra 180 MB/day in /var/logs (or 1GB per week) rendering
    the majority of those logs useless too.
    
    When the link is up (expected state), spew amount is >2x higher:
    ...
    [786139.600992] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected
    [786139.632997] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink
    [786139.665097] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected
    [786139.697100] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink
    [786139.729094] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected
    [786139.761108] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink
    ...
    
    Chrome OS cannot support RTL8156 until this is fixed.
    
    Signed-off-by: Grant Grundler <grundler@chromium.org>
    Reviewed-by: Hayes Wang <hayeswang@realtek.com>
    Link: https://lore.kernel.org/r/20210120011208.3768105-1-grundler@chromium.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>