commit dab08f7eecdfa2ea024dc563dc09afae137e3b38
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 15 08:02:59 2022 +0200

    Linux 6.0.2
    
    Link: https://lore.kernel.org/r/20221013175146.507746257@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Slade Watkins <srw@sladewatkins.net>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Allen Pais <apais@microsoft.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c01739c2aba19553beb20491b05515af9246f0f
Author: Shunsuke Mie <mie@igel.co.jp>
Date:   Wed Sep 7 11:01:00 2022 +0900

    misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic
    
    commit 8e30538eca016de8e252bef174beadecd64239f0 upstream.
    
    The dma_map_single() doesn't permit zero length mapping. It causes a follow
    panic.
    
    A panic was reported on arm64:
    
    [   60.137988] ------------[ cut here ]------------
    [   60.142630] kernel BUG at kernel/dma/swiotlb.c:624!
    [   60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [   60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l
    2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn
    c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl
    [   60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237
    [   60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
    [   60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590
    [   60.213149] lr : swiotlb_map+0x88/0x1f0
    [   60.216982] sp : ffff80000a883bc0
    [   60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000
    [   60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0
    [   60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000
    [   60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000
    [   60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180
    [   60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000
    [   60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
    [   60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000
    [   60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001
    [   60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010
    [   60.291658] Call trace:
    [   60.294100]  swiotlb_tbl_map_single+0x2c0/0x590
    [   60.298629]  swiotlb_map+0x88/0x1f0
    [   60.302115]  dma_map_page_attrs+0x188/0x230
    [   60.306299]  pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test]
    [   60.312660]  __arm64_sys_ioctl+0xa8/0xf0
    [   60.316583]  invoke_syscall+0x44/0x108
    [   60.320334]  el0_svc_common.constprop.0+0xcc/0xf0
    [   60.325038]  do_el0_svc+0x2c/0xb8
    [   60.328351]  el0_svc+0x2c/0x88
    [   60.331406]  el0t_64_sync_handler+0xb8/0xc0
    [   60.335587]  el0t_64_sync+0x18c/0x190
    [   60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000)
    [   60.345344] ---[ end trace 0000000000000000 ]---
    
    To fix it, this patch adds a checking the payload length if it is zero.
    
    Fixes: 343dc693f7b7 ("misc: pci_endpoint_test: Prevent some integer overflows")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Shunsuke Mie <mie@igel.co.jp>
    Link: https://lore.kernel.org/r/20220907020100.122588-2-mie@igel.co.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 579592f2674a9bfcc7c73fa8c9d9f27ab550f646
Author: Shunsuke Mie <mie@igel.co.jp>
Date:   Wed Sep 7 11:00:59 2022 +0900

    misc: pci_endpoint_test: Aggregate params checking for xfer
    
    commit 3e42deaac06567c7e86d287c305ccda24db4ae3d upstream.
    
    Each transfer test functions have same parameter checking code. This patch
    unites those to an introduced function.
    
    Signed-off-by: Shunsuke Mie <mie@igel.co.jp>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20220907020100.122588-1-mie@igel.co.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 605b64a1bffec19e5480a276a1e5de3a92432b3a
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Aug 18 17:44:09 2022 +0200

    Input: xpad - fix wireless 360 controller breaking after suspend
    
    commit a17b9841152e7f4621619902b347e2cc39c32996 upstream.
    
    Suspending and resuming the system can sometimes cause the out
    URB to get hung after a reset_resume. This causes LED setting
    and force feedback to break on resume. To avoid this, just drop
    the reset_resume callback so the USB core rebinds xpad to the
    wireless pads on resume if a reset happened.
    
    A nice side effect of this change is the LED ring on wireless
    controllers is now set correctly on system resume.
    
    Cc: stable@vger.kernel.org
    Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume")
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc3c3feff776fb4cee96614b05990c683d87650a
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Thu Aug 18 17:44:08 2022 +0200

    Input: xpad - add supported devices as contributed on github
    
    commit b382c5e37344883dc97525d05f1f6b788f549985 upstream.
    
    This is based on multiple commits at https://github.com/paroj/xpad
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jasper Poppe <jgpoppe@gmail.com>
    Signed-off-by: Jeremy Palmer <jpalmer@linz.govt.nz>
    Signed-off-by: Ruineka <ruinairas1992@gmail.com>
    Signed-off-by: Cleber de Mattos Casali <clebercasali@gmail.com>
    Signed-off-by: Kyle Gospodnetich <me@kylegospodneti.ch>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c7c84319833259b0bb8c879928700c9e42d6562
Author: Jeremy Kerr <jk@codeconstruct.com.au>
Date:   Wed Oct 12 10:08:51 2022 +0800

    mctp: prevent double key removal and unref
    
    commit 3a732b46736cd8a29092e4b0b1a9ba83e672bf89 upstream.
    
    Currently, we have a bug where a simultaneous DROPTAG ioctl and socket
    close may race, as we attempt to remove a key from lists twice, and
    perform an unref for each removal operation. This may result in a uaf
    when we attempt the second unref.
    
    This change fixes the race by making __mctp_key_remove tolerant to being
    called on a key that has already been removed from the socket/net lists,
    and only performs the unref when we do the actual remove. We also need
    to hold the list lock on the ioctl cleanup path.
    
    This fix is based on a bug report and comprehensive analysis from
    butt3rflyh4ck <butterflyhuangxx@gmail.com>, found via syzkaller.
    
    Cc: stable@vger.kernel.org
    Fixes: 63ed1aab3d40 ("mctp: Add SIOCMCTP{ALLOC,DROP}TAG ioctls for tag control")
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbd8cc654b5bb03ee6c06e2a3cb1bac981a675ad
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 5 23:11:43 2022 +0200

    wifi: cfg80211: update hidden BSSes to avoid WARN_ON
    
    commit c90b93b5b782891ebfda49d4e5da36632fefd5d1 upstream.
    
    When updating beacon elements in a non-transmitted BSS,
    also update the hidden sub-entries to the same beacon
    elements, so that a future update through other paths
    won't trigger a WARN_ON().
    
    The warning is triggered because the beacon elements in
    the hidden BSSes that are children of the BSS should
    always be the same as in the parent.
    
    Reported-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Tested-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ed62f2df8ebcf79c185f1bc3e4f346ea0905da6
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 5 21:24:10 2022 +0200

    wifi: mac80211: fix crash in beacon protection for P2P-device
    
    commit b2d03cabe2b2e150ff5a381731ea0355459be09f upstream.
    
    If beacon protection is active but the beacon cannot be
    decrypted or is otherwise malformed, we call the cfg80211
    API to report this to userspace, but that uses a netdev
    pointer, which isn't present for P2P-Device. Fix this to
    call it only conditionally to ensure cfg80211 won't crash
    in the case of P2P-Device.
    
    This fixes CVE-2022-42722.
    
    Reported-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Fixes: 9eaf183af741 ("mac80211: Report beacon protection failures to user space")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d484f564f49dc7e302f85c9cbc90e72e585e926d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 5 15:10:09 2022 +0200

    wifi: mac80211_hwsim: avoid mac80211 warning on bad rate
    
    commit 1833b6f46d7e2830251a063935ab464256defe22 upstream.
    
    If the tool on the other side (e.g. wmediumd) gets confused
    about the rate, we hit a warning in mac80211. Silence that
    by effectively duplicating the check here and dropping the
    frame silently (in mac80211 it's dropped with the warning).
    
    Reported-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Tested-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 377cb1ce85878c197904ca8383e6b41886e3994d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Oct 1 00:01:44 2022 +0200

    wifi: cfg80211: avoid nontransmitted BSS list corruption
    
    commit bcca852027e5878aec911a347407ecc88d6fff7f upstream.
    
    If a non-transmitted BSS shares enough information (both
    SSID and BSSID!) with another non-transmitted BSS of a
    different AP, then we can find and update it, and then
    try to add it to the non-transmitted BSS list. We do a
    search for it on the transmitted BSS, but if it's not
    there (but belongs to another transmitted BSS), the list
    gets corrupted.
    
    Since this is an erroneous situation, simply fail the
    list insertion in this case and free the non-transmitted
    BSS.
    
    This fixes CVE-2022-42721.
    
    Reported-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Tested-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e97a5d7091e6d2df05f8378a518a9bbf81688b77
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Sep 30 23:44:23 2022 +0200

    wifi: cfg80211: fix BSS refcounting bugs
    
    commit 0b7808818cb9df6680f98996b8e9a439fa7bcc2f upstream.
    
    There are multiple refcounting bugs related to multi-BSSID:
     - In bss_ref_get(), if the BSS has a hidden_beacon_bss, then
       the bss pointer is overwritten before checking for the
       transmitted BSS, which is clearly wrong. Fix this by using
       the bss_from_pub() macro.
    
     - In cfg80211_bss_update() we copy the transmitted_bss pointer
       from tmp into new, but then if we release new, we'll unref
       it erroneously. We already set the pointer and ref it, but
       need to NULL it since it was copied from the tmp data.
    
     - In cfg80211_inform_single_bss_data(), if adding to the non-
       transmitted list fails, we unlink the BSS and yet still we
       return it, but this results in returning an entry without
       a reference. We shouldn't return it anyway if it was broken
       enough to not get added there.
    
    This fixes CVE-2022-42720.
    
    Reported-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Tested-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Fixes: a3584f56de1c ("cfg80211: Properly track transmitting and non-transmitting BSS")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8820e70f0ad84f6443ff5ad0f9b463a620116579
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Sep 29 21:50:44 2022 +0200

    wifi: cfg80211: ensure length byte is present before access
    
    commit 567e14e39e8f8c6997a1378bc3be615afca86063 upstream.
    
    When iterating the elements here, ensure the length byte is
    present before checking it to see if the entire element will
    fit into the buffer.
    
    Longer term, we should rewrite this code using the type-safe
    element iteration macros that check all of this.
    
    Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
    Reported-by: Soenke Huster <shuster@seemoo.tu-darmstadt.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4afcb8886800131f8dd58d82754ee0c508303d46
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Sep 28 22:07:15 2022 +0200

    wifi: mac80211: fix MBSSID parsing use-after-free
    
    commit ff05d4b45dd89b922578dac497dcabf57cf771c6 upstream.
    
    When we parse a multi-BSSID element, we might point some
    element pointers into the allocated nontransmitted_profile.
    However, we free this before returning, causing UAF when the
    relevant pointers in the parsed elements are accessed.
    
    Fix this by not allocating the scratch buffer separately but
    as part of the returned structure instead, that way, there
    are no lifetime issues with it.
    
    The scratch buffer introduction as part of the returned data
    here is taken from MLO feature work done by Ilan.
    
    This fixes CVE-2022-42719.
    
    Fixes: 5023b14cf4df ("mac80211: support profile split between elements")
    Co-developed-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4609a23ce88b5b1bde2a03a96c03df19fac18e7b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Sep 28 22:01:37 2022 +0200

    wifi: cfg80211/mac80211: reject bad MBSSID elements
    
    commit 8f033d2becc24aa6bfd2a5c104407963560caabc upstream.
    
    Per spec, the maximum value for the MaxBSSID ('n') indicator is 8,
    and the minimum is 1 since a multiple BSSID set with just one BSSID
    doesn't make sense (the # of BSSIDs is limited by 2^n).
    
    Limit this in the parsing in both cfg80211 and mac80211, rejecting
    any elements with an invalid value.
    
    This fixes potentially bad shifts in the processing of these inside
    the cfg80211_gen_new_bssid() function later.
    
    I found this during the investigation of CVE-2022-41674 fixed by the
    previous patch.
    
    Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
    Fixes: 78ac51f81532 ("mac80211: support multi-bssid")
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc1ed6d0c9898a68da7f1f7843560dfda57683e2
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Sep 28 21:56:15 2022 +0200

    wifi: cfg80211: fix u8 overflow in cfg80211_update_notlisted_nontrans()
    
    commit aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d upstream.
    
    In the copy code of the elements, we do the following calculation
    to reach the end of the MBSSID element:
    
            /* copy the IEs after MBSSID */
            cpy_len = mbssid[1] + 2;
    
    This looks fine, however, cpy_len is a u8, the same as mbssid[1],
    so the addition of two can overflow. In this case the subsequent
    memcpy() will overflow the allocated buffer, since it copies 256
    bytes too much due to the way the allocation and memcpy() sizes
    are calculated.
    
    Fix this by using size_t for the cpy_len variable.
    
    This fixes CVE-2022-41674.
    
    Reported-by: Soenke Huster <shuster@seemoo.tu-darmstadt.de>
    Tested-by: Soenke Huster <shuster@seemoo.tu-darmstadt.de>
    Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a232bc42e1b746fef4a821459dc44643f16bad51
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Sep 22 18:46:04 2022 +0200

    random: use expired timer rather than wq for mixing fast pool
    
    commit 748bc4dd9e663f23448d8ad7e58c011a67ea1eca upstream.
    
    Previously, the fast pool was dumped into the main pool periodically in
    the fast pool's hard IRQ handler. This worked fine and there weren't
    problems with it, until RT came around. Since RT converts spinlocks into
    sleeping locks, problems cropped up. Rather than switching to raw
    spinlocks, the RT developers preferred we make the transformation from
    originally doing:
    
        do_some_stuff()
        spin_lock()
        do_some_other_stuff()
        spin_unlock()
    
    to doing:
    
        do_some_stuff()
        queue_work_on(some_other_stuff_worker)
    
    This is an ordinary pattern done all over the kernel. However, Sherry
    noticed a 10% performance regression in qperf TCP over a 40gbps
    InfiniBand card. Quoting her message:
    
    > MT27500 Family [ConnectX-3] cards:
    > Infiniband device 'mlx4_0' port 1 status:
    > default gid: fe80:0000:0000:0000:0010:e000:0178:9eb1
    > base lid: 0x6
    > sm lid: 0x1
    > state: 4: ACTIVE
    > phys state: 5: LinkUp
    > rate: 40 Gb/sec (4X QDR)
    > link_layer: InfiniBand
    >
    > Cards are configured with IP addresses on private subnet for IPoIB
    > performance testing.
    > Regression identified in this bug is in TCP latency in this stack as reported
    > by qperf tcp_lat metric:
    >
    > We have one system listen as a qperf server:
    > [root@yourQperfServer ~]# qperf
    >
    > Have the other system connect to qperf server as a client (in this
    > case, it’s X7 server with Mellanox card):
    > [root@yourQperfClient ~]# numactl -m0 -N0 qperf 20.20.20.101 -v -uu -ub --time 60 --wait_server 20 -oo msg_size:4K:1024K:*2 tcp_lat
    
    Rather than incur the scheduling latency from queue_work_on, we can
    instead switch to running on the next timer tick, on the same core. This
    also batches things a bit more -- once per jiffy -- which is okay now
    that mix_interrupt_randomness() can credit multiple bits at once.
    
    Reported-by: Sherry Yang <sherry.yang@oracle.com>
    Tested-by: Paul Webb <paul.x.webb@oracle.com>
    Cc: Sherry Yang <sherry.yang@oracle.com>
    Cc: Phillip Goerl <phillip.goerl@oracle.com>
    Cc: Jack Vogel <jack.vogel@oracle.com>
    Cc: Nicky Veitch <nicky.veitch@oracle.com>
    Cc: Colm Harrington <colm.harrington@oracle.com>
    Cc: Ramanan Govindarajan <ramanan.govindarajan@oracle.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Sultan Alsawaf <sultan@kerneltoast.com>
    Cc: stable@vger.kernel.org
    Fixes: 58340f8e952b ("random: defer fast pool mixing to worker")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0b13483ee942b76350afeddd8131285cf4d3de2
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Sep 22 18:46:04 2022 +0200

    random: avoid reading two cache lines on irq randomness
    
    commit 9ee0507e896b45af6d65408c77815800bce30008 upstream.
    
    In order to avoid reading and dirtying two cache lines on every IRQ,
    move the work_struct to the bottom of the fast_pool struct. add_
    interrupt_randomness() always touches .pool and .count, which are
    currently split, because .mix pushes everything down. Instead, move .mix
    to the bottom, so that .pool and .count are always in the first cache
    line, since .mix is only accessed when the pool is full.
    
    Fixes: 58340f8e952b ("random: defer fast pool mixing to worker")
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bb860b8d4fcaebcde22a745e6714adfddf58773
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Fri Sep 9 11:49:13 2022 +0100

    Revert "crypto: qat - reduce size of mapped region"
    
    commit 9c5f21b198d259bfe1191b1fedf08e2eab15b33b upstream.
    
    This reverts commit e48767c17718067ba21fb2ef461779ec2506f845.
    
    In an attempt to resolve a set of warnings reported by the static
    analyzer Smatch, the reverted commit improperly reduced the sizes of the
    DMA mappings used for the input and output parameters for both RSA and
    DH creating a mismatch (map size=8 bytes, unmap size=64 bytes).
    
    This issue is reported when CONFIG_DMA_API_DEBUG is selected, when the
    crypto self test is run. The function dma_unmap_single() reports a
    warning similar to the one below, saying that the `device driver frees
    DMA memory with different size`.
    
        DMA-API: 4xxx 0000:06:00.0: device driver frees DMA memory with different size [device address=0x0000000123206c80] [map size=8 bytes] [unmap size=64 bytes]
        WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:973 check_unmap+0x3d0/0x8c0\
        ...
        Call Trace:
        <IRQ>
        debug_dma_unmap_page+0x5c/0x60
        qat_dh_cb+0xd7/0x110 [intel_qat]
        qat_alg_asym_callback+0x1a/0x30 [intel_qat]
        adf_response_handler+0xbd/0x1a0 [intel_qat]
        tasklet_action_common.constprop.0+0xcd/0xe0
        __do_softirq+0xf8/0x30c
        __irq_exit_rcu+0xbf/0x140
        common_interrupt+0xb9/0xd0
        </IRQ>
        <TASK>
    
    The original commit was correct.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e471bc03f89ea81bebc1d8dc90de7cb0a8ec8e19
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Wed Sep 7 17:01:11 2022 -0500

    Revert "powerpc/rtas: Implement reentrant rtas call"
    
    commit f88aabad33ea22be2ce1c60d8901942e4e2a9edb upstream.
    
    At the time this was submitted by Leonardo, I confirmed -- or thought
    I had confirmed -- with PowerVM partition firmware development that
    the following RTAS functions:
    
    - ibm,get-xive
    - ibm,int-off
    - ibm,int-on
    - ibm,set-xive
    
    were safe to call on multiple CPUs simultaneously, not only with
    respect to themselves as indicated by PAPR, but with arbitrary other
    RTAS calls:
    
    https://lore.kernel.org/linuxppc-dev/875zcy2v8o.fsf@linux.ibm.com/
    
    Recent discussion with firmware development makes it clear that this
    is not true, and that the code in commit b664db8e3f97 ("powerpc/rtas:
    Implement reentrant rtas call") is unsafe, likely explaining several
    strange bugs we've seen in internal testing involving DLPAR and
    LPM. These scenarios use ibm,configure-connector, whose internal state
    can be corrupted by the concurrent use of the "reentrant" functions,
    leading to symptoms like endless busy statuses from RTAS.
    
    Fixes: b664db8e3f97 ("powerpc/rtas: Implement reentrant rtas call")
    Cc: stable@vger.kernel.org # v5.8+
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Laurent Dufour <laurent.dufour@fr.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220907220111.223267-1-nathanl@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53c2e5d5b5ca92b06c02b5461f555181d56484be
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Sep 27 18:53:32 2022 +0300

    Revert "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"
    
    commit 7a84e7353e23202d4f82b05093af4db2b26e6768 upstream.
    
    This reverts commit 0f01017191384e3962fa31520a9fd9846c3d352f.
    
    As pointed out by Ferry this breaks Dual Role support on
    Intel Merrifield platforms.
    
    Fixes: 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present")
    Reported-by: Ferry Toth <fntoth@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Tested-by: Ferry Toth <fntoth@gmail.com> # for Merrifield
    Reviewed-by: Sven Peter <sven@svenpeter.dev>
    Link: https://lore.kernel.org/r/20220927155332.10762-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26e0a333a84be981e8ff079740d9e31c8747e9dd
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Sep 27 18:53:31 2022 +0300

    Revert "USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present""
    
    commit 2adc960ce79d3231b02f820daeee434542fe2911 upstream.
    
    This reverts commit 8bd6b8c4b1009d7d2662138d6bdc6fe58a9274c5.
    
    Prerequisite revert for the reverting of the original commit 0f0101719138.
    
    Fixes: 8bd6b8c4b100 ("USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"")
    Fixes: 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present")
    Reported-by: Ferry Toth <fntoth@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Tested-by: Ferry Toth <fntoth@gmail.com> # for Merrifield
    Link: https://lore.kernel.org/r/20220927155332.10762-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59f29f77c9b6b151abf25adee48da94d4dd9d104
Author: Frank Wunderlich <frank-w@public-files.de>
Date:   Mon Sep 26 17:07:39 2022 +0200

    USB: serial: qcserial: add new usb-id for Dell branded EM7455
    
    commit eee48781ea199e32c1d0c4732641c494833788ca upstream.
    
    Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2.
    
    Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9b7369d89924a366b20045dc26dc4dc6b0567a4
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 9 08:54:47 2022 +0200

    scsi: stex: Properly zero out the passthrough command structure
    
    commit 6022f210461fef67e6e676fd8544ca02d1bcfa7a upstream.
    
    The passthrough structure is declared off of the stack, so it needs to be
    set to zero before copied back to userspace to prevent any unintentional
    data leakage.  Switch things to be statically allocated which will fill the
    unused fields with 0 automatically.
    
    Link: https://lore.kernel.org/r/YxrjN3OOw2HHl9tx@kroah.com
    Cc: stable@kernel.org
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Reported-by: hdthky <hdthky0@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f22520a2136ad12b228c0b33435732e0899589b1
Author: Arun Easi <aeasi@marvell.com>
Date:   Fri Aug 26 03:25:54 2022 -0700

    scsi: qla2xxx: Fix response queue handler reading stale packets
    
    commit e4f8a29deb3ba30e414dfb6b09e3ae3bf6dbe74a upstream.
    
    On some platforms, the current logic of relying on finding new packet
    solely based on signature pattern can lead to driver reading stale
    packets. Though this is a bug in those platforms, reduce such exposures by
    limiting reading packets until the IN pointer.
    
    Link: https://lore.kernel.org/r/20220826102559.17474-3-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit add6d15e3d02b647165fc81e5aced4b3c911133b
Author: Arun Easi <aeasi@marvell.com>
Date:   Fri Aug 26 03:25:53 2022 -0700

    scsi: qla2xxx: Revert "scsi: qla2xxx: Fix response queue handler reading stale packets"
    
    commit 6dc45a7322cb9db48a5b6696597a00ef7c778ef9 upstream.
    
    Reverting this commit so that a fixed up patch, without adding new module
    parameters, can be submitted.
    
        Link: https://lore.kernel.org/stable/166039743723771@kroah.com/
    
    This reverts commit b1f707146923335849fb70237eec27d4d1ae7d62.
    
    Link: https://lore.kernel.org/r/20220826102559.17474-2-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16c0b849ebd4d89b0d1b4802ff74fb533f9cf0e3
Author: Orlando Chamberlain <redecorating@protonmail.com>
Date:   Thu Sep 29 11:49:56 2022 +0000

    efi: Correct Macmini DMI match in uefi cert quirk
    
    commit bab715bdaa9ebf28d99a6d1efb2704a30125e96d upstream.
    
    It turns out Apple doesn't capitalise the "mini" in "Macmini" in DMI, which
    is inconsistent with other model line names.
    
    Correct the capitalisation of Macmini in the quirk for skipping loading
    platform certs on T2 Macs.
    
    Currently users get:
    
    ------------[ cut here ]------------
    [Firmware Bug]: Page fault caused by firmware at PA: 0xffffa30640054000
    WARNING: CPU: 1 PID: 8 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x55/0xe0
    Modules linked in:
    CPU: 1 PID: 8 Comm: kworker/u12:0 Not tainted 5.18.14-arch1-2-t2 #1 4535eb3fc40fd08edab32a509fbf4c9bc52d111e
    Hardware name: Apple Inc. Macmini8,1/Mac-7BA5B2DFE22DDD8C, BIOS 1731.120.10.0.0 (iBridge: 19.16.15071.0.0,0) 04/24/2022
    Workqueue: efi_rts_wq efi_call_rts
    ...
    ---[ end trace 0000000000000000 ]---
    efi: Froze efi_rts_wq and disabled EFI Runtime Services
    integrity: Couldn't get size: 0x8000000000000015
    integrity: MODSIGN: Couldn't get UEFI db list
    efi: EFI Runtime Services are disabled!
    integrity: Couldn't get size: 0x8000000000000015
    integrity: Couldn't get UEFI dbx list
    
    Fixes: 155ca952c7ca ("efi: Do not import certificates from UEFI Secure Boot for T2 Macs")
    Cc: stable@vger.kernel.org
    Cc: Aditya Garg <gargaditya08@live.com>
    Tested-by: Samuel Jiang <chyishian.jiang@gmail.com>
    Signed-off-by: Orlando Chamberlain <redecorating@protonmail.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5b4ed9bec58ecb21d88e2ae6f9bb55661e10ec6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 29 08:14:55 2022 +0200

    ALSA: hda/realtek: Add quirk for HP Zbook Firefly 14 G9 model
    
    commit 225f6e1bc151978041595c7d2acaded3aac41f54 upstream.
    
    HP Zbook Firefly 14 G9 model (103c:8abb) requires yet another binding
    with CS35L41 codec, but with a slightly different configuration.  It's
    over spi1 instead of spi0.  Create a new fixup entry for that.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220929061455.13355-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0aba8959aa922c12c6df86785d8c12707face3d6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Oct 1 16:21:24 2022 +0200

    ALSA: hda: Fix position reporting on Poulsbo
    
    commit 56e696c0f0c71b77fff921fc94b58a02f0445b2c upstream.
    
    Hans reported that his Sony VAIO VPX11S1E showed the broken sound
    behavior at the start of the stream for a couple of seconds, and it
    turned out that the position_fix=1 option fixes the issue.  It implies
    that the position reporting is inaccurate, and very likely hitting on
    all Poulsbo devices.
    
    The patch applies the workaround for Poulsbo generically to switch to
    LPIB mode instead of the default position buffer.
    
    Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/3e8697e1-87c6-7a7b-d2e8-b21f1d2f181b@redhat.com
    Link: https://lore.kernel.org/r/20221001142124.7241-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4f5b6cf3e1db05560a1f0d157d695401dd16804
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Sep 23 02:42:51 2022 +0200

    random: clamp credited irq bits to maximum mixed
    
    commit e78a802a7b4febf53f2a92842f494b01062d85a8 upstream.
    
    Since the most that's mixed into the pool is sizeof(long)*2, don't
    credit more than that many bytes of entropy.
    
    Fixes: e3e33fc2ea7f ("random: do not use input pool from hard IRQs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3dbb621eed976d4427a1ddd88967cc48d930987
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Sep 8 16:14:00 2022 +0200

    random: restore O_NONBLOCK support
    
    commit cd4f24ae9404fd31fc461066e57889be3b68641b upstream.
    
    Prior to 5.6, when /dev/random was opened with O_NONBLOCK, it would
    return -EAGAIN if there was no entropy. When the pools were unified in
    5.6, this was lost. The post 5.6 behavior of blocking until the pool is
    initialized, and ignoring O_NONBLOCK in the process, went unnoticed,
    with no reports about the regression received for two and a half years.
    However, eventually this indeed did break somebody's userspace.
    
    So we restore the old behavior, by returning -EAGAIN if the pool is not
    initialized. Unlike the old /dev/random, this can only occur during
    early boot, after which it never blocks again.
    
    In order to make this O_NONBLOCK behavior consistent with other
    expectations, also respect users reading with preadv2(RWF_NOWAIT) and
    similar.
    
    Fixes: 30c08efec888 ("random: make /dev/random be almost like /dev/urandom")
    Reported-by: Guozihua <guozihua@huawei.com>
    Reported-by: Zhongguohua <zhongguohua1@huawei.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Andrew Lutomirski <luto@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d70af8676a7c6cd8c3a2022e33530e14bd0cd7b
Author: Rishabh Bhatnagar <risbhat@amazon.com>
Date:   Tue Sep 20 19:19:32 2022 +0000

    nvme-pci: set min_align_mask before calculating max_hw_sectors
    
    commit 61ce339f19fabbc3e51237148a7ef6f2270e44fa upstream.
    
    If swiotlb is force enabled dma_max_mapping_size ends up calling
    swiotlb_max_mapping_size which takes into account the min align mask for
    the device.  Set the min align mask for nvme driver before calling
    dma_max_mapping_size while calculating max hw sectors.
    
    Signed-off-by: Rishabh Bhatnagar <risbhat@amazon.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c0776b5bc31de7cd28afb558fae37a20f33602e
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Sep 29 21:33:30 2022 +0900

    nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure
    
    commit 723ac751208f6d6540191689cfbf6c77135a7a1b upstream.
    
    If creation or finalization of a checkpoint fails due to anomalies in the
    checkpoint metadata on disk, a kernel warning is generated.
    
    This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted
    with panic_on_warn, does not panic.  A nilfs_error is appropriate here to
    handle the abnormal filesystem condition.
    
    This also replaces the detected error codes with an I/O error so that
    neither of the internal error codes is returned to callers.
    
    Link: https://lkml.kernel.org/r/20220929123330.19658-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+fbb3e0b24e8dae5a16ee@syzkaller.appspotmail.com
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dc48a360e7b6bb16c48625f8f80ab7665bc9648
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Fri Oct 7 17:52:26 2022 +0900

    nilfs2: fix leak of nilfs_root in case of writer thread creation failure
    
    commit d0d51a97063db4704a5ef6bc978dddab1636a306 upstream.
    
    If nilfs_attach_log_writer() failed to create a log writer thread, it
    frees a data structure of the log writer without any cleanup.  After
    commit e912a5b66837 ("nilfs2: use root object to get ifile"), this causes
    a leak of struct nilfs_root, which started to leak an ifile metadata inode
    and a kobject on that struct.
    
    In addition, if the kernel is booted with panic_on_warn, the above
    ifile metadata inode leak will cause the following panic when the
    nilfs2 kernel module is removed:
    
      kmem_cache_destroy nilfs2_inode_cache: Slab cache still has objects when
      called from nilfs_destroy_cachep+0x16/0x3a [nilfs2]
      WARNING: CPU: 8 PID: 1464 at mm/slab_common.c:494 kmem_cache_destroy+0x138/0x140
      ...
      RIP: 0010:kmem_cache_destroy+0x138/0x140
      Code: 00 20 00 00 e8 a9 55 d8 ff e9 76 ff ff ff 48 8b 53 60 48 c7 c6 20 70 65 86 48 c7 c7 d8 69 9c 86 48 8b 4c 24 28 e8 ef 71 c7 00 <0f> 0b e9 53 ff ff ff c3 48 81 ff ff 0f 00 00 77 03 31 c0 c3 53 48
      ...
      Call Trace:
       <TASK>
       ? nilfs_palloc_freev.cold.24+0x58/0x58 [nilfs2]
       nilfs_destroy_cachep+0x16/0x3a [nilfs2]
       exit_nilfs_fs+0xa/0x1b [nilfs2]
        __x64_sys_delete_module+0x1d9/0x3a0
       ? __sanitizer_cov_trace_pc+0x1a/0x50
       ? syscall_trace_enter.isra.19+0x119/0x190
       do_syscall_64+0x34/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
       ...
       </TASK>
      Kernel panic - not syncing: panic_on_warn set ...
    
    This patch fixes these issues by calling nilfs_detach_log_writer() cleanup
    function if spawning the log writer thread fails.
    
    Link: https://lkml.kernel.org/r/20221007085226.57667-1-konishi.ryusuke@gmail.com
    Fixes: e912a5b66837 ("nilfs2: use root object to get ifile")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+7381dc4ad60658ca4c05@syzkaller.appspotmail.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6251c9c0430d70cc221d0bb907b278bd99d7b066
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Tue Oct 4 00:05:19 2022 +0900

    nilfs2: fix use-after-free bug of struct nilfs_root
    
    commit d325dc6eb763c10f591c239550b8c7e5466a5d09 upstream.
    
    If the beginning of the inode bitmap area is corrupted on disk, an inode
    with the same inode number as the root inode can be allocated and fail
    soon after.  In this case, the subsequent call to nilfs_clear_inode() on
    that bogus root inode will wrongly decrement the reference counter of
    struct nilfs_root, and this will erroneously free struct nilfs_root,
    causing kernel oopses.
    
    This fixes the problem by changing nilfs_new_inode() to skip reserved
    inode numbers while repairing the inode bitmap.
    
    Link: https://lkml.kernel.org/r/20221003150519.39789-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+b8c672b0e22615c80fe0@syzkaller.appspotmail.com
    Reported-by: Khalid Masum <khalid.masum.92@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 037e760a4a009e9545a51e87c98c22d9aaf32df7
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Oct 2 12:08:04 2022 +0900

    nilfs2: fix NULL pointer dereference at nilfs_bmap_lookup_at_level()
    
    commit 21a87d88c2253350e115029f14fe2a10a7e6c856 upstream.
    
    If the i_mode field in inode of metadata files is corrupted on disk, it
    can cause the initialization of bmap structure, which should have been
    called from nilfs_read_inode_common(), not to be called.  This causes a
    lockdep warning followed by a NULL pointer dereference at
    nilfs_bmap_lookup_at_level().
    
    This patch fixes these issues by adding a missing sanitiy check for the
    i_mode field of metadata file's inode.
    
    Link: https://lkml.kernel.org/r/20221002030804.29978-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+2b32eb36c1a825b7a74c@syzkaller.appspotmail.com
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>