commit a6ca7c65b1376f7bb14979cb745d3da73c8de948
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 29 12:17:37 2021 +0100

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

commit 311601f114859d586d5ef8833d60d3aa23282161
Author: Rémi Denis-Courmont <remi@remlab.net>
Date:   Sun Dec 19 19:03:39 2021 +0200

    phonet/pep: refuse to enable an unbound pipe
    
    commit 75a2f31520095600f650597c0ac41f48b5ba0068 upstream.
    
    This ioctl() implicitly assumed that the socket was already bound to
    a valid local socket name, i.e. Phonet object. If the socket was not
    bound, two separate problems would occur:
    
    1) We'd send an pipe enablement request with an invalid source object.
    2) Later socket calls could BUG on the socket unexpectedly being
       connected yet not bound to a valid object.
    
    Reported-by: syzbot+2dc91e7fc3dea88b1e8a@syzkaller.appspotmail.com
    Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7b0ae2cc486fcb601f9f9d87d98138cc7b7f7f9
Author: Lin Ma <linma@zju.edu.cn>
Date:   Fri Dec 17 10:13:56 2021 +0800

    hamradio: improve the incomplete fix to avoid NPD
    
    commit b2f37aead1b82a770c48b5d583f35ec22aabb61e upstream.
    
    The previous commit 3e0588c291d6 ("hamradio: defer ax25 kfree after
    unregister_netdev") reorder the kfree operations and unregister_netdev
    operation to prevent UAF.
    
    This commit improves the previous one by also deferring the nullify of
    the ax->tty pointer. Otherwise, a NULL pointer dereference bug occurs.
    Partial of the stack trace is shown below.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000538
    RIP: 0010:ax_xmit+0x1f9/0x400
    ...
    Call Trace:
     dev_hard_start_xmit+0xec/0x320
     sch_direct_xmit+0xea/0x240
     __qdisc_run+0x166/0x5c0
     __dev_queue_xmit+0x2c7/0xaf0
     ax25_std_establish_data_link+0x59/0x60
     ax25_connect+0x3a0/0x500
     ? security_socket_connect+0x2b/0x40
     __sys_connect+0x96/0xc0
     ? __hrtimer_init+0xc0/0xc0
     ? common_nsleep+0x2e/0x50
     ? switch_fpu_return+0x139/0x1a0
     __x64_sys_connect+0x11/0x20
     do_syscall_64+0x33/0x40
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The crash point is shown as below
    
    static void ax_encaps(...) {
      ...
      set_bit(TTY_DO_WRITE_WAKEUP, &ax->tty->flags); // ax->tty = NULL!
      ...
    }
    
    By placing the nullify action after the unregister_netdev, the ax->tty
    pointer won't be assigned as NULL net_device framework layer is well
    synchronized.
    
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaa816a86e629cbcc0a94f38391fee09231628c7
Author: Lin Ma <linma@zju.edu.cn>
Date:   Mon Nov 8 18:37:21 2021 +0800

    hamradio: defer ax25 kfree after unregister_netdev
    
    commit 3e0588c291d6ce225f2b891753ca41d45ba42469 upstream.
    
    There is a possible race condition (use-after-free) like below
    
     (USE)                       |  (FREE)
    ax25_sendmsg                 |
     ax25_queue_xmit             |
      dev_queue_xmit             |
       __dev_queue_xmit          |
        __dev_xmit_skb           |
         sch_direct_xmit         | ...
          xmit_one               |
           netdev_start_xmit     | tty_ldisc_kill
            __netdev_start_xmit  |  mkiss_close
             ax_xmit             |   kfree
              ax_encaps          |
                                 |
    
    Even though there are two synchronization primitives before the kfree:
    1. wait_for_completion(&ax->dead). This can prevent the race with
    routines from mkiss_ioctl. However, it cannot stop the routine coming
    from upper layer, i.e., the ax25_sendmsg.
    
    2. netif_stop_queue(ax->dev). It seems that this line of code aims to
    halt the transmit queue but it fails to stop the routine that already
    being xmit.
    
    This patch reorder the kfree after the unregister_netdev to avoid the
    possible UAF as the unregister_netdev() is well synchronized and won't
    return if there is a running routine.
    
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cccaf8b6f3f8b4b9974fb5dd661dce88f8aa555
Author: Lin Ma <linma@zju.edu.cn>
Date:   Fri Dec 17 10:29:41 2021 +0800

    ax25: NPD bug when detaching AX25 device
    
    commit 1ade48d0c27d5da1ccf4b583d8c5fc8b534a3ac8 upstream.
    
    The existing cleanup routine implementation is not well synchronized
    with the syscall routine. When a device is detaching, below race could
    occur.
    
    static int ax25_sendmsg(...) {
      ...
      lock_sock()
      ax25 = sk_to_ax25(sk);
      if (ax25->ax25_dev == NULL) // CHECK
      ...
      ax25_queue_xmit(skb, ax25->ax25_dev->dev); // USE
      ...
    }
    
    static void ax25_kill_by_device(...) {
      ...
      if (s->ax25_dev == ax25_dev) {
        s->ax25_dev = NULL;
        ...
    }
    
    Other syscall functions like ax25_getsockopt, ax25_getname,
    ax25_info_show also suffer from similar races. To fix them, this patch
    introduce lock_sock() into ax25_kill_by_device in order to guarantee
    that the nullify action in cleanup routine cannot proceed when another
    socket request is pending.
    
    Signed-off-by: Hanjie Wu <nagi@zju.edu.cn>
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0affa7f439107554744c897a945b5c4d2c4cc013
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Dec 3 13:42:22 2021 -0800

    hwmon: (lm90) Do not report 'busy' status bit as alarm
    
    commit cdc5287acad9ede121924a9c9313544b80d15842 upstream.
    
    Bit 7 of the status register indicates that the chip is busy
    doing a conversion. It does not indicate an alarm status.
    Stop reporting it as alarm status bit.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06613a7b3035d5172ed82b59060f222de7fa816e
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Dec 7 19:30:05 2021 +0000

    KVM: VMX: Fix stale docs for kvm-intel.emulate_invalid_guest_state
    
    commit 0ff29701ffad9a5d5a24344d8b09f3af7b96ffda upstream.
    
    Update the documentation for kvm-intel's emulate_invalid_guest_state to
    rectify the description of KVM's default behavior, and to document that
    the behavior and thus parameter only applies to L1.
    
    Fixes: a27685c33acc ("KVM: VMX: Emulate invalid guest state by default")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20211207193006.120997-4-seanjc@google.com>
    Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8e2d2cfefbcd10d24bf8bff653309569e9ecc38
Author: Marian Postevca <posteuca@mutex.one>
Date:   Sat Dec 4 23:49:12 2021 +0200

    usb: gadget: u_ether: fix race in setting MAC address in setup phase
    
    commit 890d5b40908bfd1a79be018d2d297cf9df60f4ee upstream.
    
    When listening for notifications through netlink of a new interface being
    registered, sporadically, it is possible for the MAC to be read as zero.
    The zero MAC address lasts a short period of time and then switches to a
    valid random MAC address.
    
    This causes problems for netd in Android, which assumes that the interface
    is malfunctioning and will not use it.
    
    In the good case we get this log:
    InterfaceController::getCfg() ifName usb0
     hwAddr 92:a8:f0:73:79:5b ipv4Addr 0.0.0.0 flags 0x1002
    
    In the error case we get these logs:
    InterfaceController::getCfg() ifName usb0
     hwAddr 00:00:00:00:00:00 ipv4Addr 0.0.0.0 flags 0x1002
    
    netd : interfaceGetCfg("usb0")
    netd : interfaceSetCfg() -> ServiceSpecificException
     (99, "[Cannot assign requested address] : ioctl() failed")
    
    The reason for the issue is the order in which the interface is setup,
    it is first registered through register_netdev() and after the MAC
    address is set.
    
    Fixed by first setting the MAC address of the net_device and after that
    calling register_netdev().
    
    Fixes: bcd4a1c40bee885e ("usb: gadget: u_ether: construct with default values and add setters/getters")
    Cc: stable@vger.kernel.org
    Signed-off-by: Marian Postevca <posteuca@mutex.one>
    Link: https://lore.kernel.org/r/20211204214912.17627-1-posteuca@mutex.one
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88dedecc24763c2e0bc1e8eeb35f9f2cd785a7e5
Author: Chao Yu <chao@kernel.org>
Date:   Sun Dec 12 17:16:30 2021 +0800

    f2fs: fix to do sanity check on last xattr entry in __f2fs_setxattr()
    
    commit 5598b24efaf4892741c798b425d543e4bed357a1 upstream.
    
    As Wenqing Liu reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=215235
    
    - Overview
    page fault in f2fs_setxattr() when mount and operate on corrupted image
    
    - Reproduce
    tested on kernel 5.16-rc3, 5.15.X under root
    
    1. unzip tmp7.zip
    2. ./single.sh f2fs 7
    
    Sometimes need to run the script several times
    
    - Kernel dump
    loop0: detected capacity change from 0 to 131072
    F2FS-fs (loop0): Found nat_bits in checkpoint
    F2FS-fs (loop0): Mounted with checkpoint version = 7548c2ee
    BUG: unable to handle page fault for address: ffffe47bc7123f48
    RIP: 0010:kfree+0x66/0x320
    Call Trace:
     __f2fs_setxattr+0x2aa/0xc00 [f2fs]
     f2fs_setxattr+0xfa/0x480 [f2fs]
     __f2fs_set_acl+0x19b/0x330 [f2fs]
     __vfs_removexattr+0x52/0x70
     __vfs_removexattr_locked+0xb1/0x140
     vfs_removexattr+0x56/0x100
     removexattr+0x57/0x80
     path_removexattr+0xa3/0xc0
     __x64_sys_removexattr+0x17/0x20
     do_syscall_64+0x37/0xb0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The root cause is in __f2fs_setxattr(), we missed to do sanity check on
    last xattr entry, result in out-of-bound memory access during updating
    inconsistent xattr data of target inode.
    
    After the fix, it can detect such xattr inconsistency as below:
    
    F2FS-fs (loop11): inode (7) has invalid last xattr entry, entry_size: 60676
    F2FS-fs (loop11): inode (8) has corrupted xattr
    F2FS-fs (loop11): inode (8) has corrupted xattr
    F2FS-fs (loop11): inode (8) has invalid last xattr entry, entry_size: 47736
    
    Cc: stable@vger.kernel.org
    Reported-by: Wenqing Liu <wenqingliu0120@gmail.com>
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [delete f2fs_err() call as it's not in older kernels - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 196833e26da9ac9906c24507c1b30b3edd009c3e
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Wed Dec 15 09:31:36 2021 +0100

    ARM: 9169/1: entry: fix Thumb2 bug in iWMMXt exception handling
    
    commit 8536a5ef886005bc443c2da9b842d69fd3d7647f upstream.
    
    The Thumb2 version of the FP exception handling entry code treats the
    register holding the CP number (R8) differently, resulting in the iWMMXT
    CP number check to be incorrect.
    
    Fix this by unifying the ARM and Thumb2 code paths, and switch the
    order of the additions of the TI_USED_CP offset and the shifted CP
    index.
    
    Cc: <stable@vger.kernel.org>
    Fixes: b86040a59feb ("Thumb-2: Implementation of the unified start-up and exceptions code")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5de0b1fa2fab81c762510df642e74acd4e80f53
Author: Fabien Dessenne <fabien.dessenne@foss.st.com>
Date:   Wed Dec 15 10:58:08 2021 +0100

    pinctrl: stm32: consider the GPIO offset to expose all the GPIO lines
    
    commit b67210cc217f9ca1c576909454d846970c13dfd4 upstream.
    
    Consider the GPIO controller offset (from "gpio-ranges") to compute the
    maximum GPIO line number.
    This fixes an issue where gpio-ranges uses a non-null offset.
      e.g.: gpio-ranges = <&pinctrl 6 86 10>
            In that case the last valid GPIO line is not 9 but 15 (6 + 10 - 1)
    
    Cc: stable@vger.kernel.org
    Fixes: 67e2996f72c7 ("pinctrl: stm32: fix the reported number of GPIO lines per bank")
    Reported-by: Christoph Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Fabien Dessenne <fabien.dessenne@foss.st.com>
    Link: https://lore.kernel.org/r/20211215095808.621716-1-fabien.dessenne@foss.st.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27a7e1d9cb36cc0053ced24f894c1cb486a902c0
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Thu Dec 16 00:08:56 2021 +0000

    x86/pkey: Fix undefined behaviour with PKRU_WD_BIT
    
    commit 57690554abe135fee81d6ac33cc94d75a7e224bb upstream.
    
    Both __pkru_allows_write() and arch_set_user_pkey_access() shift
    PKRU_WD_BIT (a signed constant) by up to 30 bits, hitting the
    sign bit.
    
    Use unsigned constants instead.
    
    Clearly pkey 15 has not been used in combination with UBSAN yet.
    
    Noticed by code inspection only.  I can't actually provoke the
    compiler into generating incorrect logic as far as this shift is
    concerned.
    
    [
      dhansen: add stable@ tag, plus minor changelog massaging,
    
               For anyone doing backports, these #defines were in
               arch/x86/include/asm/pgtable.h before 784a46618f6.
    ]
    
    Fixes: 33a709b25a76 ("mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20211216000856.4480-1-andrew.cooper3@citrix.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b75d500fd52481ddfa00d2fc8f9b8318e750c48a
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Sun Dec 12 21:01:49 2021 -0800

    Input: atmel_mxt_ts - fix double free in mxt_read_info_block
    
    commit 12f247ab590a08856441efdbd351cf2cc8f60a2d upstream.
    
    The "id_buf" buffer is stored in "data->raw_info_block" and freed by
    "mxt_free_object_table" in case of error.
    
    Return instead of jumping to avoid a double free.
    
    Addresses-Coverity-ID: 1474582 ("Double free")
    Fixes: 068bdb67ef74 ("Input: atmel_mxt_ts - fix the firmware update")
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>
    Link: https://lore.kernel.org/r/20211212194257.68879-1-jose.exposito89@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e1c179cf8708dd6c53e0b6cb63ca21484d95b0b
Author: Colin Ian King <colin.king@intel.com>
Date:   Sun Dec 12 17:20:25 2021 +0000

    ALSA: drivers: opl3: Fix incorrect use of vp->state
    
    commit 2dee54b289fbc810669a1b2b8a0887fa1c9a14d7 upstream.
    
    Static analysis with scan-build has found an assignment to vp2 that is
    never used. It seems that the check on vp->state > 0 should be actually
    on vp2->state instead. Fix this.
    
    This dates back to 2002, I found the offending commit from the git
    history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git,
    commit 91e39521bbf6 ("[PATCH] ALSA patch for 2.5.4")
    
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211212172025.470367-1-colin.i.king@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c016618c6843c2c7265ae06d0490a98db22d27f9
Author: Xiaoke Wang <xkernel.wang@foxmail.com>
Date:   Mon Dec 13 15:39:31 2021 +0800

    ALSA: jack: Check the return value of kstrdup()
    
    commit c01c1db1dc632edafb0dff32d40daf4f9c1a4e19 upstream.
    
    kstrdup() can return NULL, it is better to check the return value of it.
    
    Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/tencent_094816F3522E0DC704056C789352EBBF0606@qq.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e13a3b81ffa158993d25ffb55ca94d96fa2cd42
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Nov 6 10:02:44 2021 -0700

    hwmon: (lm90) Fix usage of CONFIG2 register in detect function
    
    [ Upstream commit fce15c45d3fbd9fc1feaaf3210d8e3f8b33dfd3a ]
    
    The detect function had a comment "Make compiler happy" when id did not
    read the second configuration register. As it turns out, the code was
    checking the contents of this register for manufacturer ID 0xA1 (NXP
    Semiconductor/Philips), but never actually read the register. So it
    wasn't surprising that the compiler complained, and it indeed had a point.
    Fix the code to read the register contents for manufacturer ID 0xa1.
    
    At the same time, the code was reading the register for manufacturer ID
    0x41 (Analog Devices), but it was not using the results. In effect it was
    just checking if reading the register returned an error. That doesn't
    really add much if any value, so stop doing that.
    
    Fixes: f90be42fb383 ("hwmon: (lm90) Refactor reading of config2 register")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 156e03cf98aa56a3beed09f5c7d50cd1c0225e88
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Mon Dec 20 22:03:44 2021 +0800

    sfc: falcon: Check null pointer of rx_queue->page_ring
    
    [ Upstream commit 9b8bdd1eb5890aeeab7391dddcf8bd51f7b07216 ]
    
    Because of the possible failure of the kcalloc, it should be better to
    set rx_queue->page_ptr_mask to 0 when it happens in order to maintain
    the consistency.
    
    Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Martin Habets <habetsm.xilinx@gmail.com>
    Link: https://lore.kernel.org/r/20211220140344.978408-1-jiasheng@iscas.ac.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b666438be16b2efceb74343c2fbd3503efbeca3
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Wed Dec 22 15:41:12 2021 +0800

    drivers: net: smc911x: Check for error irq
    
    [ Upstream commit cb93b3e11d405f20a405a07482d01147ef4934a3 ]
    
    Because platform_get_irq() could fail and return error irq.
    Therefore, it might be better to check it if order to avoid the use of
    error irq.
    
    Fixes: ae150435b59e ("smsc: Move the SMC (SMSC) drivers")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4c0bb9697cac643dcaec091fb9095acb7435017
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Wed Dec 22 15:12:07 2021 +0800

    fjes: Check for error irq
    
    [ Upstream commit db6d6afe382de5a65d6ccf51253ab48b8e8336c3 ]
    
    I find that platform_get_irq() will not always succeed.
    It will return error irq in case of the failure.
    Therefore, it might be better to check it if order to avoid the use of
    error irq.
    
    Fixes: 658d439b2292 ("fjes: Introduce FUJITSU Extended Socket Network Device driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5d0092bc544f4c391d60661568d98c4c057dd7b
Author: Fernando Fernandez Mancera <ffmancera@riseup.net>
Date:   Tue Dec 21 12:13:45 2021 +0100

    bonding: fix ad_actor_system option setting to default
    
    [ Upstream commit 1c15b05baea71a5ff98235783e3e4ad227760876 ]
    
    When 802.3ad bond mode is configured the ad_actor_system option is set to
    "00:00:00:00:00:00". But when trying to set the all-zeroes MAC as actors'
    system address it was failing with EINVAL.
    
    An all-zeroes ethernet address is valid, only multicast addresses are not
    valid values.
    
    Fixes: 171a42c38c6e ("bonding: add netlink support for sys prio, actor sys mac, and port key")
    Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Link: https://lore.kernel.org/r/20211221111345.2462-1-ffmancera@riseup.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3843ad124e85777a7c039d811aa9b9958da232e
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Dec 20 09:50:27 2021 -0500

    net: skip virtio_net_hdr_set_proto if protocol already set
    
    [ Upstream commit 1ed1d592113959f00cc552c3b9f47ca2d157768f ]
    
    virtio_net_hdr_set_proto infers skb->protocol from the virtio_net_hdr
    gso_type, to avoid packets getting dropped for lack of a proto type.
    
    Its protocol choice is a guess, especially in the case of UFO, where
    the single VIRTIO_NET_HDR_GSO_UDP label covers both UFOv4 and UFOv6.
    
    Skip this best effort if the field is already initialized. Whether
    explicitly from userspace, or implicitly based on an earlier call to
    dev_parse_header_protocol (which is more robust, but was introduced
    after this patch).
    
    Fixes: 9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20211220145027.2784293-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97399eb6cc50b356eadcf5ff7bdbc805a209f94f
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Dec 20 09:49:01 2021 -0500

    net: accept UFOv6 packages in virtio_net_hdr_to_skb
    
    [ Upstream commit 7e5cced9ca84df52d874aca6b632f930b3dc5bc6 ]
    
    Skb with skb->protocol 0 at the time of virtio_net_hdr_to_skb may have
    a protocol inferred from virtio_net_hdr with virtio_net_hdr_set_proto.
    
    Unlike TCP, UDP does not have separate types for IPv4 and IPv6. Type
    VIRTIO_NET_HDR_GSO_UDP is guessed to be IPv4/UDP. As of the below
    commit, UFOv6 packets are dropped due to not matching the protocol as
    obtained from dev_parse_header_protocol.
    
    Invert the test to take that L2 protocol field as starting point and
    pass both UFOv4 and UFOv6 for VIRTIO_NET_HDR_GSO_UDP.
    
    Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct")
    Link: https://lore.kernel.org/netdev/CABcq3pG9GRCYqFDBAJ48H1vpnnX=41u+MhQnayF1ztLH4WX0Fw@mail.gmail.com/
    Reported-by: Andrew Melnichenko <andrew@daynix.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20211220144901.2784030-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96493fd281f8810ed4b330b2016323bc686c83cf
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Dec 17 17:39:11 2021 +0800

    qlcnic: potential dereference null pointer of rx_queue->page_ring
    
    [ Upstream commit 60ec7fcfe76892a1479afab51ff17a4281923156 ]
    
    The return value of kcalloc() needs to be checked.
    To avoid dereference of null pointer in case of the failure of alloc.
    Therefore, it might be better to change the return type of
    qlcnic_sriov_alloc_vlans() and return -ENOMEM when alloc fails and
    return 0 the others.
    Also, qlcnic_sriov_set_guest_vlan_mode() and __qlcnic_pci_sriov_enable()
    should deal with the return value of qlcnic_sriov_alloc_vlans().
    
    Fixes: 154d0c810c53 ("qlcnic: VLAN enhancement for 84XX adapters")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a44aa23f78ef1377bf3ffb09b5b369cc359186ed
Author: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date:   Fri Dec 10 16:31:27 2021 +0100

    netfilter: fix regression in looped (broad|multi)cast's MAC handling
    
    [ Upstream commit ebb966d3bdfed581ecccbb4a7432341baf7619b4 ]
    
    In commit 5648b5e1169f ("netfilter: nfnetlink_queue: fix OOB when mac
    header was cleared"), the test for non-empty MAC header introduced in
    commit 2c38de4c1f8da7 ("netfilter: fix looped (broad|multi)cast's MAC
    handling") has been replaced with a test for a set MAC header.
    
    This breaks the case when the MAC header has been reset (using
    skb_reset_mac_header), as is the case with looped-back multicast
    packets.  As a result, the packets ending up in NFQUEUE get a bogus
    hwaddr interpreted from the first bytes of the IP header.
    
    This patch adds a test for a non-empty MAC header in addition to the
    test for a set MAC header.  The same two tests are also implemented in
    nfnetlink_log.c, where the initial code of commit 2c38de4c1f8da7
    ("netfilter: fix looped (broad|multi)cast's MAC handling") has not been
    touched, but where supposedly the same situation may happen.
    
    Fixes: 5648b5e1169f ("netfilter: nfnetlink_queue: fix OOB when mac header was cleared")
    Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d53456492b5d02033c73dfa0f3b94c86337791ba
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Wed Dec 8 18:52:38 2021 +0100

    IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()
    
    [ Upstream commit bee90911e0138c76ee67458ac0d58b38a3190f65 ]
    
    The wrong goto label was used for the error case and missed cleanup of the
    pkt allocation.
    
    Fixes: d39bf40e55e6 ("IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields")
    Link: https://lore.kernel.org/r/20211208175238.29983-1-jose.exposito89@gmail.com
    Addresses-Coverity-ID: 1493352 ("Resource leak")
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>
    Acked-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bfdba53b01aab4d0306f468bf00c57d8b60020b6
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Mon Dec 6 18:19:31 2021 +0800

    spi: change clk_disable_unprepare to clk_unprepare
    
    [ Upstream commit db6689b643d8653092f5853751ea2cdbc299f8d3 ]
    
    The corresponding API for clk_prepare is clk_unprepare, other than
    clk_disable_unprepare.
    
    Fix this by changing clk_disable_unprepare to clk_unprepare.
    
    Fixes: 5762ab71eb24 ("spi: Add support for Armada 3700 SPI Controller")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Link: https://lore.kernel.org/r/20211206101931.2816597-1-mudongliangabcd@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 641784eb0b4538b958893d5d9ab5cd9461eabdac
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Mon Dec 20 10:51:20 2021 +0100

    HID: holtek: fix mouse probing
    
    commit 93a2207c254ca102ebbdae47b00f19bbfbfa7ecd upstream.
    
    An overlook from the previous commit: we don't even parse or start the
    device, meaning that the device is not presented to user space.
    
    Fixes: 93020953d0fa ("HID: check for valid USB device for many HID drivers")
    Cc: stable@vger.kernel.org
    Link: https://bugs.archlinux.org/task/73048
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215341
    Link: https://lore.kernel.org/r/e4efbf13-bd8d-0370-629b-6c80c0044b15@leemhuis.info/
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5967fc906ec0b044700d057002038a4fc9fbe8f1
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Wed Dec 8 16:21:22 2021 +0100

    can: kvaser_usb: get CAN clock frequency from device
    
    commit fb12797ab1fef480ad8a32a30984844444eeb00d upstream.
    
    The CAN clock frequency is used when calculating the CAN bittiming
    parameters. When wrong clock frequency is used, the device may end up
    with wrong bittiming parameters, depending on user requested bittiming
    parameters.
    
    To avoid this, get the CAN clock frequency from the device. Various
    existing Kvaser Leaf products use different CAN clocks.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Link: https://lore.kernel.org/all/20211208152122.250852-2-extja@kvaser.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82684c3c1ba060705ed7f74a9493a7702a5851fa
Author: Greg Jesionowski <jesionowskigreg@gmail.com>
Date:   Tue Dec 14 15:10:27 2021 -0700

    net: usb: lan78xx: add Allied Telesis AT29M2-AF
    
    commit ef8a0f6eab1ca5d1a75c242c5c7b9d386735fa0a upstream.
    
    This adds the vendor and product IDs for the AT29M2-AF which is a
    lan7801-based device.
    
    Signed-off-by: Greg Jesionowski <jesionowskigreg@gmail.com>
    Link: https://lore.kernel.org/r/20211214221027.305784-1-jesionowskigreg@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>