Linux 5.10.166

 
affs: initialize fsdata in affs_truncate() [+ + +]
Author: Alexander Potapenko <glider@google.com>
Date:   Tue Jan 10 13:49:30 2023 +0100

    affs: initialize fsdata in affs_truncate()
    
    [ Upstream commit eef034ac6690118c88f357b00e2b3239c9d8575d ]
    
    When aops->write_begin() does not initialize fsdata, KMSAN may report
    an error passing the latter to aops->write_end().
    
    Fix this by unconditionally initializing fsdata.
    
    Fixes: f2b6a16eb8f5 ("fs: affs convert to new aops")
    Suggested-by: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amd-xgbe: Delay AN timeout during KR training [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Jan 11 22:58:52 2023 +0530

    amd-xgbe: Delay AN timeout during KR training
    
    [ Upstream commit 926446ae24c03311a480fb96eb78f0ce7ea6d091 ]
    
    AN restart triggered during KR training not only aborts the KR training
    process but also move the HW to unstable state. Driver has to wait upto
    500ms or until the KR training is completed before restarting AN cycle.
    
    Fixes: 7c12aa08779c ("amd-xgbe: Move the PHY support into amd-xgbe")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

amd-xgbe: TX Flow Ctrl Registers are h/w ver dependent [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Jan 11 22:58:51 2023 +0530

    amd-xgbe: TX Flow Ctrl Registers are h/w ver dependent
    
    [ Upstream commit 579923d84b04abb6cd4cd1fd9974096a2dd1832b ]
    
    There is difference in the TX Flow Control registers (TFCR) between the
    revisions of the hardware. The older revisions of hardware used to have
    single register per queue. Whereas, the newer revision of hardware (from
    ver 30H onwards) have one register per priority.
    
    Update the driver to use the TFCR based on the reported version of the
    hardware.
    
    Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver")
    Co-developed-by: Ajith Nayak <Ajith.Nayak@amd.com>
    Signed-off-by: Ajith Nayak <Ajith.Nayak@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: imx8mm-beacon: Fix ecspi2 pinmux [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Fri Dec 2 13:10:37 2022 -0600

    arm64: dts: imx8mm-beacon: Fix ecspi2 pinmux
    
    [ Upstream commit 5225ba9db112ec4ed67da5e4d8b72e618573955e ]
    
    Early hardware did not support hardware handshaking on the UART, but
    final production hardware did.  When the hardware was updated the chip
    select was changed to facilitate hardware handshaking on UART3.  Fix the
    ecspi2 pin mux to eliminate a pin conflict with UART3 and allow the
    EEPROM to operate again.
    
    Fixes: 4ce01ce36d77 ("arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: 9280/1: mm: fix warning on phys_addr_t to void pointer assignment [+ + +]
Author: Giulio Benetti <giulio.benetti@benettiengineering.com>
Date:   Tue Dec 13 20:24:03 2022 +0100

    ARM: 9280/1: mm: fix warning on phys_addr_t to void pointer assignment
    
    commit a4e03921c1bb118e6718e0a3b0322a2c13ed172b upstream.
    
    zero_page is a void* pointer but memblock_alloc() returns phys_addr_t type
    so this generates a warning while using clang and with -Wint-error enabled
    that becomes and error. So let's cast the return of memblock_alloc() to
    (void *).
    
    Cc: <stable@vger.kernel.org> # 4.14.x +
    Fixes: 340a982825f7 ("ARM: 9266/1: mm: fix no-MMU ZERO_PAGE() implementation")
    Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: at91: sam9x60: fix the ddr clock for sam9x60 [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Dec 8 13:52:41 2022 +0200

    ARM: dts: at91: sam9x60: fix the ddr clock for sam9x60
    
    [ Upstream commit 9bfa2544dbd1133f0b0af4e967de3bb9c1e3a497 ]
    
    The 2nd DDR clock for sam9x60 DDR controller is peripheral clock with
    id 49.
    
    Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20221208115241.36312-1-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6qdl-gw560x: Remove incorrect 'uart-has-rtscts' [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 17:22:59 2022 -0300

    ARM: dts: imx6qdl-gw560x: Remove incorrect 'uart-has-rtscts'
    
    [ Upstream commit 9dfbc72256b5de608ad10989bcbafdbbd1ac8d4e ]
    
    The following build warning is seen when running:
    
    make dtbs_check DT_SCHEMA_FILES=fsl-imx-uart.yaml
    
    arch/arm/boot/dts/imx6dl-gw560x.dtb: serial@2020000: rts-gpios: False schema does not allow [[20, 1, 0]]
            From schema: Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
    
    The imx6qdl-gw560x board does not expose the UART RTS and CTS
    as native UART pins, so 'uart-has-rtscts' should not be used.
    
    Using 'uart-has-rtscts' with 'rts-gpios' is an invalid combination
    detected by serial.yaml.
    
    Fix the problem by removing the incorrect 'uart-has-rtscts' property.
    
    Fixes: b8a559feffb2 ("ARM: dts: imx: add Gateworks Ventana GW5600 support")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Acked-by: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul-pico-dwarf: Use 'clock-frequency' [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 13:31:23 2022 -0300

    ARM: dts: imx6ul-pico-dwarf: Use 'clock-frequency'
    
    [ Upstream commit 94e2cf1e0db5b06c7a6ae0878c5cbec925819a8a ]
    
    'clock_frequency' is not a valid property.
    
    Use the correct 'clock-frequency' instead.
    
    Fixes: 47246fafef84 ("ARM: dts: imx6ul-pico: Add support for the dwarf baseboard")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx7d-pico: Use 'clock-frequency' [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 13:31:24 2022 -0300

    ARM: dts: imx7d-pico: Use 'clock-frequency'
    
    [ Upstream commit f4dd0845c4f1f5371f1e06fef0e4a1734a2db964 ]
    
    'clock_frequency' is not a valid property.
    
    Use the correct 'clock-frequency' instead.
    
    Fixes: 8b646cfb84c3 ("ARM: dts: imx7d-pico: Add support for the dwarf baseboard")
    Fixes: 6418fd92417f ("ARM: dts: imx7d-pico: Add support for the nymph baseboard")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: imx: add missing of_node_put() [+ + +]
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Thu Dec 8 17:54:03 2022 +0100

    ARM: imx: add missing of_node_put()
    
    [ Upstream commit 87b30c4b0efb6a194a7b8eac2568a3da520d905f ]
    
    Calling of_find_compatible_node() returns a node pointer with refcount
    incremented. Use of_node_put() on it when done.
    The patch fixes the same problem on different i.MX platforms.
    
    Fixes: 8b88f7ef31dde ("ARM: mx25: Retrieve IIM base from dt")
    Fixes: 94b2bec1b0e05 ("ARM: imx27: Retrieve the SYSCTRL base address from devicetree")
    Fixes: 3172225d45bd9 ("ARM: imx31: Retrieve the IIM base address from devicetree")
    Fixes: f68ea682d1da7 ("ARM: imx35: Retrieve the IIM base address from devicetree")
    Fixes: ee18a7154ee08 ("ARM: imx5: retrieve iim base from device tree")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Martin Kaiser <martin@kaiser.cx>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jan 6 23:15:07 2023 +0000

    ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets
    
    [ Upstream commit 242fc66ae6e1e2b8519daacc7590a73cd0e8a6e4 ]
    
    The fsl-asoc-card AC'97 support currently tries to route to Playback and
    Capture widgets provided by the AC'97 CODEC. This doesn't work since the
    generic AC'97 driver registers with an "AC97" at the front of the stream
    and hence widget names, update to reflect reality. It's not clear to me
    if or how this ever worked.
    
    Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-2-a5d7469d4f67@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl_micfil: Correct the number of steps on SX controls [+ + +]
Author: Chancel Liu <chancel.liu@nxp.com>
Date:   Wed Jan 4 10:57:54 2023 +0800

    ASoC: fsl_micfil: Correct the number of steps on SX controls
    
    [ Upstream commit cdfa92eb90f5770b26a79824ef213ebdbbd988b1 ]
    
    The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
    rather than maximum value. This patch corrects the minimum value to -8
    and the number of steps to 15.
    
    Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
    Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
    Link: https://lore.kernel.org/r/20230104025754.3019235-1-chancel.liu@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jan 6 23:15:06 2023 +0000

    ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC
    
    [ Upstream commit 8c6a42b5b0ed6f96624f56954e93eeae107440a6 ]
    
    The SSI driver calls the AC'97 playback and transmit streams "AC97 Playback"
    and "AC97 Capture" respectively. This is the same name used by the generic
    AC'97 CODEC driver in ASoC, creating confusion for the Freescale ASoC card
    when it attempts to use these widgets in routing. Add a "CPU" in the name
    like the regular DAIs registered by the driver to disambiguate.
    
    Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-1-a5d7469d4f67@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: fix and cleanup bio_check_ro [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Mar 4 19:00:56 2022 +0100

    block: fix and cleanup bio_check_ro
    
    commit 57e95e4670d1126c103305bcf34a9442f49f6d6a upstream.
    
    Don't use a WARN_ON when printing a potentially user triggered
    condition.  Also don't print the partno when the block device name
    already includes it, and use the %pg specifier to simplify printing
    the block device name.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Link: https://lore.kernel.org/r/20220304180105.409765-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: hci_sync: cancel cmd_timer if hci_open failed [+ + +]
Author: Archie Pusaka <apusaka@chromium.org>
Date:   Thu Jan 26 16:38:17 2023 +0300

    Bluetooth: hci_sync: cancel cmd_timer if hci_open failed
    
    commit 97dfaf073f5881c624856ef293be307b6166115c upstream.
    
    If a command is already sent, we take care of freeing it, but we
    also need to cancel the timeout as well.
    
    Signed-off-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation [+ + +]
Author: Luis Gerhorst <gerhorst@cs.fau.de>
Date:   Mon Jan 9 16:05:46 2023 +0100

    bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation
    
    [ Upstream commit e4f4db47794c9f474b184ee1418f42e6a07412b6 ]
    
    To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to
    insufficient speculative store bypass mitigation") inserts lfence
    instructions after 1) initializing a stack slot and 2) spilling a
    pointer to the stack.
    
    However, this does not cover cases where a stack slot is first
    initialized with a pointer (subject to sanitization) but then
    overwritten with a scalar (not subject to sanitization because
    the slot was already initialized). In this case, the second write
    may be subject to speculative store bypass (SSB) creating a
    speculative pointer-as-scalar type confusion. This allows the
    program to subsequently leak the numerical pointer value using,
    for example, a branch-based cache side channel.
    
    To fix this, also sanitize scalars if they write a stack slot
    that previously contained a pointer. Assuming that pointer-spills
    are only generated by LLVM on register-pressure, the performance
    impact on most real-world BPF programs should be small.
    
    The following unprivileged BPF bytecode drafts a minimal exploit
    and the mitigation:
    
      [...]
      // r6 = 0 or 1 (skalar, unknown user input)
      // r7 = accessible ptr for side channel
      // r10 = frame pointer (fp), to be leaked
      //
      r9 = r10 # fp alias to encourage ssb
      *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked
      // lfence added here because of pointer spill to stack.
      //
      // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor
      // for no r9-r10 dependency.
      //
      *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr
      // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,
      // store may be subject to SSB
      //
      // fix: also add an lfence when the slot contained a ptr
      //
      r8 = *(u64 *)(r9 - 8)
      // r8 = architecturally a scalar, speculatively a ptr
      //
      // leak ptr using branch-based cache side channel:
      r8 &= 1 // choose bit to leak
      if r8 == 0 goto SLOW // no mispredict
      // architecturally dead code if input r6 is 0,
      // only executes speculatively iff ptr bit is 1
      r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)
    SLOW:
      [...]
    
    After running this, the program can time the access to *(r7 + 0) to
    determine whether the chosen pointer bit was 0 or 1. Repeat this 64
    times to recover the whole address on amd64.
    
    In summary, sanitization can only be skipped if one scalar is
    overwritten with another scalar. Scalar-confusion due to speculative
    store bypass can not lead to invalid accesses because the pointer
    bounds deducted during verification are enforced using branchless
    logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on
    pointer arithmetic") for details.
    
    Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks}
    because speculative leaks are likely unexpected if these were enabled.
    For example, leaking the address to a protected log file may be acceptable
    while disabling the mitigation might unintentionally leak the address
    into the cached-state of a map that is accessible to unprivileged
    processes.
    
    Fixes: 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation")
    Signed-off-by: Luis Gerhorst <gerhorst@cs.fau.de>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Henriette Hofmeier <henriette.hofmeier@rub.de>
    Link: https://lore.kernel.org/bpf/edc95bad-aada-9cfc-ffe2-fa9bb206583c@cs.fau.de
    Link: https://lore.kernel.org/bpf/20230109150544.41465-1-gerhorst@cs.fau.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: Fix oops due to uncleared server->smbd_conn in reconnect [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jan 25 14:02:13 2023 +0000

    cifs: Fix oops due to uncleared server->smbd_conn in reconnect
    
    commit b7ab9161cf5ddc42a288edf9d1a61f3bdffe17c7 upstream.
    
    In smbd_destroy(), clear the server->smbd_conn pointer after freeing the
    smbd_connection struct that it points to so that reconnection doesn't get
    confused.
    
    Fixes: 8ef130f9ec27 ("CIFS: SMBD: Implement function to destroy a SMB Direct connection")
    Cc: stable@vger.kernel.org
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Acked-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Pavel Shilovsky <piastryyy@gmail.com>
    Cc: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clk: Fix pointer casting to prevent oops in devm_clk_release() [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Jun 20 19:18:15 2022 +0200

    clk: Fix pointer casting to prevent oops in devm_clk_release()
    
    commit 8b3d743fc9e2542822826890b482afabf0e7522a upstream.
    
    The release function is called with a pointer to the memory returned by
    devres_alloc(). I was confused about that by the code before the
    generalization that used a struct clk **ptr.
    
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Fixes: abae8e57e49a ("clk: generalize devm_clk_get() a bit")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20220620171815.114212-1-u.kleine-koenig@pengutronix.de
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: generalize devm_clk_get() a bit [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri May 20 09:57:35 2022 +0200

    clk: generalize devm_clk_get() a bit
    
    [ Upstream commit abae8e57e49aa75f6db76aa866c775721523908f ]
    
    Allow to add an exit hook to devm managed clocks. Also use
    clk_get_optional() in devm_clk_get_optional instead of open coding it.
    The generalisation will be used in the next commit to add some more
    devm_clk helpers.
    
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <aardelean@deviqon.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20220520075737.758761-3-u.kleine-koenig@pengutronix.de
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 340cb392a038 ("memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: Provide new devm_clk helpers for prepared and enabled clocks [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri May 20 09:57:36 2022 +0200

    clk: Provide new devm_clk helpers for prepared and enabled clocks
    
    [ Upstream commit 7ef9651e9792b08eb310c6beb202cbc947f43cab ]
    
    When a driver keeps a clock prepared (or enabled) during the whole
    lifetime of the driver, these helpers allow to simplify the drivers.
    
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <aardelean@deviqon.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20220520075737.758761-4-u.kleine-koenig@pengutronix.de
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 340cb392a038 ("memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpufreq: Add Tegra234 to cpufreq-dt-platdev blocklist [+ + +]
Author: Sumit Gupta <sumitg@nvidia.com>
Date:   Tue Dec 20 21:32:37 2022 +0530

    cpufreq: Add Tegra234 to cpufreq-dt-platdev blocklist
    
    [ Upstream commit 01c5bb0cc2a39fbc56ff9a5ef28b79447f0c2351 ]
    
    Tegra234 platform uses the tegra194-cpufreq driver, so add it
    to the blocklist in cpufreq-dt-platdev driver to avoid the cpufreq
    driver registration from there.
    
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: armada-37xx: stop using 0 as NULL pointer [+ + +]
Author: Miles Chen <miles.chen@mediatek.com>
Date:   Tue Jan 10 11:12:52 2023 +0800

    cpufreq: armada-37xx: stop using 0 as NULL pointer
    
    [ Upstream commit 08f0adb193c008de640fde34a2e00a666c01d77c ]
    
    Use NULL for NULL pointer to fix the following sparse warning:
    drivers/cpufreq/armada-37xx-cpufreq.c:448:32: sparse: warning: Using plain integer as NULL pointer
    
    Signed-off-by: Miles Chen <miles.chen@mediatek.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
csky: Fix function name in csky_alignment() and die() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 24 11:29:54 2023 -0800

    csky: Fix function name in csky_alignment() and die()
    
    commit 751971af2e3615dc5bd12674080bc795505fefeb upstream.
    
    When building ARCH=csky defconfig:
    
    arch/csky/kernel/traps.c: In function 'die':
    arch/csky/kernel/traps.c:112:17: error: implicit declaration of function
    'make_dead_task' [-Werror=implicit-function-declaration]
      112 |                 make_dead_task(SIGSEGV);
          |                 ^~~~~~~~~~~~~~
    
    The function's name is make_task_dead(), change it so there is no more
    build error.
    
    Fixes: 0e25498f8cd4 ("exit: Add and use make_task_dead.")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Link: https://lkml.kernel.org/r/20211227184851.2297759-4-nathan@kernel.org
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: Fix double increment of client_count in dma_chan_get() [+ + +]
Author: Koba Ko <koba.ko@canonical.com>
Date:   Thu Dec 1 11:00:50 2022 +0800

    dmaengine: Fix double increment of client_count in dma_chan_get()
    
    [ Upstream commit f3dc1b3b4750851a94212dba249703dd0e50bb20 ]
    
    The first time dma_chan_get() is called for a channel the channel
    client_count is incorrectly incremented twice for public channels,
    first in balance_ref_count(), and again prior to returning. This
    results in an incorrect client count which will lead to the
    channel resources not being freed when they should be. A simple
     test of repeated module load and unload of async_tx on a Dell
     Power Edge R7425 also shows this resulting in a kref underflow
     warning.
    
    [  124.329662] async_tx: api initialized (async)
    [  129.000627] async_tx: api initialized (async)
    [  130.047839] ------------[ cut here ]------------
    [  130.052472] refcount_t: underflow; use-after-free.
    [  130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28
    refcount_warn_saturate+0xba/0x110
    [  130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr
    intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm
    mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si
    syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops
    k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat
    fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul
    libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas
    i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash
    dm_log dm_mod [last unloaded: async_tx]
    [  130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not
    tainted 5.14.0-185.el9.x86_64 #1
    [  130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS
    1.18.0 01/17/2022
    [  130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110
    [  130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d
    26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a
    bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff
    48 c7
    [  130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286
    [  130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000
    [  130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0
    [  130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff
    [  130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970
    [  130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    [  130.198739] FS:  00007f646435c740(0000) GS:ffff9daf9de00000(0000)
    knlGS:0000000000000000
    [  130.206832] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0
    [  130.219729] Call Trace:
    [  130.222192]  <TASK>
    [  130.224305]  dma_chan_put+0x10d/0x110
    [  130.227988]  dmaengine_put+0x7a/0xa0
    [  130.231575]  __do_sys_delete_module.constprop.0+0x178/0x280
    [  130.237157]  ? syscall_trace_enter.constprop.0+0x145/0x1d0
    [  130.242652]  do_syscall_64+0x5c/0x90
    [  130.246240]  ? exc_page_fault+0x62/0x150
    [  130.250178]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [  130.255243] RIP: 0033:0x7f6463a3f5ab
    [  130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48
    83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00
    00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89
    01 48
    [  130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:
    00000000000000b0
    [  130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab
    [  130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8
    [  130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000
    [  130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8
    [  130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8
    [  130.320875]  </TASK>
    [  130.323081] ---[ end trace eff7156d56b5cf25 ]---
    
    cat /sys/class/dma/dma0chan*/in_use would get the wrong result.
    2
    2
    2
    
    Fixes: d2f4f99db3e9 ("dmaengine: Rework dma_chan_get")
    Signed-off-by: Koba Ko <koba.ko@canonical.com>
    Reviewed-by: Jie Hai <haijie1@huawei.com>
    Test-by: Jie Hai <haijie1@huawei.com>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Tested-by: Joel Savitz <jsavitz@redhat.com>
    Link: https://lore.kernel.org/r/20221201030050.978595-1-koba.ko@canonical.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: xilinx_dma: call of_node_put() when breaking out of for_each_child_of_node() [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Tue Nov 22 10:16:12 2022 +0800

    dmaengine: xilinx_dma: call of_node_put() when breaking out of for_each_child_of_node()
    
    [ Upstream commit 596b53ccc36a546ab28e8897315c5b4d1d5a0200 ]
    
    Since for_each_child_of_node() will increase the refcount of node, we need
    to call of_node_put() manually when breaking out of the iteration.
    
    Fixes: 9cd4360de609 ("dma: Add Xilinx AXI Video Direct Memory Access Engine driver support")
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Acked-by: Peter Korsgaard <peter@korsgaard.com>
    Link: https://lore.kernel.org/r/20221122021612.1908866-1-liushixin2@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
docs: Fix path paste-o for /sys/kernel/warn_count [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:30:03 2023 -0800

    docs: Fix path paste-o for /sys/kernel/warn_count
    
    commit 00dd027f721e0458418f7750d8a5a664ed3e5994 upstream.
    
    Running "make htmldocs" shows that "/sys/kernel/oops_count" was
    duplicated. This should have been "warn_count":
    
      Warning: /sys/kernel/oops_count is defined 2 times:
      ./Documentation/ABI/testing/sysfs-kernel-warn_count:0
      ./Documentation/ABI/testing/sysfs-kernel-oops_count:0
    
    Fix the typo.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/linux-doc/202212110529.A3Qav8aR-lkp@intel.com
    Fixes: 8b05aa263361 ("panic: Expose "warn_count" to sysfs")
    Cc: linux-hardening@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
driver core: Fix test_async_probe_init saves device in wrong array [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Fri Nov 25 14:35:41 2022 +0800

    driver core: Fix test_async_probe_init saves device in wrong array
    
    [ Upstream commit 9be182da0a7526f1b9a3777a336f83baa2e64d23 ]
    
    In test_async_probe_init, second set of asynchronous devices are saved
    in sync_dev[sync_id], which should be async_dev[async_id].
    This makes these devices not unregistered when exit.
    
    > modprobe test_async_driver_probe && \
    > modprobe -r test_async_driver_probe && \
    > modprobe test_async_driver_probe
     ...
    > sysfs: cannot create duplicate filename '/devices/platform/test_async_driver.4'
    > kobject_add_internal failed for test_async_driver.4 with -EEXIST,
      don't try to register things with the same name in the same directory.
    
    Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Link: https://lore.kernel.org/r/20221125063541.241328-1-chenzhongjin@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panfrost: fix GENERIC_ATOMIC64 dependency [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 17:44:43 2023 +0100

    drm/panfrost: fix GENERIC_ATOMIC64 dependency
    
    [ Upstream commit 6437a549ae178a3f5a5c03e983f291ebcdc2bbc7 ]
    
    On ARMv5 and earlier, a randconfig build can still run into
    
    WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE
      Depends on [n]: IOMMU_SUPPORT [=y] && (ARM [=y] || ARM64 || COMPILE_TEST [=y]) && !GENERIC_ATOMIC64 [=y]
      Selected by [y]:
      - DRM_PANFROST [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARM [=y] || ARM64 || COMPILE_TEST [=y] && !GENERIC_ATOMIC64 [=y]) && MMU [=y]
    
    Rework the dependencies to always require a working cmpxchg64.
    
    Fixes: db594ba3fcf9 ("drm/panfrost: depend on !GENERIC_ATOMIC64 when using COMPILE_TEST")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Signed-off-by: Steven Price <steven.price@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230117164456.1591901-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: Add orientation quirk for Lenovo ideapad D330-10IGL [+ + +]
Author: Patrick Thompson <ptf@google.com>
Date:   Tue Dec 20 15:58:26 2022 -0500

    drm: Add orientation quirk for Lenovo ideapad D330-10IGL
    
    [ Upstream commit 0688773f0710528e1ab302c3d6317e269f2e2e6e ]
    
    Panel is 800x1280 but mounted on a detachable form factor sideways.
    
    Signed-off-by: Patrick Thompson <ptf@google.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221220205826.178008-1-ptf@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/device: Respect any driver-supplied workqueue polling value [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Wed Jan 18 20:38:48 2023 +0530

    EDAC/device: Respect any driver-supplied workqueue polling value
    
    commit cec669ff716cc83505c77b242aecf6f7baad869d upstream.
    
    The EDAC drivers may optionally pass the poll_msec value. Use that value
    if available, else fall back to 1000ms.
    
      [ bp: Touchups. ]
    
    Fixes: e27e3dac6517 ("drivers/edac: add edac_device class")
    Reported-by: Luca Weiss <luca.weiss@fairphone.com>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
    Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride
    Cc: <stable@vger.kernel.org> # 4.9
    Link: https://lore.kernel.org/r/COZYL8MWN97H.MROQ391BGA09@otso
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
EDAC/highbank: Fix memory leak in highbank_mc_probe() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Dec 29 09:48:24 2022 +0400

    EDAC/highbank: Fix memory leak in highbank_mc_probe()
    
    [ Upstream commit e7a293658c20a7945014570e1921bf7d25d68a36 ]
    
    When devres_open_group() fails, it returns -ENOMEM without freeing memory
    allocated by edac_mc_alloc().
    
    Call edac_mc_free() on the error handling path to avoid a memory leak.
    
      [ bp: Massage commit message. ]
    
    Fixes: a1b01edb2745 ("edac: add support for Calxeda highbank memory controller")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Link: https://lore.kernel.org/r/20221229054825.1361993-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Wed Jan 18 20:38:50 2023 +0530

    EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info
    
    commit 977c6ba624f24ae20cf0faee871257a39348d4a9 upstream.
    
    The memory for llcc_driv_data is allocated by the LLCC driver. But when
    it is passed as the private driver info to the EDAC core, it will get freed
    during the qcom_edac driver release. So when the qcom_edac driver gets probed
    again, it will try to use the freed data leading to the use-after-free bug.
    
    Hence, do not pass llcc_driv_data as pvt_info but rather reference it
    using the platform_data pointer in the qcom_edac driver.
    
    Fixes: 27450653f1db ("drivers: edac: Add EDAC driver support for QCOM SoCs")
    Reported-by: Steev Klimaszewski <steev@kali.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
    Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride
    Cc: <stable@vger.kernel.org> # 4.20
    Link: https://lore.kernel.org/r/20230118150904.26913-4-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
exit: Add and use make_task_dead. [+ + +]
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Jan 24 11:29:50 2023 -0800

    exit: Add and use make_task_dead.
    
    commit 0e25498f8cd43c1b5aa327f373dd094e9a006da7 upstream.
    
    There are two big uses of do_exit.  The first is it's design use to be
    the guts of the exit(2) system call.  The second use is to terminate
    a task after something catastrophic has happened like a NULL pointer
    in kernel code.
    
    Add a function make_task_dead that is initialy exactly the same as
    do_exit to cover the cases where do_exit is called to handle
    catastrophic failure.  In time this can probably be reduced to just a
    light wrapper around do_task_dead. For now keep it exactly the same so
    that there will be no behavioral differences introducing this new
    concept.
    
    Replace all of the uses of do_exit that use it for catastraphic
    task cleanup with make_task_dead to make it clear what the code
    is doing.
    
    As part of this rename rewind_stack_do_exit
    rewind_stack_and_make_dead.
    
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

exit: Allow oops_limit to be disabled [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:29:59 2023 -0800

    exit: Allow oops_limit to be disabled
    
    commit de92f65719cd672f4b48397540b9f9eff67eca40 upstream.
    
    In preparation for keeping oops_limit logic in sync with warn_limit,
    have oops_limit == 0 disable checking the Oops counter.
    
    Cc: Jann Horn <jannh@google.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: Eric Biggers <ebiggers@google.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: linux-doc@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

exit: Expose "oops_count" to sysfs [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:29:58 2023 -0800

    exit: Expose "oops_count" to sysfs
    
    commit 9db89b41117024f80b38b15954017fb293133364 upstream.
    
    Since Oops count is now tracked and is a fairly interesting signal, add
    the entry /sys/kernel/oops_count to expose it to userspace.
    
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-3-keescook@chromium.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

exit: Put an upper limit on how often we can oops [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Tue Jan 24 11:29:57 2023 -0800

    exit: Put an upper limit on how often we can oops
    
    commit d4ccd54d28d3c8598e2354acc13e28c060961dbb upstream.
    
    Many Linux systems are configured to not panic on oops; but allowing an
    attacker to oops the system **really** often can make even bugs that look
    completely unexploitable exploitable (like NULL dereferences and such) if
    each crash elevates a refcount by one or a lock is taken in read mode, and
    this causes a counter to eventually overflow.
    
    The most interesting counters for this are 32 bits wide (like open-coded
    refcounts that don't use refcount_t). (The ldsem reader count on 32-bit
    platforms is just 16 bits, but probably nobody cares about 32-bit platforms
    that much nowadays.)
    
    So let's panic the system if the kernel is constantly oopsing.
    
    The speed of oopsing 2^32 times probably depends on several factors, like
    how long the stack trace is and which unwinder you're using; an empirically
    important one is whether your console is showing a graphical environment or
    a text console that oopses will be printed to.
    In a quick single-threaded benchmark, it looks like oopsing in a vfork()
    child with a very short stack trace only takes ~510 microseconds per run
    when a graphical console is active; but switching to a text console that
    oopses are printed to slows it down around 87x, to ~45 milliseconds per
    run.
    (Adding more threads makes this faster, but the actual oops printing
    happens under &die_lock on x86, so you can maybe speed this up by a factor
    of around 2 and then any further improvement gets eaten up by lock
    contention.)
    
    It looks like it would take around 8-12 days to overflow a 32-bit counter
    with repeated oopsing on a multi-core X86 system running a graphical
    environment; both me (in an X86 VM) and Seth (with a distro kernel on
    normal hardware in a standard configuration) got numbers in that ballpark.
    
    12 days aren't *that* short on a desktop system, and you'd likely need much
    longer on a typical server system (assuming that people don't run graphical
    desktop environments on their servers), and this is a *very* noisy and
    violent approach to exploiting the kernel; and it also seems to take orders
    of magnitude longer on some machines, probably because stuff like EFI
    pstore will slow it down a ton if that's active.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Link: https://lore.kernel.org/r/20221107201317.324457-1-jannh@google.com
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-2-keescook@chromium.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

exit: Use READ_ONCE() for all oops/warn limit reads [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:30:04 2023 -0800

    exit: Use READ_ONCE() for all oops/warn limit reads
    
    commit 7535b832c6399b5ebfc5b53af5c51dd915ee2538 upstream.
    
    Use a temporary variable to take full advantage of READ_ONCE() behavior.
    Without this, the report (and even the test) might be out of sync with
    the initial test.
    
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/lkml/Y5x7GXeluFmZ8E0E@hirez.programming.kicks-ass.net
    Fixes: 9fc9e278a5c0 ("panic: Introduce warn_limit")
    Fixes: d4ccd54d28d3 ("exit: Put an upper limit on how often we can oops")
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Marco Elver <elver@google.com>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: arm_scmi: Harden shared memory access in fetch_notification [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Thu Dec 22 18:38:21 2022 +0000

    firmware: arm_scmi: Harden shared memory access in fetch_notification
    
    [ Upstream commit 9bae076cd4e3e3c3dc185cae829d80b2dddec86e ]
    
    A misbheaving SCMI platform firmware could reply with out-of-spec
    notifications, shorter than the mimimum size comprising a header.
    
    Fixes: d5141f37c42e ("firmware: arm_scmi: Add notifications support in transport layer")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20221222183823.518856-4-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: arm_scmi: Harden shared memory access in fetch_response [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Thu Dec 22 18:38:20 2022 +0000

    firmware: arm_scmi: Harden shared memory access in fetch_response
    
    [ Upstream commit ad78b81a1077f7d956952cd8bdfe1e61504e3eb8 ]
    
    A misbheaving SCMI platform firmware could reply with out-of-spec messages,
    shorter than the mimimum size comprising a header and a status field.
    
    Harden shmem_fetch_response to properly truncate such a bad messages.
    
    Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20221222183823.518856-3-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: reiserfs: remove useless new_opts in reiserfs_remount [+ + +]
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Wed Oct 27 22:34:41 2021 +0800

    fs: reiserfs: remove useless new_opts in reiserfs_remount
    
    commit 81dedaf10c20959bdf5624f9783f408df26ba7a4 upstream.
    
    Since the commit c3d98ea08291 ("VFS: Don't use save/replace_mount_options
    if not using generic_show_options") eliminates replace_mount_options
    in reiserfs_remount, but does not handle the allocated new_opts,
    it will cause memory leak in the reiserfs_remount.
    
    Because new_opts is useless in reiserfs_mount, so we fix this bug by
    removing the useless new_opts in reiserfs_remount.
    
    Fixes: c3d98ea08291 ("VFS: Don't use save/replace_mount_options if not using generic_show_options")
    Link: https://lore.kernel.org/r/20211027143445.4156459-1-mudongliangabcd@gmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ftrace/scripts: Update the instructions for ftrace-bisect.sh [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Mon Jan 23 11:22:52 2023 -0500

    ftrace/scripts: Update the instructions for ftrace-bisect.sh
    
    commit 7ae4ba7195b1bac04a4210a499da9d8c63b0ba9c upstream.
    
    The instructions for the ftrace-bisect.sh script, which is used to find
    what function is being traced that is causing a kernel crash, and possibly
    a triple fault reboot, uses the old method. In 5.1, a new feature was
    added that let the user write in the index into available_filter_functions
    that maps to the function a user wants to set in set_ftrace_filter (or
    set_ftrace_notrace). This takes O(1) to set, as suppose to writing a
    function name, which takes O(n) (where n is the number of functions in
    available_filter_functions).
    
    The ftrace-bisect.sh requires setting half of the functions in
    available_filter_functions, which is O(n^2) using the name method to enable
    and can take several minutes to complete. The number method is O(n) which
    takes less than a second to complete. Using the number method for any
    kernel 5.1 and after is the proper way to do the bisect.
    
    Update the usage to reflect the new change, as well as using the
    /sys/kernel/tracing path instead of the obsolete debugfs path.
    
    Link: https://lkml.kernel.org/r/20230123112252.022003dd@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Fixes: f79b3f338564e ("ftrace: Allow enabling of filters via index of available_filter_functions")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpio: mxc: Always set GPIOs used as interrupt source to INPUT mode [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Jan 16 10:49:57 2023 +0100

    gpio: mxc: Always set GPIOs used as interrupt source to INPUT mode
    
    [ Upstream commit 8e88a0feebb241cab0253698b2f7358b6ebec802 ]
    
    Always configure GPIO pins which are used as interrupt source as INPUTs.
    In case the default pin configuration is OUTPUT, or the prior stage does
    configure the pins as OUTPUT, then Linux will not reconfigure the pin as
    INPUT and no interrupts are received.
    
    Always configure the interrupt source GPIO pin as input to fix the above case.
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Fixes: 07bd1a6cc7cbb ("MXC arch: Add gpio support for the whole platform")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
h8300: Fix build errors from do_exit() to make_task_dead() transition [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 24 11:29:53 2023 -0800

    h8300: Fix build errors from do_exit() to make_task_dead() transition
    
    commit ab4ababdf77ccc56c7301c751dff49c79709c51c upstream.
    
    When building ARCH=h8300 defconfig:
    
    arch/h8300/kernel/traps.c: In function 'die':
    arch/h8300/kernel/traps.c:109:2: error: implicit declaration of function
    'make_dead_task' [-Werror=implicit-function-declaration]
      109 |  make_dead_task(SIGSEGV);
          |  ^~~~~~~~~~~~~~
    
    arch/h8300/mm/fault.c: In function 'do_page_fault':
    arch/h8300/mm/fault.c:54:2: error: implicit declaration of function
    'make_dead_task' [-Werror=implicit-function-declaration]
       54 |  make_dead_task(SIGKILL);
          |  ^~~~~~~~~~~~~~
    
    The function's name is make_task_dead(), change it so there is no more
    build error.
    
    Additionally, include linux/sched/task.h in arch/h8300/kernel/traps.c
    to avoid the same error because do_exit()'s declaration is in kernel.h
    but make_task_dead()'s is in task.h, which is not included in traps.c.
    
    Fixes: 0e25498f8cd4 ("exit: Add and use make_task_dead.")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lkml.kernel.org/r/20211227184851.2297759-3-nathan@kernel.org
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hexagon: Fix function name in die() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 24 11:29:52 2023 -0800

    hexagon: Fix function name in die()
    
    commit 4f0712ccec09c071e221242a2db9a6779a55a949 upstream.
    
    When building ARCH=hexagon defconfig:
    
    arch/hexagon/kernel/traps.c:217:2: error: implicit declaration of
    function 'make_dead_task' [-Werror,-Wimplicit-function-declaration]
            make_dead_task(err);
            ^
    
    The function's name is make_task_dead(), change it so there is no more
    build error.
    
    Fixes: 0e25498f8cd4 ("exit: Add and use make_task_dead.")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lkml.kernel.org/r/20211227184851.2297759-2-nathan@kernel.org
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: betop: check shape of output reports [+ + +]
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Wed Jan 11 18:12:16 2023 +0000

    HID: betop: check shape of output reports
    
    [ Upstream commit 3782c0d6edf658b71354a64d60aa7a296188fc90 ]
    
    betopff_init() only checks the total sum of the report counts for each
    report field to be at least 4, but hid_betopff_play() expects 4 report
    fields.
    A device advertising an output report with one field and 4 report counts
    would pass the check but crash the kernel with a NULL pointer dereference
    in hid_betopff_play().
    
    Fixes: 52cd7785f3cd ("HID: betop: add drivers/hid/hid-betopff.c")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: check empty report_list in bigben_probe() [+ + +]
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Mon Jan 16 11:11:25 2023 +0000

    HID: check empty report_list in bigben_probe()
    
    [ Upstream commit c7bf714f875531f227f2ef1fdcc8f4d44e7c7d9d ]
    
    Add a check for empty report_list in bigben_probe().
    The missing check causes a type confusion when issuing a list_entry()
    on an empty report_list.
    The problem is caused by the assumption that the device must
    have valid report_list. While this will be true for all normal HID
    devices, a suitably malicious device can violate the assumption.
    
    Fixes: 256a90ed9e46 ("HID: hid-bigbenff: driver for BigBen Interactive PS3OFMINIPAD gamepad")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: check empty report_list in hid_validate_values() [+ + +]
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Mon Jan 16 11:11:24 2023 +0000

    HID: check empty report_list in hid_validate_values()
    
    [ Upstream commit b12fece4c64857e5fab4290bf01b2e0317a88456 ]
    
    Add a check for empty report_list in hid_validate_values().
    The missing check causes a type confusion when issuing a list_entry()
    on an empty report_list.
    The problem is caused by the assumption that the device must
    have valid report_list. While this will be true for all normal HID
    devices, a suitably malicious device can violate the assumption.
    
    Fixes: 1b15d2e5b807 ("HID: core: fix validation of report id 0")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: intel_ish-hid: Add check for ishtp_dma_tx_map [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Nov 22 21:48:23 2022 +0800

    HID: intel_ish-hid: Add check for ishtp_dma_tx_map
    
    [ Upstream commit b3d40c3ec3dc4ad78017de6c3a38979f57aaaab8 ]
    
    As the kcalloc may return NULL pointer,
    it should be better to check the ishtp_dma_tx_map
    before use in order to avoid NULL pointer dereference.
    
    Fixes: 3703f53b99e4 ("HID: intel_ish-hid: ISH Transport layer")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: revert CHERRY_MOUSE_000C quirk [+ + +]
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Jan 17 15:41:40 2023 +0100

    HID: revert CHERRY_MOUSE_000C quirk
    
    [ Upstream commit cbf44580ce6b310272a73e3e794233fd064330bd ]
    
    This partially reverts commit f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk
    for some mice"), as it turns out to break reboot on some platforms for reason
    yet to be understood.
    
    Fixes: f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk for some mice")
    Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: designware: use casting of u64 in clock multiplication to avoid overflow [+ + +]
Author: Lareine Khawaly <lareine@amazon.com>
Date:   Wed Dec 21 19:59:00 2022 +0000

    i2c: designware: use casting of u64 in clock multiplication to avoid overflow
    
    [ Upstream commit c8c37bc514514999e62a17e95160ed9ebf75ca8d ]
    
    In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow
    by depending on the values of the given parameters including the ic_clk.
    For example in our use case where ic_clk is larger than one million,
    multiplication of ic_clk * 4700 will result in 32 bit overflow.
    
    Add cast of u64 to the calculation to avoid multiplication overflow, and
    use the corresponding define for divide.
    
    Fixes: 2373f6b9744d ("i2c-designware: split of i2c-designware.c into core and bus specific parts")
    Signed-off-by: Lareine Khawaly <lareine@amazon.com>
    Signed-off-by: Hanna Hawa <hhhawa@amazon.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: designware: Use DIV_ROUND_CLOSEST() macro [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jul 12 17:20:26 2021 +0300

    i2c: designware: Use DIV_ROUND_CLOSEST() macro
    
    [ Upstream commit c045214a0f31dd5d6be716ed2f119b57b6c5d3a2 ]
    
    Instead of open-coding DIV_ROUND_CLOSEST() and similar use the macros directly.
    While at it, replace numbers with predefined SI metric prefixes.
    
    No functional change intended.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Stable-dep-of: c8c37bc51451 ("i2c: designware: use casting of u64 in clock multiplication to avoid overflow")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ia64: make IA64_MCA_RECOVERY bool instead of tristate [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Jan 24 11:29:55 2023 -0800

    ia64: make IA64_MCA_RECOVERY bool instead of tristate
    
    commit dbecf9b8b8ce580f4e11afed9d61e8aa294cddd2 upstream.
    
    In linux-next, IA64_MCA_RECOVERY uses the (new) function
    make_task_dead(), which is not exported for use by modules.  Instead of
    exporting it for one user, convert IA64_MCA_RECOVERY to be a bool
    Kconfig symbol.
    
    In a config file from "kernel test robot <lkp@intel.com>" for a
    different problem, this linker error was exposed when
    CONFIG_IA64_MCA_RECOVERY=m.
    
    Fixes this build error:
    
      ERROR: modpost: "make_task_dead" [arch/ia64/kernel/mca_recovery.ko] undefined!
    
    Link: https://lkml.kernel.org/r/20220124213129.29306-1-rdunlap@infradead.org
    Fixes: 0e25498f8cd4 ("exit: Add and use make_task_dead.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Suggested-by: Christoph Hellwig <hch@infradead.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/hfi1: Fix expected receive setup error exit issues [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:21 2023 -0500

    IB/hfi1: Fix expected receive setup error exit issues
    
    [ Upstream commit e0c4a422f5246abefbf7c178ef99a1f2dc3c5f62 ]
    
    Fix three error exit issues in expected receive setup.
    Re-arrange error exits to increase readability.
    
    Issues and fixes:
    1. Possible missed page unpin if tidlist copyout fails and
       not all pinned pages where made part of a TID.
       Fix: Unpin the unused pages.
    
    2. Return success with unset return values tidcnt and length
       when no pages were pinned.
       Fix: Return -ENOSPC if no pages were pinned.
    
    3. Return success with unset return values tidcnt and length when
       no rcvarray entries available.
       Fix: Return -ENOSPC if no rcvarray entries are available.
    
    Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
    Fixes: 97736f36dbeb ("IB/hfi1: Validate page aligned for a given virtual addres")
    Fixes: f404ca4c7ea8 ("IB/hfi1: Refactor hfi_user_exp_rcv_setup() IOCTL")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328548150.1472310.1492305874804187634.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Immediately remove invalid memory from hardware [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:26 2023 -0500

    IB/hfi1: Immediately remove invalid memory from hardware
    
    [ Upstream commit 1c7edde1b5720ddb0aff5ca8c7f605a0f92526eb ]
    
    When a user expected receive page is unmapped, it should be
    immediately removed from hardware rather than depend on a
    reaction from user space.
    
    Fixes: 2677a7680e77 ("IB/hfi1: Fix memory leak during unexpected shutdown")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328548663.1472310.7871808081861622659.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Reject a zero-length user expected buffer [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:11 2023 -0500

    IB/hfi1: Reject a zero-length user expected buffer
    
    [ Upstream commit 0a0a6e80472c98947d73c3d13bcd7d101895f55d ]
    
    A zero length user buffer makes no sense and the code
    does not handle it correctly.  Instead, reject a
    zero length as invalid.
    
    Fixes: 97736f36dbeb ("IB/hfi1: Validate page aligned for a given virtual addres")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328547120.1472310.6362802432127399257.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Remove user expected buffer invalidate race [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:31 2023 -0500

    IB/hfi1: Remove user expected buffer invalidate race
    
    [ Upstream commit b3deec25847bda34e34d5d7be02f633caf000bd8 ]
    
    During setup, there is a possible race between a page invalidate
    and hardware programming.  Add a covering invalidate over the user
    target range during setup.  If anything within that range is
    invalidated during setup, fail the setup.  Once set up, each
    TID will have its own invalidate callback and invalidate.
    
    Fixes: 3889551db212 ("RDMA/hfi1: Use mmu_interval_notifier_insert for user_exp_rcv")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328549178.1472310.9867497376936699488.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Reserve user expected TIDs [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:16 2023 -0500

    IB/hfi1: Reserve user expected TIDs
    
    [ Upstream commit ecf91551cdd2925ed6d9a9d99074fa5f67b90596 ]
    
    To avoid a race, reserve the number of user expected
    TIDs before setup.
    
    Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328547636.1472310.7419712824785353905.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4: prevent potential spectre v1 gadget in fib_metrics_match() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 13:31:40 2023 +0000

    ipv4: prevent potential spectre v1 gadget in fib_metrics_match()
    
    [ Upstream commit 5e9398a26a92fc402d82ce1f97cc67d832527da0 ]
    
    if (!type)
            continue;
        if (type > RTAX_MAX)
            return false;
        ...
        fi_val = fi->fib_metrics->metrics[type - 1];
    
    @type being used as an array index, we need to prevent
    cpu speculation or risk leaking kernel memory content.
    
    Fixes: 5f9ae3d9e7e4 ("ipv4: do metrics match when looking up and deleting a route")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230120133140.3624204-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv4: prevent potential spectre v1 gadget in ip_metrics_convert() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 13:30:40 2023 +0000

    ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()
    
    [ Upstream commit 1d1d63b612801b3f0a39b7d4467cad0abd60e5c8 ]
    
    if (!type)
                    continue;
            if (type > RTAX_MAX)
                    return -EINVAL;
            ...
            metrics[type - 1] = val;
    
    @type being used as an array index, we need to prevent
    cpu speculation or risk leaking kernel memory content.
    
    Fixes: 6cf9dfd3bd62 ("net: fib: move metrics parsing to a helper")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230120133040.3623463-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kasan: no need to unset panic_on_warn in end_report() [+ + +]
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Jan 24 11:29:49 2023 -0800

    kasan: no need to unset panic_on_warn in end_report()
    
    commit e7ce7500375a63348e1d3a703c8d5003cbe3fea6 upstream.
    
    panic_on_warn is unset inside panic(), so no need to unset it before
    calling panic() in end_report().
    
    Link: https://lkml.kernel.org/r/1644324666-15947-6-git-send-email-yangtiezhu@loongson.cn
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Reviewed-by: Marco Elver <elver@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Xuefeng Li <lixuefeng@loongson.cn>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kcsan: test: don't put the expect array on the stack [+ + +]
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Dec 22 23:28:21 2022 -0800

    kcsan: test: don't put the expect array on the stack
    
    [ Upstream commit 5b24ac2dfd3eb3e36f794af3aa7f2828b19035bd ]
    
    Size of the 'expect' array in the __report_matches is 1536 bytes, which
    is exactly the default frame size warning limit of the xtensa
    architecture.
    As a result allmodconfig xtensa kernel builds with the gcc that does not
    support the compiler plugins (which otherwise would push the said
    warning limit to 2K) fail with the following message:
    
      kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes
        is larger than 1536 bytes
    
    Fix it by dynamically allocating the 'expect' array.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Tested-by: Marco Elver <elver@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kernel/panic: move panic sysctls to its own file [+ + +]
Author: tangmeng <tangmeng@uniontech.com>
Date:   Tue Jan 24 11:29:46 2023 -0800

    kernel/panic: move panic sysctls to its own file
    
    commit 9df918698408fd914493aba0b7858fef50eba63a upstream.
    
    kernel/sysctl.c is a kitchen sink where everyone leaves their dirty
    dishes, this makes it very difficult to maintain.
    
    To help with this maintenance let's start by moving sysctls to places
    where they actually belong.  The proc sysctl maintainers do not want to
    know what sysctl knobs you wish to add for your own piece of code, we
    just care about the core logic.
    
    All filesystem syctls now get reviewed by fs folks. This commit
    follows the commit of fs, move the oops_all_cpu_backtrace sysctl to
    its own file, kernel/panic.c.
    
    Signed-off-by: tangmeng <tangmeng@uniontech.com>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: s390: interrupt: use READ_ONCE() before cmpxchg() [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Jan 9 15:54:56 2023 +0100

    KVM: s390: interrupt: use READ_ONCE() before cmpxchg()
    
    [ Upstream commit 42400d99e9f0728c17240edb9645637ead40f6b9 ]
    
    Use READ_ONCE() before cmpxchg() to prevent that the compiler generates
    code that fetches the to be compared old value several times from memory.
    
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230109145456.2895385-1-hca@linux.ibm.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/vmx: Do not skip segment attributes if unusable bit is set [+ + +]
Author: Hendrik Borghorst <hborghor@amazon.de>
Date:   Mon Nov 14 16:48:23 2022 +0000

    KVM: x86/vmx: Do not skip segment attributes if unusable bit is set
    
    commit a44b331614e6f7e63902ed7dff7adc8c85edd8bc upstream.
    
    When serializing and deserializing kvm_sregs, attributes of the segment
    descriptors are stored by user space. For unusable segments,
    vmx_segment_access_rights skips all attributes and sets them to 0.
    
    This means we zero out the DPL (Descriptor Privilege Level) for unusable
    entries.
    
    Unusable segments are - contrary to their name - usable in 64bit mode and
    are used by guests to for example create a linear map through the
    NULL selector.
    
    VMENTER checks if SS.DPL is correct depending on the CS segment type.
    For types 9 (Execute Only) and 11 (Execute Read), CS.DPL must be equal to
    SS.DPL [1].
    
    We have seen real world guests setting CS to a usable segment with DPL=3
    and SS to an unusable segment with DPL=3. Once we go through an sregs
    get/set cycle, SS.DPL turns to 0. This causes the virtual machine to crash
    reproducibly.
    
    This commit changes the attribute logic to always preserve attributes for
    unusable segments. According to [2] SS.DPL is always saved on VM exits,
    regardless of the unusable bit so user space applications should have saved
    the information on serialization correctly.
    
    [3] specifies that besides SS.DPL the rest of the attributes of the
    descriptors are undefined after VM entry if unusable bit is set. So, there
    should be no harm in setting them all to the previous state.
    
    [1] Intel SDM Vol 3C 26.3.1.2 Checks on Guest Segment Registers
    [2] Intel SDM Vol 3C 27.3.2 Saving Segment Registers and Descriptor-Table
    Registers
    [3] Intel SDM Vol 3C 26.3.2.2 Loading Guest Segment Registers and
    Descriptor-Table Registers
    
    Cc: Alexander Graf <graf@amazon.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hendrik Borghorst <hborghor@amazon.de>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Alexander Graf <graf@amazon.com>
    Message-Id: <20221114164823.69555-1-hborghor@amazon.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
l2tp: close all race conditions in l2tp_tunnel_register() [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Fri Jan 13 19:01:37 2023 -0800

    l2tp: close all race conditions in l2tp_tunnel_register()
    
    [ Upstream commit 0b2c59720e65885a394a017d0cf9cab118914682 ]
    
    The code in l2tp_tunnel_register() is racy in several ways:
    
    1. It modifies the tunnel socket _after_ publishing it.
    
    2. It calls setup_udp_tunnel_sock() on an existing socket without
       locking.
    
    3. It changes sock lock class on fly, which triggers many syzbot
       reports.
    
    This patch amends all of them by moving socket initialization code
    before publishing and under sock lock. As suggested by Jakub, the
    l2tp lockdep class is not necessary as we can just switch to
    bh_lock_sock_nested().
    
    Fixes: 37159ef2c1ae ("l2tp: fix a lockdep splat")
    Fixes: 6b9f34239b00 ("l2tp: fix races in tunnel creation")
    Reported-by: syzbot+52866e24647f9a23403f@syzkaller.appspotmail.com
    Reported-by: syzbot+94cc2a66fc228b23f360@syzkaller.appspotmail.com
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Guillaume Nault <gnault@redhat.com>
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Tom Parkin <tparkin@katalix.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

l2tp: convert l2tp_tunnel_list to idr [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Fri Jan 13 19:01:36 2023 -0800

    l2tp: convert l2tp_tunnel_list to idr
    
    [ Upstream commit c4d48a58f32c5972174a1d01c33b296fe378cce0 ]
    
    l2tp uses l2tp_tunnel_list to track all registered tunnels and
    to allocate tunnel ID's. IDR can do the same job.
    
    More importantly, with IDR we can hold the ID before a successful
    registration so that we don't need to worry about late error
    handling, it is not easy to rollback socket changes.
    
    This is a preparation for the following fix.
    
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Guillaume Nault <gnault@redhat.com>
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Tom Parkin <tparkin@katalix.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

l2tp: Don't sleep and disable BH under writer-side sk_callback_lock [+ + +]
Author: Jakub Sitnicki <jakub@cloudflare.com>
Date:   Mon Nov 21 09:54:26 2022 +0100

    l2tp: Don't sleep and disable BH under writer-side sk_callback_lock
    
    [ Upstream commit af295e854a4e3813ffbdef26dbb6a4d6226c3ea1 ]
    
    When holding a reader-writer spin lock we cannot sleep. Calling
    setup_udp_tunnel_sock() with write lock held violates this rule, because we
    end up calling percpu_down_read(), which might sleep, as syzbot reports
    [1]:
    
     __might_resched.cold+0x222/0x26b kernel/sched/core.c:9890
     percpu_down_read include/linux/percpu-rwsem.h:49 [inline]
     cpus_read_lock+0x1b/0x140 kernel/cpu.c:310
     static_key_slow_inc+0x12/0x20 kernel/jump_label.c:158
     udp_tunnel_encap_enable include/net/udp_tunnel.h:187 [inline]
     setup_udp_tunnel_sock+0x43d/0x550 net/ipv4/udp_tunnel_core.c:81
     l2tp_tunnel_register+0xc51/0x1210 net/l2tp/l2tp_core.c:1509
     pppol2tp_connect+0xcdc/0x1a10 net/l2tp/l2tp_ppp.c:723
    
    Trim the writer-side critical section for sk_callback_lock down to the
    minimum, so that it covers only operations on sk_user_data.
    
    Also, when grabbing the sk_callback_lock, we always need to disable BH, as
    Eric points out. Failing to do so leads to deadlocks because we acquire
    sk_callback_lock in softirq context, which can get stuck waiting on us if:
    
    1) it runs on the same CPU, or
    
           CPU0
           ----
      lock(clock-AF_INET6);
      <Interrupt>
        lock(clock-AF_INET6);
    
    2) lock ordering leads to priority inversion
    
           CPU0                    CPU1
           ----                    ----
      lock(clock-AF_INET6);
                                   local_irq_disable();
                                   lock(&tcp_hashinfo.bhash[i].lock);
                                   lock(clock-AF_INET6);
      <Interrupt>
        lock(&tcp_hashinfo.bhash[i].lock);
    
    ... as syzbot reports [2,3]. Use the _bh variants for write_(un)lock.
    
    [1] https://lore.kernel.org/netdev/0000000000004e78ec05eda79749@google.com/
    [2] https://lore.kernel.org/netdev/000000000000e38b6605eda76f98@google.com/
    [3] https://lore.kernel.org/netdev/000000000000dfa31e05eda76f75@google.com/
    
    v2:
    - Check and set sk_user_data while holding sk_callback_lock for both
      L2TP encapsulation types (IP and UDP) (Tetsuo)
    
    Cc: Tom Parkin <tparkin@katalix.com>
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Fixes: b68777d54fac ("l2tp: Serialize access to sk_user_data with sk_callback_lock")
    Reported-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com
    Reported-by: syzbot+50680ced9e98a61f7698@syzkaller.appspotmail.com
    Reported-by: syzbot+de987172bb74a381879b@syzkaller.appspotmail.com
    Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

l2tp: prevent lockdep issue in l2tp_tunnel_register() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 17 11:01:31 2023 +0000

    l2tp: prevent lockdep issue in l2tp_tunnel_register()
    
    [ Upstream commit b9fb10d131b8c84af9bb14e2078d5c63600c7dea ]
    
    lockdep complains with the following lock/unlock sequence:
    
         lock_sock(sk);
         write_lock_bh(&sk->sk_callback_lock);
    [1]  release_sock(sk);
    [2]  write_unlock_bh(&sk->sk_callback_lock);
    
    We need to swap [1] and [2] to fix this issue.
    
    Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
    Reported-by: syzbot+bbd35b345c7cab0d9a08@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/netdev/20230114030137.672706-1-xiyou.wangcong@gmail.com/T/#m1164ff20628671b0f326a24cb106ab3239c70ce3
    Cc: Cong Wang <cong.wang@bytedance.com>
    Cc: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

l2tp: Serialize access to sk_user_data with sk_callback_lock [+ + +]
Author: Jakub Sitnicki <jakub@cloudflare.com>
Date:   Mon Nov 14 20:16:19 2022 +0100

    l2tp: Serialize access to sk_user_data with sk_callback_lock
    
    [ Upstream commit b68777d54fac21fc833ec26ea1a2a84f975ab035 ]
    
    sk->sk_user_data has multiple users, which are not compatible with each
    other. Writers must synchronize by grabbing the sk->sk_callback_lock.
    
    l2tp currently fails to grab the lock when modifying the underlying tunnel
    socket fields. Fix it by adding appropriate locking.
    
    We err on the side of safety and grab the sk_callback_lock also inside the
    sk_destruct callback overridden by l2tp, even though there should be no
    refs allowing access to the sock at the time when sk_destruct gets called.
    
    v4:
    - serialize write to sk_user_data in l2tp sk_destruct
    
    v3:
    - switch from sock lock to sk_callback_lock
    - document write-protection for sk_user_data
    
    v2:
    - update Fixes to point to origin of the bug
    - use real names in Reported/Tested-by tags
    
    Cc: Tom Parkin <tparkin@katalix.com>
    Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
    Reported-by: Haowei Yan <g1042620637@gmail.com>
    Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.10.166 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 1 08:23:27 2023 +0100

    Linux 5.10.166
    
    Link: https://lore.kernel.org/r/20230130134306.862721518@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lockref: stop doing cpu_relax in the cmpxchg loop [+ + +]
Author: Mateusz Guzik <mjguzik@gmail.com>
Date:   Fri Jan 13 19:44:47 2023 +0100

    lockref: stop doing cpu_relax in the cmpxchg loop
    
    [ Upstream commit f5fe24ef17b5fbe6db49534163e77499fb10ae8c ]
    
    On the x86-64 architecture even a failing cmpxchg grants exclusive
    access to the cacheline, making it preferable to retry the failed op
    immediately instead of stalling with the pause instruction.
    
    To illustrate the impact, below are benchmark results obtained by
    running various will-it-scale tests on top of the 6.2-rc3 kernel and
    Cascade Lake (2 sockets * 24 cores * 2 threads) CPU.
    
    All results in ops/s.  Note there is some variance in re-runs, but the
    code is consistently faster when contention is present.
    
      open3 ("Same file open/close"):
      proc          stock       no-pause
         1         805603         814942       (+%1)
         2        1054980        1054781       (-0%)
         8        1544802        1822858      (+18%)
        24        1191064        2199665      (+84%)
        48         851582        1469860      (+72%)
        96         609481        1427170     (+134%)
    
      fstat2 ("Same file fstat"):
      proc          stock       no-pause
         1        3013872        3047636       (+1%)
         2        4284687        4400421       (+2%)
         8        3257721        5530156      (+69%)
        24        2239819        5466127     (+144%)
        48        1701072        5256609     (+209%)
        96        1269157        6649326     (+423%)
    
    Additionally, a kernel with a private patch to help access() scalability:
    access2 ("Same file access"):
    
      proc          stock        patched      patched
                                             +nopause
        24        2378041        2005501      5370335  (-15% / +125%)
    
    That is, fixing the problems in access itself *reduces* scalability
    after the cacheline ping-pong only happens in lockref with the pause
    instruction.
    
    Note that fstat and access benchmarks are not currently integrated into
    will-it-scale, but interested parties can find them in pull requests to
    said project.
    
    Code at hand has a rather tortured history.  First modification showed
    up in commit d472d9d98b46 ("lockref: Relax in cmpxchg loop"), written
    with Itanium in mind.  Later it got patched up to use an arch-dependent
    macro to stop doing it on s390 where it caused a significant regression.
    Said macro had undergone revisions and was ultimately eliminated later,
    going back to cpu_relax.
    
    While I intended to only remove cpu_relax for x86-64, I got the
    following comment from Linus:
    
        I would actually prefer just removing it entirely and see if
        somebody else hollers. You have the numbers to prove it hurts on
        real hardware, and I don't think we have any numbers to the
        contrary.
    
        So I think it's better to trust the numbers and remove it as a
        failure, than say "let's just remove it on x86-64 and leave
        everybody else with the potentially broken code"
    
    Additionally, Will Deacon (maintainer of the arm64 port, one of the
    architectures previously benchmarked):
    
        So, from the arm64 side of the fence, I'm perfectly happy just
        removing the cpu_relax() calls from lockref.
    
    As such, come back full circle in history and whack it altogether.
    
    Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
    Link: https://lore.kernel.org/all/CAGudoHHx0Nqg6DE70zAVA75eV-HXfWyhVMWZ-aSeOofkA_=WdA@mail.gmail.com/
    Acked-by: Tony Luck <tony.luck@intel.com> # ia64
    Acked-by: Nicholas Piggin <npiggin@gmail.com> # powerpc
    Acked-by: Will Deacon <will@kernel.org> # arm64
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Fri Nov 25 15:37:57 2022 +0800

    memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe()
    
    [ Upstream commit 340cb392a038cf70540a4cdf2e98a247c66b6df4 ]
    
    The clk_disable_unprepare() should be called in the error handling
    of caps->has_mpddr_clk, fix it by replacing devm_clk_get and
    clk_prepare_enable by devm_clk_get_enabled.
    
    Fixes: e81b6abebc87 ("memory: add a driver for atmel ram controllers")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221125073757.3535219-1-cuigaosheng1@huawei.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

memory: mvebu-devbus: Fix missing clk_disable_unprepare in mvebu_devbus_probe() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Sat Nov 26 12:49:11 2022 +0800

    memory: mvebu-devbus: Fix missing clk_disable_unprepare in mvebu_devbus_probe()
    
    [ Upstream commit cb8fd6f75775165390ededea8799b60d93d9fe3e ]
    
    The clk_disable_unprepare() should be called in the error handling
    of devbus_get_timing_params() and of_platform_populate(), fix it by
    replacing devm_clk_get and clk_prepare_enable by devm_clk_get_enabled.
    
    Fixes: e81b6abebc87 ("memory: add a driver for atmel ram controllers")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221126044911.7226-1-cuigaosheng1@huawei.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
module: Don't wait for GOING modules [+ + +]
Author: Petr Pavlu <petr.pavlu@suse.com>
Date:   Mon Dec 5 11:35:57 2022 +0100

    module: Don't wait for GOING modules
    
    commit 0254127ab977e70798707a7a2b757c9f3c971210 upstream.
    
    During a system boot, it can happen that the kernel receives a burst of
    requests to insert the same module but loading it eventually fails
    during its init call. For instance, udev can make a request to insert
    a frequency module for each individual CPU when another frequency module
    is already loaded which causes the init function of the new module to
    return an error.
    
    Since commit 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for
    modules that have finished loading"), the kernel waits for modules in
    MODULE_STATE_GOING state to finish unloading before making another
    attempt to load the same module.
    
    This creates unnecessary work in the described scenario and delays the
    boot. In the worst case, it can prevent udev from loading drivers for
    other devices and might cause timeouts of services waiting on them and
    subsequently a failed boot.
    
    This patch attempts a different solution for the problem 6e6de3dee51a
    was trying to solve. Rather than waiting for the unloading to complete,
    it returns a different error code (-EBUSY) for modules in the GOING
    state. This should avoid the error situation that was described in
    6e6de3dee51a (user space attempting to load a dependent module because
    the -EEXIST error code would suggest to user space that the first module
    had been loaded successfully), while avoiding the delay situation too.
    
    This has been tested on linux-next since December 2022 and passes
    all kmod selftests except test 0009 with module compression enabled
    but it has been confirmed that this issue has existed and has gone
    unnoticed since prior to this commit and can also be reproduced without
    module compression with a simple usleep(5000000) on tools/modprobe.c [0].
    These failures are caused by hitting the kernel mod_concurrent_max and can
    happen either due to a self inflicted kernel module auto-loead DoS somehow
    or on a system with large CPU count and each CPU count incorrectly triggering
    many module auto-loads. Both of those issues need to be fixed in-kernel.
    
    [0] https://lore.kernel.org/all/Y9A4fiobL6IHp%2F%2FP@bombadil.infradead.org/
    
    Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading")
    Co-developed-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    [mcgrof: enhance commit log with testing and kmod test result interpretation ]
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/sched: sch_taprio: do not schedule in taprio_reset() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jan 23 08:45:52 2023 +0000

    net/sched: sch_taprio: do not schedule in taprio_reset()
    
    [ Upstream commit ea4fdbaa2f7798cb25adbe4fd52ffc6356f097bb ]
    
    As reported by syzbot and hinted by Vinicius, I should not have added
    a qdisc_synchronize() call in taprio_reset()
    
    taprio_reset() can be called with qdisc spinlock held (and BH disabled)
    as shown in included syzbot report [1].
    
    Only taprio_destroy() needed this synchronization, as explained
    in the blamed commit changelog.
    
    [1]
    
    BUG: scheduling while atomic: syz-executor150/5091/0x00000202
    2 locks held by syz-executor150/5091:
    Modules linked in:
    Preemption disabled at:
    [<0000000000000000>] 0x0
    Kernel panic - not syncing: scheduling while atomic: panic_on_warn set ...
    CPU: 1 PID: 5091 Comm: syz-executor150 Not tainted 6.2.0-rc3-syzkaller-00219-g010a74f52203 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
    Call Trace:
    <TASK>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
    panic+0x2cc/0x626 kernel/panic.c:318
    check_panic_on_warn.cold+0x19/0x35 kernel/panic.c:238
    __schedule_bug.cold+0xd5/0xfe kernel/sched/core.c:5836
    schedule_debug kernel/sched/core.c:5865 [inline]
    __schedule+0x34e4/0x5450 kernel/sched/core.c:6500
    schedule+0xde/0x1b0 kernel/sched/core.c:6682
    schedule_timeout+0x14e/0x2a0 kernel/time/timer.c:2167
    schedule_timeout_uninterruptible kernel/time/timer.c:2201 [inline]
    msleep+0xb6/0x100 kernel/time/timer.c:2322
    qdisc_synchronize include/net/sch_generic.h:1295 [inline]
    taprio_reset+0x93/0x270 net/sched/sch_taprio.c:1703
    qdisc_reset+0x10c/0x770 net/sched/sch_generic.c:1022
    dev_reset_queue+0x92/0x130 net/sched/sch_generic.c:1285
    netdev_for_each_tx_queue include/linux/netdevice.h:2464 [inline]
    dev_deactivate_many+0x36d/0x9f0 net/sched/sch_generic.c:1351
    dev_deactivate+0xed/0x1b0 net/sched/sch_generic.c:1374
    qdisc_graft+0xe4a/0x1380 net/sched/sch_api.c:1080
    tc_modify_qdisc+0xb6b/0x19a0 net/sched/sch_api.c:1689
    rtnetlink_rcv_msg+0x43e/0xca0 net/core/rtnetlink.c:6141
    netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564
    netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]
    netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356
    netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xd3/0x120 net/socket.c:734
    ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
    __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    
    Fixes: 3a415d59c1db ("net/sched: sch_taprio: fix possible use-after-free")
    Link: https://lore.kernel.org/netdev/167387581653.2747.13878941339893288655.git-patchwork-notify@kernel.org/T/
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Link: https://lore.kernel.org/r/20230123084552.574396-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: sch_taprio: fix possible use-after-free [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 13 16:48:49 2023 +0000

    net/sched: sch_taprio: fix possible use-after-free
    
    [ Upstream commit 3a415d59c1dbec9d772dbfab2d2520d98360caae ]
    
    syzbot reported a nasty crash [1] in net_tx_action() which
    made little sense until we got a repro.
    
    This repro installs a taprio qdisc, but providing an
    invalid TCA_RATE attribute.
    
    qdisc_create() has to destroy the just initialized
    taprio qdisc, and taprio_destroy() is called.
    
    However, the hrtimer used by taprio had already fired,
    therefore advance_sched() called __netif_schedule().
    
    Then net_tx_action was trying to use a destroyed qdisc.
    
    We can not undo the __netif_schedule(), so we must wait
    until one cpu serviced the qdisc before we can proceed.
    
    Many thanks to Alexander Potapenko for his help.
    
    [1]
    BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
    BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
    BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
    BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
     queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
     do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
     __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
     _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
     spin_trylock include/linux/spinlock.h:359 [inline]
     qdisc_run_begin include/net/sch_generic.h:187 [inline]
     qdisc_run+0xee/0x540 include/net/pkt_sched.h:125
     net_tx_action+0x77c/0x9a0 net/core/dev.c:5086
     __do_softirq+0x1cc/0x7fb kernel/softirq.c:571
     run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934
     smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164
     kthread+0x31b/0x430 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30
    
    Uninit was created at:
     slab_post_alloc_hook mm/slab.h:732 [inline]
     slab_alloc_node mm/slub.c:3258 [inline]
     __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970
     kmalloc_reserve net/core/skbuff.c:358 [inline]
     __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430
     alloc_skb include/linux/skbuff.h:1257 [inline]
     nlmsg_new include/net/netlink.h:953 [inline]
     netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436
     netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507
     rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg net/socket.c:734 [inline]
     ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482
     ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536
     __sys_sendmsg net/socket.c:2565 [inline]
     __do_sys_sendmsg net/socket.c:2574 [inline]
     __se_sys_sendmsg net/socket.c:2572 [inline]
     __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
    
    Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/tg3: resolve deadlock in tg3_reset_task() during EEH [+ + +]
Author: David Christensen <drc@linux.vnet.ibm.com>
Date:   Tue Jan 24 13:53:39 2023 -0500

    net/tg3: resolve deadlock in tg3_reset_task() during EEH
    
    [ Upstream commit 6c4ca03bd890566d873e3593b32d034bf2f5a087 ]
    
    During EEH error injection testing, a deadlock was encountered in the tg3
    driver when tg3_io_error_detected() was attempting to cancel outstanding
    reset tasks:
    
    crash> foreach UN bt
    ...
    PID: 159    TASK: c0000000067c6000  CPU: 8   COMMAND: "eehd"
    ...
     #5 [c00000000681f990] __cancel_work_timer at c00000000019fd18
     #6 [c00000000681fa30] tg3_io_error_detected at c00800000295f098 [tg3]
     #7 [c00000000681faf0] eeh_report_error at c00000000004e25c
    ...
    
    PID: 290    TASK: c000000036e5f800  CPU: 6   COMMAND: "kworker/6:1"
    ...
     #4 [c00000003721fbc0] rtnl_lock at c000000000c940d8
     #5 [c00000003721fbe0] tg3_reset_task at c008000002969358 [tg3]
     #6 [c00000003721fc60] process_one_work at c00000000019e5c4
    ...
    
    PID: 296    TASK: c000000037a65800  CPU: 21  COMMAND: "kworker/21:1"
    ...
     #4 [c000000037247bc0] rtnl_lock at c000000000c940d8
     #5 [c000000037247be0] tg3_reset_task at c008000002969358 [tg3]
     #6 [c000000037247c60] process_one_work at c00000000019e5c4
    ...
    
    PID: 655    TASK: c000000036f49000  CPU: 16  COMMAND: "kworker/16:2"
    ...:1
    
     #4 [c0000000373ebbc0] rtnl_lock at c000000000c940d8
     #5 [c0000000373ebbe0] tg3_reset_task at c008000002969358 [tg3]
     #6 [c0000000373ebc60] process_one_work at c00000000019e5c4
    ...
    
    Code inspection shows that both tg3_io_error_detected() and
    tg3_reset_task() attempt to acquire the RTNL lock at the beginning of
    their code blocks.  If tg3_reset_task() should happen to execute between
    the times when tg3_io_error_deteced() acquires the RTNL lock and
    tg3_reset_task_cancel() is called, a deadlock will occur.
    
    Moving tg3_reset_task_cancel() call earlier within the code block, prior
    to acquiring RTNL, prevents this from happening, but also exposes another
    deadlock issue where tg3_reset_task() may execute AFTER
    tg3_io_error_detected() has executed:
    
    crash> foreach UN bt
    PID: 159    TASK: c0000000067d2000  CPU: 9   COMMAND: "eehd"
    ...
     #4 [c000000006867a60] rtnl_lock at c000000000c940d8
     #5 [c000000006867a80] tg3_io_slot_reset at c0080000026c2ea8 [tg3]
     #6 [c000000006867b00] eeh_report_reset at c00000000004de88
    ...
    PID: 363    TASK: c000000037564000  CPU: 6   COMMAND: "kworker/6:1"
    ...
     #3 [c000000036c1bb70] msleep at c000000000259e6c
     #4 [c000000036c1bba0] napi_disable at c000000000c6b848
     #5 [c000000036c1bbe0] tg3_reset_task at c0080000026d942c [tg3]
     #6 [c000000036c1bc60] process_one_work at c00000000019e5c4
    ...
    
    This issue can be avoided by aborting tg3_reset_task() if EEH error
    recovery is already in progress.
    
    Fixes: db84bf43ef23 ("tg3: tg3_reset_task() needs to use rtnl_lock to synchronize")
    Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Link: https://lore.kernel.org/r/20230124185339.225806-1-drc@linux.vnet.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: microchip: ksz9477: port map correction in ALU table entry register [+ + +]
Author: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com>
Date:   Wed Jan 18 23:17:35 2023 +0530

    net: dsa: microchip: ksz9477: port map correction in ALU table entry register
    
    [ Upstream commit 6c977c5c2e4c5d8ad1b604724cc344e38f96fe9b ]
    
    ALU table entry 2 register in KSZ9477 have bit positions reserved for
    forwarding port map. This field is referred in ksz9477_fdb_del() for
    clearing forward port map and alu table.
    
    But current fdb_del refer ALU table entry 3 register for accessing forward
    port map. Update ksz9477_fdb_del() to get forward port map from correct
    alu table entry register.
    
    With this bug, issue can be observed while deleting static MAC entries.
    Delete any specific MAC entry using "bridge fdb del" command. This should
    clear all the specified MAC entries. But it is observed that entries with
    self static alone are retained.
    
    Tested on LAN9370 EVB since ksz9477_fdb_del() is used common across
    LAN937x and KSZ series.
    
    Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
    Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20230118174735.702377-1-rakesh.sankaranarayanan@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fix UaF in netns ops registration error path [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Jan 19 19:55:45 2023 +0100

    net: fix UaF in netns ops registration error path
    
    [ Upstream commit 71ab9c3e2253619136c31c89dbb2c69305cc89b1 ]
    
    If net_assign_generic() fails, the current error path in ops_init() tries
    to clear the gen pointer slot. Anyway, in such error path, the gen pointer
    itself has not been modified yet, and the existing and accessed one is
    smaller than the accessed index, causing an out-of-bounds error:
    
     BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
     Write of size 8 at addr ffff888109124978 by task modprobe/1018
    
     CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
     Call Trace:
      <TASK>
      dump_stack_lvl+0x6a/0x9f
      print_address_description.constprop.0+0x86/0x2b5
      print_report+0x11b/0x1fb
      kasan_report+0x87/0xc0
      ops_init+0x2de/0x320
      register_pernet_operations+0x2e4/0x750
      register_pernet_subsys+0x24/0x40
      tcf_register_action+0x9f/0x560
      do_one_initcall+0xf9/0x570
      do_init_module+0x190/0x650
      load_module+0x1fa5/0x23c0
      __do_sys_finit_module+0x10d/0x1b0
      do_syscall_64+0x58/0x80
      entry_SYSCALL_64_after_hwframe+0x72/0xdc
     RIP: 0033:0x7f42518f778d
     Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48
           89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
           ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48
     RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
     RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d
     RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003
     RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
     R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000
      </TASK>
    
    This change addresses the issue by skipping the gen pointer
    de-reference in the mentioned error-path.
    
    Found by code inspection and verified with explicit error injection
    on a kasan-enabled kernel.
    
    Fixes: d266935ac43d ("net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/cec4e0f3bb2c77ac03a6154a8508d3930beb5f0f.1674154348.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: macb: fix PTP TX timestamp failure due to packet padding [+ + +]
Author: Robert Hancock <robert.hancock@calian.com>
Date:   Mon Jan 16 15:41:33 2023 -0600

    net: macb: fix PTP TX timestamp failure due to packet padding
    
    [ Upstream commit 7b90f5a665acd46efbbfa677a3a3a18d01ad6487 ]
    
    PTP TX timestamp handling was observed to be broken with this driver
    when using the raw Layer 2 PTP encapsulation. ptp4l was not receiving
    the expected TX timestamp after transmitting a packet, causing it to
    enter a failure state.
    
    The problem appears to be due to the way that the driver pads packets
    which are smaller than the Ethernet minimum of 60 bytes. If headroom
    space was available in the SKB, this caused the driver to move the data
    back to utilize it. However, this appears to cause other data references
    in the SKB to become inconsistent. In particular, this caused the
    ptp_one_step_sync function to later (in the TX completion path) falsely
    detect the packet as a one-step SYNC packet, even when it was not, which
    caused the TX timestamp to not be processed when it should be.
    
    Using the headroom for this purpose seems like an unnecessary complexity
    as this is not a hot path in the driver, and in most cases it appears
    that there is sufficient tailroom to not require using the headroom
    anyway. Remove this usage of headroom to prevent this inconsistency from
    occurring and causing other problems.
    
    Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation")
    Signed-off-by: Robert Hancock <robert.hancock@calian.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> # on SAMA7G5
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mdio-mux-meson-g12a: force internal PHY off on mux switch [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Tue Jan 24 11:11:57 2023 +0100

    net: mdio-mux-meson-g12a: force internal PHY off on mux switch
    
    [ Upstream commit 7083df59abbc2b7500db312cac706493be0273ff ]
    
    Force the internal PHY off then on when switching to the internal path.
    This fixes problems where the PHY ID is not properly set.
    
    Fixes: 7090425104db ("net: phy: add amlogic g12a mdio mux support")
    Suggested-by: Qi Duan <qi.duan@amlogic.com>
    Co-developed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20230124101157.232234-1-jbrunet@baylibre.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mdio: validate parameter addr in mdiobus_get_phy() [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jan 15 11:54:06 2023 +0100

    net: mdio: validate parameter addr in mdiobus_get_phy()
    
    [ Upstream commit 867dbe784c5010a466f00a7d1467c1c5ea569c75 ]
    
    The caller may pass any value as addr, what may result in an out-of-bounds
    access to array mdio_map. One existing case is stmmac_init_phy() that
    may pass -1 as addr. Therefore validate addr before using it.
    
    Fixes: 7f854420fbfe ("phy: Add API for {un}registering an mdio device to a bus.")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/cdf664ea-3312-e915-73f8-021678d08887@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mlx5: eliminate anonymous module_init & module_exit [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Aug 30 20:12:29 2022 -0700

    net: mlx5: eliminate anonymous module_init & module_exit
    
    [ Upstream commit 2c1e1b949024989e20907b84e11a731a50778416 ]
    
    Eliminate anonymous module_init() and module_exit(), which can lead to
    confusion or ambiguity when reading System.map, crashes/oops/bugs,
    or an initcall_debug log.
    
    Give each of these init and exit functions unique driver-specific
    names to eliminate the anonymous names.
    
    Example 1: (System.map)
     ffffffff832fc78c t init
     ffffffff832fc79e t init
     ffffffff832fc8f8 t init
    
    Example 2: (initcall_debug log)
     calling  init+0x0/0x12 @ 1
     initcall init+0x0/0x12 returned 0 after 15 usecs
     calling  init+0x0/0x60 @ 1
     initcall init+0x0/0x60 returned 0 after 2 usecs
     calling  init+0x0/0x9a @ 1
     initcall init+0x0/0x9a returned 0 after 74 usecs
    
    Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Eli Cohen <eli@mellanox.com>
    Cc: Saeed Mahameed <saeedm@nvidia.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: linux-rdma@vger.kernel.org
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: nfc: Fix use-after-free in local_cleanup() [+ + +]
Author: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Date:   Wed Jan 11 22:19:14 2023 +0900

    net: nfc: Fix use-after-free in local_cleanup()
    
    [ Upstream commit 4bb4db7f3187c6e3de6b229ffc87cdb30a2d22b6 ]
    
    Fix a use-after-free that occurs in kfree_skb() called from
    local_cleanup(). This could happen when killing nfc daemon (e.g. neard)
    after detaching an nfc device.
    When detaching an nfc device, local_cleanup() called from
    nfc_llcp_unregister_device() frees local->rx_pending and decreases
    local->ref by kref_put() in nfc_llcp_local_put().
    In the terminating process, nfc daemon releases all sockets and it leads
    to decreasing local->ref. After the last release of local->ref,
    local_cleanup() called from local_release() frees local->rx_pending
    again, which leads to the bug.
    
    Setting local->rx_pending to NULL in local_cleanup() could prevent
    use-after-free when local_cleanup() is called twice.
    
    Found by a modified version of syzkaller.
    
    BUG: KASAN: use-after-free in kfree_skb()
    
    Call Trace:
    dump_stack_lvl (lib/dump_stack.c:106)
    print_address_description.constprop.0.cold (mm/kasan/report.c:306)
    kasan_check_range (mm/kasan/generic.c:189)
    kfree_skb (net/core/skbuff.c:955)
    local_cleanup (net/nfc/llcp_core.c:159)
    nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)
    nfc_llcp_local_put (net/nfc/llcp_core.c:181)
    llcp_sock_destruct (net/nfc/llcp_sock.c:959)
    __sk_destruct (net/core/sock.c:2133)
    sk_destruct (net/core/sock.c:2181)
    __sk_free (net/core/sock.c:2192)
    sk_free (net/core/sock.c:2203)
    llcp_sock_release (net/nfc/llcp_sock.c:646)
    __sock_release (net/socket.c:650)
    sock_close (net/socket.c:1365)
    __fput (fs/file_table.c:306)
    task_work_run (kernel/task_work.c:179)
    ptrace_notify (kernel/signal.c:2354)
    syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)
    syscall_exit_to_user_mode (kernel/entry/common.c:296)
    do_syscall_64 (arch/x86/entry/common.c:86)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
    
    Allocated by task 4719:
    kasan_save_stack (mm/kasan/common.c:45)
    __kasan_slab_alloc (mm/kasan/common.c:325)
    slab_post_alloc_hook (mm/slab.h:766)
    kmem_cache_alloc_node (mm/slub.c:3497)
    __alloc_skb (net/core/skbuff.c:552)
    pn533_recv_response (drivers/nfc/pn533/usb.c:65)
    __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)
    usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)
    tasklet_action_common.isra.0 (kernel/softirq.c:797)
    __do_softirq (kernel/softirq.c:571)
    
    Freed by task 1901:
    kasan_save_stack (mm/kasan/common.c:45)
    kasan_set_track (mm/kasan/common.c:52)
    kasan_save_free_info (mm/kasan/genericdd.c:518)
    __kasan_slab_free (mm/kasan/common.c:236)
    kmem_cache_free (mm/slub.c:3809)
    kfree_skbmem (net/core/skbuff.c:874)
    kfree_skb (net/core/skbuff.c:931)
    local_cleanup (net/nfc/llcp_core.c:159)
    nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)
    nfc_unregister_device (net/nfc/core.c:1179)
    pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)
    pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)
    usb_unbind_interface (drivers/usb/core/driver.c:458)
    device_release_driver_internal (drivers/base/dd.c:1279)
    bus_remove_device (drivers/base/bus.c:529)
    device_del (drivers/base/core.c:3665)
    usb_disable_device (drivers/usb/core/message.c:1420)
    usb_disconnect (drivers/usb/core.c:2261)
    hub_event (drivers/usb/core/hub.c:5833)
    process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)
    worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)
    kthread (kernel/kthread.c:319)
    ret_from_fork (arch/x86/entry/entry_64.S:301)
    
    Fixes: 3536da06db0b ("NFC: llcp: Clean local timers and works when removing a device")
    Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
    Link: https://lore.kernel.org/r/20230111131914.3338838-1-jisoo.jang@yonsei.ac.kr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ravb: Fix possible hang if RIS2_QFF1 happen [+ + +]
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Jan 24 09:02:11 2023 +0900

    net: ravb: Fix possible hang if RIS2_QFF1 happen
    
    [ Upstream commit f3c07758c9007a6bfff5290d9e19d3c41930c897 ]
    
    Since this driver enables the interrupt by RIC2_QFE1, this driver
    should clear the interrupt flag if it happens. Otherwise, the interrupt
    causes to hang the system.
    
    Note that this also fix a minor coding style (a comment indentation)
    around the fixed code.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: fix invalid call to mdiobus_get_phy() [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jan 15 18:24:08 2023 +0100

    net: stmmac: fix invalid call to mdiobus_get_phy()
    
    [ Upstream commit 1f3bd64ad921f051254591fbed04fd30b306cde6 ]
    
    In a number of cases the driver assigns a default value of -1 to
    priv->plat->phy_addr. This may result in calling mdiobus_get_phy()
    with addr parameter being -1. Therefore check for this scenario and
    bail out before calling mdiobus_get_phy().
    
    Fixes: 42e87024f727 ("net: stmmac: Fix case when PHY handle is not present")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/669f9671-ecd1-a41b-2727-7b73e3003985@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: sr9700: Handle negative len [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Sat Jan 14 19:23:26 2023 +0100

    net: usb: sr9700: Handle negative len
    
    [ Upstream commit ecf7cf8efb59789e2b21d2f9ab926142579092b2 ]
    
    Packet len computed as difference of length word extracted from
    skb data and four may result in a negative value. In such case
    processing of the buffer should be interrupted rather than
    setting sr_skb->len to an unexpectedly large value (due to cast
    from signed to unsigned integer) and passing sr_skb to
    usbnet_skb_return.
    
    Fixes: e9da0b56fe27 ("sr9700: sanity check for packet length")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Link: https://lore.kernel.org/r/20230114182326.30479-1-szymon.heidrich@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs [+ + +]
Author: Esina Ekaterina <eesina@astralinux.ru>
Date:   Thu Jan 12 10:47:03 2023 +0300

    net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
    
    [ Upstream commit 488e0bf7f34af3d42d1d5e56f7a5a7beaff188a3 ]
    
    If uhdlc_priv_tsa != 1 then utdm is not initialized.
    And if ret != NULL then goto undo_uhdlc_init, where
    utdm is dereferenced. Same if dev == NULL.
    
    Found by Astra Linux on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: 8d68100ab4ad ("soc/fsl/qe: fix err handling of ucc_of_parse_tdm")
    Signed-off-by: Esina Ekaterina <eesina@astralinux.ru>
    Link: https://lore.kernel.org/r/20230112074703.13558-1-eesina@astralinux.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: conntrack: do not renew entry stuck in tcp SYN_SENT state [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Jun 24 12:36:42 2021 +0200

    netfilter: conntrack: do not renew entry stuck in tcp SYN_SENT state
    
    [ Upstream commit e15d4cdf27cb0c1e977270270b2cea12e0955edd ]
    
    Consider:
      client -----> conntrack ---> Host
    
    client sends a SYN, but $Host is unreachable/silent.
    Client eventually gives up and the conntrack entry will time out.
    
    However, if the client is restarted with same addr/port pair, it
    may prevent the conntrack entry from timing out.
    
    This is noticeable when the existing conntrack entry has no NAT
    transformation or an outdated one and port reuse happens either
    on client or due to a NAT middlebox.
    
    This change prevents refresh of the timeout for SYN retransmits,
    so entry is going away after nf_conntrack_tcp_timeout_syn_sent
    seconds (default: 60).
    
    Entry will be re-created on next connection attempt, but then
    nat rules will be evaluated again.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE [+ + +]
Author: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
Date:   Tue Jan 24 02:47:18 2023 +0100

    netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE
    
    [ Upstream commit a9993591fa94246b16b444eea55d84c54608282a ]
    
    RFC 9260, Sec 8.5.1 states that for ABORT/SHUTDOWN_COMPLETE, the chunk
    MUST be accepted if the vtag of the packet matches its own tag and the
    T bit is not set OR if it is set to its peer's vtag and the T bit is set
    in chunk flags. Otherwise the packet MUST be silently dropped.
    
    Update vtag verification for ABORT/SHUTDOWN_COMPLETE based on the above
    description.
    
    Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
    Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: conntrack: unify established states for SCTP paths [+ + +]
Author: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
Date:   Tue Jan 24 02:47:21 2023 +0100

    netfilter: conntrack: unify established states for SCTP paths
    
    commit a44b7651489f26271ac784b70895e8a85d0cebf4 upstream.
    
    An SCTP endpoint can start an association through a path and tear it
    down over another one. That means the initial path will not see the
    shutdown sequence, and the conntrack entry will remain in ESTABLISHED
    state for 5 days.
    
    By merging the HEARTBEAT_ACKED and ESTABLISHED states into one
    ESTABLISHED state, there remains no difference between a primary or
    secondary path. The timeout for the merged ESTABLISHED state is set to
    210 seconds (hb_interval * max_path_retrans + rto_max). So, even if a
    path doesn't see the shutdown sequence, it will expire in a reasonable
    amount of time.
    
    With this change in place, there is now more than one state from which
    we can transition to ESTABLISHED, COOKIE_ECHOED and HEARTBEAT_SENT, so
    handle the setting of ASSURED bit whenever a state change has happened
    and the new state is ESTABLISHED. Removed the check for dir==REPLY since
    the transition to ESTABLISHED can happen only in the reply direction.
    
    Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
    Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nft_set_rbtree: skip elements in transaction from garbage collection [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Jan 14 23:49:46 2023 +0100

    netfilter: nft_set_rbtree: skip elements in transaction from garbage collection
    
    [ Upstream commit 5d235d6ce75c12a7fdee375eb211e4116f7ab01b ]
    
    Skip interference with an ongoing transaction, do not perform garbage
    collection on inactive elements. Reset annotated previous end interval
    if the expired element is marked as busy (control plane removed the
    element right before expiration).
    
    Fixes: 8d8540c4f5e0 ("netfilter: nft_set_rbtree: add timeout support")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_rbtree: Switch to node list walk for overlap detection [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Jan 14 23:38:32 2023 +0100

    netfilter: nft_set_rbtree: Switch to node list walk for overlap detection
    
    [ Upstream commit c9e6978e2725a7d4b6cd23b2facd3f11422c0643 ]
    
    ...instead of a tree descent, which became overly complicated in an
    attempt to cover cases where expired or inactive elements would affect
    comparisons with the new element being inserted.
    
    Further, it turned out that it's probably impossible to cover all those
    cases, as inactive nodes might entirely hide subtrees consisting of a
    complete interval plus a node that makes the current insertion not
    overlap.
    
    To speed up the overlap check, descent the tree to find a greater
    element that is closer to the key value to insert. Then walk down the
    node list for overlap detection. Starting the overlap check from
    rb_first() unconditionally is slow, it takes 10 times longer due to the
    full linear traversal of the list.
    
    Moreover, perform garbage collection of expired elements when walking
    down the node list to avoid bogus overlap reports.
    
    For the insertion operation itself, this essentially reverts back to the
    implementation before commit 7c84d41416d8 ("netfilter: nft_set_rbtree:
    Detect partial overlaps on insertion"), except that cases of complete
    overlap are already handled in the overlap detection phase itself, which
    slightly simplifies the loop to find the insertion point.
    
    Based on initial patch from Stefano Brivio, including text from the
    original patch description too.
    
    Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netlink: annotate data races around dst_portid and dst_group [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 12:59:54 2023 +0000

    netlink: annotate data races around dst_portid and dst_group
    
    [ Upstream commit 004db64d185a5f23dfb891d7701e23713b2420ee ]
    
    netlink_getname(), netlink_sendmsg() and netlink_getsockbyportid()
    can read nlk->dst_portid and nlk->dst_group while another
    thread is changing them.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netlink: annotate data races around nlk->portid [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 12:59:53 2023 +0000

    netlink: annotate data races around nlk->portid
    
    [ Upstream commit c1bb9484e3b05166880da8574504156ccbd0549e ]
    
    syzbot reminds us netlink_getname() runs locklessly [1]
    
    This first patch annotates the race against nlk->portid.
    
    Following patches take care of the remaining races.
    
    [1]
    BUG: KCSAN: data-race in netlink_getname / netlink_insert
    
    write to 0xffff88814176d310 of 4 bytes by task 2315 on cpu 1:
    netlink_insert+0xf1/0x9a0 net/netlink/af_netlink.c:583
    netlink_autobind+0xae/0x180 net/netlink/af_netlink.c:856
    netlink_sendmsg+0x444/0x760 net/netlink/af_netlink.c:1895
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg net/socket.c:734 [inline]
    ____sys_sendmsg+0x38f/0x500 net/socket.c:2476
    ___sys_sendmsg net/socket.c:2530 [inline]
    __sys_sendmsg+0x19a/0x230 net/socket.c:2559
    __do_sys_sendmsg net/socket.c:2568 [inline]
    __se_sys_sendmsg net/socket.c:2566 [inline]
    __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff88814176d310 of 4 bytes by task 2316 on cpu 0:
    netlink_getname+0xcd/0x1a0 net/netlink/af_netlink.c:1144
    __sys_getsockname+0x11d/0x1b0 net/socket.c:2026
    __do_sys_getsockname net/socket.c:2041 [inline]
    __se_sys_getsockname net/socket.c:2038 [inline]
    __x64_sys_getsockname+0x3e/0x50 net/socket.c:2038
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x00000000 -> 0xc9a49780
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 2316 Comm: syz-executor.2 Not tainted 6.2.0-rc3-syzkaller-00030-ge8f60cd7db24-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netlink: annotate data races around sk_state [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 12:59:55 2023 +0000

    netlink: annotate data races around sk_state
    
    [ Upstream commit 9b663b5cbb15b494ef132a3c937641c90646eb73 ]
    
    netlink_getsockbyportid() reads sk_state while a concurrent
    netlink_connect() can change its value.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netlink: prevent potential spectre v1 gadgets [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 19 11:01:50 2023 +0000

    netlink: prevent potential spectre v1 gadgets
    
    [ Upstream commit f0950402e8c76e7dcb08563f1b4e8000fbc62455 ]
    
    Most netlink attributes are parsed and validated from
    __nla_validate_parse() or validate_nla()
    
        u16 type = nla_type(nla);
    
        if (type == 0 || type > maxtype) {
            /* error or continue */
        }
    
    @type is then used as an array index and can be used
    as a Spectre v1 gadget.
    
    array_index_nospec() can be used to prevent leaking
    content of kernel memory to malicious users.
    
    This should take care of vast majority of netlink uses,
    but an audit is needed to take care of others where
    validation is not yet centralized in core netlink functions.
    
    Fixes: bfa83a9e03cf ("[NETLINK]: Type-safe netlink messages/attributes interface")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230119110150.2678537-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netrom: Fix use-after-free of a listening socket. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Fri Jan 20 15:19:27 2023 -0800

    netrom: Fix use-after-free of a listening socket.
    
    [ Upstream commit 409db27e3a2eb5e8ef7226ca33be33361b3ed1c9 ]
    
    syzbot reported a use-after-free in do_accept(), precisely nr_accept()
    as sk_prot_alloc() allocated the memory and sock_put() frees it. [0]
    
    The issue could happen if the heartbeat timer is fired and
    nr_heartbeat_expiry() calls nr_destroy_socket(), where a socket
    has SOCK_DESTROY or a listening socket has SOCK_DEAD.
    
    In this case, the first condition cannot be true.  SOCK_DESTROY is
    flagged in nr_release() only when the file descriptor is close()d,
    but accept() is being called for the listening socket, so the second
    condition must be true.
    
    Usually, the AF_NETROM listener neither starts timers nor sets
    SOCK_DEAD.  However, the condition is met if connect() fails before
    listen().  connect() starts the t1 timer and heartbeat timer, and
    t1timer calls nr_disconnect() when timeout happens.  Then, SOCK_DEAD
    is set, and if we call listen(), the heartbeat timer calls
    nr_destroy_socket().
    
      nr_connect
        nr_establish_data_link(sk)
          nr_start_t1timer(sk)
        nr_start_heartbeat(sk)
                                        nr_t1timer_expiry
                                          nr_disconnect(sk, ETIMEDOUT)
                                            nr_sk(sk)->state = NR_STATE_0
                                            sk->sk_state = TCP_CLOSE
                                            sock_set_flag(sk, SOCK_DEAD)
    nr_listen
      if (sk->sk_state != TCP_LISTEN)
        sk->sk_state = TCP_LISTEN
                                        nr_heartbeat_expiry
                                          switch (nr->state)
                                          case NR_STATE_0
                                            if (sk->sk_state == TCP_LISTEN &&
                                                sock_flag(sk, SOCK_DEAD))
                                              nr_destroy_socket(sk)
    
    This path seems expected, and nr_destroy_socket() is called to clean
    up resources.  Initially, there was sock_hold() before nr_destroy_socket()
    so that the socket would not be freed, but the commit 517a16b1a88b
    ("netrom: Decrease sock refcount when sock timers expire") accidentally
    removed it.
    
    To fix use-after-free, let's add sock_hold().
    
    [0]:
    BUG: KASAN: use-after-free in do_accept+0x483/0x510 net/socket.c:1848
    Read of size 8 at addr ffff88807978d398 by task syz-executor.3/5315
    
    CPU: 0 PID: 5315 Comm: syz-executor.3 Not tainted 6.2.0-rc3-syzkaller-00165-gd9fc1511728c #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:306 [inline]
     print_report+0x15e/0x461 mm/kasan/report.c:417
     kasan_report+0xbf/0x1f0 mm/kasan/report.c:517
     do_accept+0x483/0x510 net/socket.c:1848
     __sys_accept4_file net/socket.c:1897 [inline]
     __sys_accept4+0x9a/0x120 net/socket.c:1927
     __do_sys_accept net/socket.c:1944 [inline]
     __se_sys_accept net/socket.c:1941 [inline]
     __x64_sys_accept+0x75/0xb0 net/socket.c:1941
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fa436a8c0c9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fa437784168 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
    RAX: ffffffffffffffda RBX: 00007fa436bac050 RCX: 00007fa436a8c0c9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
    RBP: 00007fa436ae7ae9 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffebc6700df R14: 00007fa437784300 R15: 0000000000022000
     </TASK>
    
    Allocated by task 5294:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     ____kasan_kmalloc mm/kasan/common.c:371 [inline]
     ____kasan_kmalloc mm/kasan/common.c:330 [inline]
     __kasan_kmalloc+0xa3/0xb0 mm/kasan/common.c:380
     kasan_kmalloc include/linux/kasan.h:211 [inline]
     __do_kmalloc_node mm/slab_common.c:968 [inline]
     __kmalloc+0x5a/0xd0 mm/slab_common.c:981
     kmalloc include/linux/slab.h:584 [inline]
     sk_prot_alloc+0x140/0x290 net/core/sock.c:2038
     sk_alloc+0x3a/0x7a0 net/core/sock.c:2091
     nr_create+0xb6/0x5f0 net/netrom/af_netrom.c:433
     __sock_create+0x359/0x790 net/socket.c:1515
     sock_create net/socket.c:1566 [inline]
     __sys_socket_create net/socket.c:1603 [inline]
     __sys_socket_create net/socket.c:1588 [inline]
     __sys_socket+0x133/0x250 net/socket.c:1636
     __do_sys_socket net/socket.c:1649 [inline]
     __se_sys_socket net/socket.c:1647 [inline]
     __x64_sys_socket+0x73/0xb0 net/socket.c:1647
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Freed by task 14:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:518
     ____kasan_slab_free mm/kasan/common.c:236 [inline]
     ____kasan_slab_free+0x13b/0x1a0 mm/kasan/common.c:200
     kasan_slab_free include/linux/kasan.h:177 [inline]
     __cache_free mm/slab.c:3394 [inline]
     __do_kmem_cache_free mm/slab.c:3580 [inline]
     __kmem_cache_free+0xcd/0x3b0 mm/slab.c:3587
     sk_prot_free net/core/sock.c:2074 [inline]
     __sk_destruct+0x5df/0x750 net/core/sock.c:2166
     sk_destruct net/core/sock.c:2181 [inline]
     __sk_free+0x175/0x460 net/core/sock.c:2192
     sk_free+0x7c/0xa0 net/core/sock.c:2203
     sock_put include/net/sock.h:1991 [inline]
     nr_heartbeat_expiry+0x1d7/0x460 net/netrom/nr_timer.c:148
     call_timer_fn+0x1da/0x7c0 kernel/time/timer.c:1700
     expire_timers+0x2c6/0x5c0 kernel/time/timer.c:1751
     __run_timers kernel/time/timer.c:2022 [inline]
     __run_timers kernel/time/timer.c:1995 [inline]
     run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035
     __do_softirq+0x1fb/0xadc kernel/softirq.c:571
    
    Fixes: 517a16b1a88b ("netrom: Decrease sock refcount when sock timers expire")
    Reported-by: syzbot+5fafd5cfe1fc91f6b352@syzkaller.appspotmail.com
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20230120231927.51711-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfsd: Ensure knfsd shuts down when the "nfsd" pseudofs is unmounted [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat Mar 13 16:08:47 2021 -0500

    nfsd: Ensure knfsd shuts down when the "nfsd" pseudofs is unmounted
    
    commit c6c7f2a84da459bcc3714044e74a9cb66de31039 upstream.
    
    In order to ensure that knfsd threads don't linger once the nfsd
    pseudofs is unmounted (e.g. when the container is killed) we let
    nfsd_umount() shut down those threads and wait for them to exit.
    
    This also should ensure that we don't need to do a kernel mount of
    the pseudofs, since the thread lifetime is now limited by the
    lifetime of the filesystem.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf [+ + +]
Author: Karol Herbst <kherbst@redhat.com>
Date:   Fri Aug 19 22:09:28 2022 +0200

    nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf
    
    commit 6b04ce966a738ecdd9294c9593e48513c0dc90aa upstream.
    
    It is a bit unlcear to us why that's helping, but it does and unbreaks
    suspend/resume on a lot of GPUs without any known drawbacks.
    
    Cc: stable@vger.kernel.org # v5.15+
    Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220819200928.401416-1-kherbst@redhat.com
    Cc: Salvatore Bonaccorso <carnil@debian.org>
    Cc: Computer Enthusiastic <computer.enthusiastic@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvme-pci: fix timeout request state check [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Wed Jan 18 08:44:16 2023 -0800

    nvme-pci: fix timeout request state check
    
    [ Upstream commit 1c5842085851f786eba24a39ecd02650ad892064 ]
    
    Polling the completion can progress the request state to IDLE, either
    inline with the completion, or through softirq. Either way, the state
    may not be COMPLETED, so don't check for that. We only care if the state
    isn't IN_FLIGHT.
    
    This is fixing an issue where the driver aborts an IO that we just
    completed. Seeing the "aborting" message instead of "polled" is very
    misleading as to where the timeout problem resides.
    
    Fixes: bf392a5dc02a9b ("nvme-pci: Remove tag from process cq")
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
objtool: Add a missing comma to avoid string concatenation [+ + +]
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Jan 24 11:29:51 2023 -0800

    objtool: Add a missing comma to avoid string concatenation
    
    commit 1fb466dff904e4a72282af336f2c355f011eec61 upstream.
    
    Recently the kbuild robot reported two new errors:
    
    >> lib/kunit/kunit-example-test.o: warning: objtool: .text.unlikely: unexpected end of section
    >> arch/x86/kernel/dumpstack.o: warning: objtool: oops_end() falls through to next function show_opcodes()
    
    I don't know why they did not occur in my test setup but after digging
    it I realized I had accidentally dropped a comma in
    tools/objtool/check.c when I renamed rewind_stack_do_exit to
    rewind_stack_and_make_dead.
    
    Add that comma back to fix objtool errors.
    
    Link: https://lkml.kernel.org/r/202112140949.Uq5sFKR1-lkp@intel.com
    Fixes: 0e25498f8cd4 ("exit: Add and use make_task_dead.")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
panic: Consolidate open-coded panic_on_warn checks [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:30:00 2023 -0800

    panic: Consolidate open-coded panic_on_warn checks
    
    commit 79cc1ba7badf9e7a12af99695a557e9ce27ee967 upstream.
    
    Several run-time checkers (KASAN, UBSAN, KFENCE, KCSAN, sched) roll
    their own warnings, and each check "panic_on_warn". Consolidate this
    into a single function so that future instrumentation can be added in
    a single location.
    
    Cc: Marco Elver <elver@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ben Segall <bsegall@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: Valentin Schneider <vschneid@redhat.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: David Gow <davidgow@google.com>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: "Paul E. McKenney" <paulmck@kernel.org>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: kasan-dev@googlegroups.com
    Cc: linux-mm@kvack.org
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Marco Elver <elver@google.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
    Link: https://lore.kernel.org/r/20221117234328.594699-4-keescook@chromium.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

panic: Expose "warn_count" to sysfs [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:30:02 2023 -0800

    panic: Expose "warn_count" to sysfs
    
    commit 8b05aa26336113c4cea25f1c333ee8cd4fc212a6 upstream.
    
    Since Warn count is now tracked and is a fairly interesting signal, add
    the entry /sys/kernel/warn_count to expose it to userspace.
    
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-6-keescook@chromium.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

panic: Introduce warn_limit [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:30:01 2023 -0800

    panic: Introduce warn_limit
    
    commit 9fc9e278a5c0b708eeffaf47d6eb0c82aa74ed78 upstream.
    
    Like oops_limit, add warn_limit for limiting the number of warnings when
    panic_on_warn is not set.
    
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: Eric Biggers <ebiggers@google.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: linux-doc@vger.kernel.org
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-5-keescook@chromium.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

panic: Separate sysctl logic from CONFIG_SMP [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 11:29:56 2023 -0800

    panic: Separate sysctl logic from CONFIG_SMP
    
    commit 9360d035a579d95d1e76c471061b9065b18a0eb1 upstream.
    
    In preparation for adding more sysctls directly in kernel/panic.c, split
    CONFIG_SMP from the logic that adds sysctls.
    
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: tangmeng <tangmeng@uniontech.com>
    Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221117234328.594699-1-keescook@chromium.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

panic: unset panic_on_warn inside panic() [+ + +]
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Jan 24 11:29:47 2023 -0800

    panic: unset panic_on_warn inside panic()
    
    commit 1a2383e8b84c0451fd9b1eec3b9aab16f30b597c upstream.
    
    In the current code, the following three places need to unset
    panic_on_warn before calling panic() to avoid recursive panics:
    
    kernel/kcsan/report.c: print_report()
    kernel/sched/core.c: __schedule_bug()
    mm/kfence/report.c: kfence_report_error()
    
    In order to avoid copy-pasting "panic_on_warn = 0" all over the places,
    it is better to move it inside panic() and then remove it from the other
    places.
    
    Link: https://lkml.kernel.org/r/1644324666-15947-4-git-send-email-yangtiezhu@loongson.cn
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Reviewed-by: Marco Elver <elver@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Xuefeng Li <lixuefeng@loongson.cn>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86/amd: fix potential integer overflow on shift of a int [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Fri Dec 2 13:51:49 2022 +0000

    perf/x86/amd: fix potential integer overflow on shift of a int
    
    commit 08245672cdc6505550d1a5020603b0a8d4a6dcc7 upstream.
    
    The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
    arithmetic and then passed as a 64 bit function argument. In the case where
    i is 32 or more this can lead to an overflow.  Avoid this by shifting
    using the BIT_ULL macro instead.
    
    Fixes: 471af006a747 ("perf/x86/amd: Constrain Large Increment per Cycle events")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Ian Rogers <irogers@google.com>
    Acked-by: Kim Phillips <kim.phillips@amd.com>
    Link: https://lore.kernel.org/r/20221202135149.1797974-1-colin.i.king@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
phy: rockchip-inno-usb2: Fix missing clk_disable_unprepare() in rockchip_usb2phy_power_on() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Mon Dec 5 19:58:23 2022 +0800

    phy: rockchip-inno-usb2: Fix missing clk_disable_unprepare() in rockchip_usb2phy_power_on()
    
    [ Upstream commit 5daba914da0e48950e9407ea4d75fa57029c9adc ]
    
    The clk_disable_unprepare() should be called in the error handling of
    rockchip_usb2phy_power_on().
    
    Fixes: 0e08d2a727e6 ("phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Link: https://lore.kernel.org/r/20221205115823.16957-1-shangxiaojing@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: ti: fix Kconfig warning and operator precedence [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Jan 9 22:25:29 2023 -0800

    phy: ti: fix Kconfig warning and operator precedence
    
    [ Upstream commit 7124c93887cc4e6c5b48920f83115e4a5892e870 ]
    
    Fix Kconfig depends operator precedence to prevent a Kconfig warning:
    
    WARNING: unmet direct dependencies detected for MUX_MMIO
      Depends on [n]: MULTIPLEXER [=m] && OF [=n]
      Selected by [m]:
      - PHY_AM654_SERDES [=m] && (OF [=n] && ARCH_K3 || COMPILE_TEST [=y]) && COMMON_CLK [=y]
    
    Fixes: 71e2f5c5c224 ("phy: ti: Add a new SERDES driver for TI's AM654x SoC")
    Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: Kishon Vijay Abraham I <kishon@kernel.org>
    Cc: linux-phy@lists.infradead.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20230110062529.22668-1-rdunlap@infradead.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: asus-nb-wmi: Add alternate mapping for KEY_SCREENLOCK [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 12 19:18:41 2023 +0100

    platform/x86: asus-nb-wmi: Add alternate mapping for KEY_SCREENLOCK
    
    [ Upstream commit db9494895b405bf318dc7e563dee6daa51b3b6ed ]
    
    The 0x33 keycode is emitted by Fn + F6 on a ASUS FX705GE laptop.
    
    Reported-by: Nemcev Aleksey <Nemcev_Aleksey@inbox.ru>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230112181841.84652-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: touchscreen_dmi: Add info for the CSL Panther Tab HD [+ + +]
Author: Michael Klein <m.klein@mvz-labor-lb.de>
Date:   Tue Dec 20 13:11:03 2022 +0100

    platform/x86: touchscreen_dmi: Add info for the CSL Panther Tab HD
    
    [ Upstream commit 36c2b9d6710427f802494ba070621cb415198293 ]
    
    Add touchscreen info for the CSL Panther Tab HD.
    
    Signed-off-by: Michael Klein <m.klein@mvz-labor-lb.de>
    Link: https://lore.kernel.org/r/20221220121103.uiwn5l7fii2iggct@LLGMVZLB-0037
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM: AVS: qcom-cpr: Fix an error handling path in cpr_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 17 17:05:41 2022 +0100

    PM: AVS: qcom-cpr: Fix an error handling path in cpr_probe()
    
    [ Upstream commit 6049aae52392539e505bfb8ccbcff3c26f1d2f0b ]
    
    If an error occurs after a successful pm_genpd_init() call, it should be
    undone by a corresponding pm_genpd_remove().
    
    Add the missing call in the error handling path, as already done in the
    remove function.
    
    Fixes: bf6910abf548 ("power: avs: Add support for CPR (Core Power Reduction)")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/0f520597dbad89ab99c217c8986912fa53eaf5f9.1671293108.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/core: Fix ib block iterator counter overflow [+ + +]
Author: Yonatan Nachum <ynachum@amazon.com>
Date:   Mon Jan 9 13:37:11 2023 +0000

    RDMA/core: Fix ib block iterator counter overflow
    
    [ Upstream commit 0afec5e9cea732cb47014655685a2a47fb180c31 ]
    
    When registering a new DMA MR after selecting the best aligned page size
    for it, we iterate over the given sglist to split each entry to smaller,
    aligned to the selected page size, DMA blocks.
    
    In given circumstances where the sg entry and page size fit certain
    sizes and the sg entry is not aligned to the selected page size, the
    total size of the aligned pages we need to cover the sg entry is >= 4GB.
    Under this circumstances, while iterating page aligned blocks, the
    counter responsible for counting how much we advanced from the start of
    the sg entry is overflowed because its type is u32 and we pass 4GB in
    size. This can lead to an infinite loop inside the iterator function
    because the overflow prevents the counter to be larger
    than the size of the sg entry.
    
    Fix the presented problem by changing the advancement condition to
    eliminate overflow.
    
    Backtrace:
    [  192.374329] efa_reg_user_mr_dmabuf
    [  192.376783] efa_register_mr
    [  192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000
    [  192.386423] pg_sz [0x80000000] umem_length[0xc0000000]
    [  192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3
    [  192.399559] hp_cnt[3], pages_in_hp[524288]
    [  192.403690] umem->sgt_append.sgt.nents[1]
    [  192.407905] number entries: [1], pg_bit: [31]
    [  192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
    [  192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472]
    [  192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
    [  192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472]
    [  192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
    [  192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472]
    
    Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks")
    Signed-off-by: Yonatan Nachum <ynachum@amazon.com>
    Link: https://lore.kernel.org/r/20230109133711.13678-1-ynachum@amazon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode" [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Dec 16 13:15:34 2022 -0800

    Revert "Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode"
    
    commit 3c44e2b6cde674797b76e76d3a903a63ce8a18bb upstream.
    
    This reverts commit ac5408991ea6b06e29129b4d4861097c4c3e0d59 because
    it causes loss of keyboard on HP 15-da1xxx.
    
    Fixes: ac5408991ea6 ("Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode")
    Reported-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/824effa5-8b9a-c28a-82bb-9b0ab24623e1@kernel.org
    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1206358
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID" [+ + +]
Author: Sasha Levin <sashal@kernel.org>
Date:   Tue Jan 24 07:02:31 2023 -0500

    Revert "selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID"
    
    This reverts commit 3093027183f2846365a76b2fb1e1309f1960084a.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "selftests/ftrace: Update synthetic event syntax errors" [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Tue Jan 17 20:47:09 2023 +0800

    Revert "selftests/ftrace: Update synthetic event syntax errors"
    
    This reverts commit 31c2e369b5335d70e913afee3ae11e54d61afef2 which is commit
    b5734e997e1117afb479ffda500e36fa91aea3e8 upstream.
    
    The reverted commit belongs to patchset which updated synthetic event
    command parsing and testcase 'trigger-synthetic_event_syntax_errors.tc'
    Link: https://lore.kernel.org/all/20210211020950.102294806@goodmis.org/
    
    However this testcase update was backported alone without feature
    update, which makes the testcase cannot pass on stable branch.
    
    Revert this commit to make the testcase correct.
    
    Fixes: 31c2e369b533 ("selftests/ftrace: Update synthetic event syntax errors")
    Reported-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/debug: add _ASM_S390_ prefix to header guard [+ + +]
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Tue Jan 3 15:11:07 2023 +0100

    s390/debug: add _ASM_S390_ prefix to header guard
    
    [ Upstream commit 0d4d52361b6c29bf771acd4fa461f06d78fb2fac ]
    
    Using DEBUG_H without a prefix is very generic and inconsistent with
    other header guards in arch/s390/include/asm. In fact it collides with
    the same name in the ath9k wireless driver though that depends on !S390
    via disabled wireless support. Let's just use a consistent header guard
    name and prevent possible future trouble.
    
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: hisi_sas: Set a port invalid only if there are no devices attached when refreshing port id [+ + +]
Author: Yihang Li <liyihang9@huawei.com>
Date:   Wed Jan 4 12:03:20 2023 +0800

    scsi: hisi_sas: Set a port invalid only if there are no devices attached when refreshing port id
    
    [ Upstream commit f58c89700630da6554b24fd3df293a24874c10c1 ]
    
    Currently the driver sets the port invalid if one phy in the port is not
    enabled, which may cause issues in expander situation. In directly attached
    situation, if phy up doesn't occur in time when refreshing port id, the
    port is incorrectly set to invalid which will also cause disk lost.
    
    Therefore set a port invalid only if there are no devices attached to the
    port.
    
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1672805000-141102-3-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hpsa: Fix allocation size for scsi_host_alloc() [+ + +]
Author: Alexey V. Vissarionov <gremlin@altlinux.org>
Date:   Wed Jan 18 06:12:55 2023 +0300

    scsi: hpsa: Fix allocation size for scsi_host_alloc()
    
    [ Upstream commit bbbd25499100c810ceaf5193c3cfcab9f7402a33 ]
    
    The 'h' is a pointer to struct ctlr_info, so it's just 4 or 8 bytes, while
    the structure itself is much bigger.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: edd163687ea5 ("hpsa: add driver for HP Smart Array controllers.")
    Link: https://lore.kernel.org/r/20230118031255.GE15213@altlinux.org
    Signed-off-by: Alexey V. Vissarionov <gremlin@altlinux.org>
    Acked-by: Don Brace <don.brace@microchip.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Fix multiple iSCSI session unbind events sent to userspace [+ + +]
Author: Wenchao Hao <haowenchao@huawei.com>
Date:   Sat Nov 26 09:07:52 2022 +0800

    scsi: iscsi: Fix multiple iSCSI session unbind events sent to userspace
    
    [ Upstream commit a3be19b91ea7121d388084e8c07f5b1b982eb40c ]
    
    It was observed that the kernel would potentially send
    ISCSI_KEVENT_UNBIND_SESSION multiple times. Introduce 'target_state' in
    iscsi_cls_session() to make sure session will send only one unbind session
    event.
    
    This introduces a regression wrt. the issue fixed in commit 13e60d3ba287
    ("scsi: iscsi: Report unbind session event when the target has been
    removed"). If iscsid dies for any reason after sending an unbind session to
    kernel, once iscsid is restarted, the kernel's ISCSI_KEVENT_UNBIND_SESSION
    event is lost and userspace is then unable to logout. However, the session
    is actually in invalid state (its target_id is INVALID) so iscsid should
    not sync this session during restart.
    
    Consequently we need to check the session's target state during iscsid
    restart.  If session is in unbound state, do not sync this session and
    perform session teardown. This is OK because once a session is unbound, we
    can not recover it any more (mainly because its target id is INVALID).
    
    Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
    Link: https://lore.kernel.org/r/20221126010752.231917-1-haowenchao@huawei.com
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Reviewed-by: Wu Bo <wubo40@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sctp: fail if no bound addresses can be used for a given scope [+ + +]
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Mon Jan 23 14:59:33 2023 -0300

    sctp: fail if no bound addresses can be used for a given scope
    
    [ Upstream commit 458e279f861d3f61796894cd158b780765a1569f ]
    
    Currently, if you bind the socket to something like:
            servaddr.sin6_family = AF_INET6;
            servaddr.sin6_port = htons(0);
            servaddr.sin6_scope_id = 0;
            inet_pton(AF_INET6, "::1", &servaddr.sin6_addr);
    
    And then request a connect to:
            connaddr.sin6_family = AF_INET6;
            connaddr.sin6_port = htons(20000);
            connaddr.sin6_scope_id = if_nametoindex("lo");
            inet_pton(AF_INET6, "fe88::1", &connaddr.sin6_addr);
    
    What the stack does is:
     - bind the socket
     - create a new asoc
     - to handle the connect
       - copy the addresses that can be used for the given scope
       - try to connect
    
    But the copy returns 0 addresses, and the effect is that it ends up
    trying to connect as if the socket wasn't bound, which is not the
    desired behavior. This unexpected behavior also allows KASLR leaks
    through SCTP diag interface.
    
    The fix here then is, if when trying to copy the addresses that can
    be used for the scope used in connect() it returns 0 addresses, bail
    out. This is what TCP does with a similar reproducer.
    
    Reported-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/9fcd182f1099f86c6661f3717f63712ddd1c676c.1674496737.git.marcelo.leitner@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: spidev: remove debug messages that access spidev->spi without locking [+ + +]
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Fri Jan 6 11:07:19 2023 +0100

    spi: spidev: remove debug messages that access spidev->spi without locking
    
    [ Upstream commit 6b35b173dbc1711f8d272e3f322d2ad697015919 ]
    
    The two debug messages in spidev_open() dereference spidev->spi without
    taking the lock and without checking if it's not null. This can lead to
    a crash. Drop the messages as they're not needed - the user-space will
    get informed about ENOMEM with the syscall return value.
    
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Link: https://lore.kernel.org/r/20230106100719.196243-2-brgl@bgdev.pl
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sysctl: add a new register_sysctl_init() interface [+ + +]
Author: Xiaoming Ni <nixiaoming@huawei.com>
Date:   Tue Jan 24 11:29:45 2023 -0800

    sysctl: add a new register_sysctl_init() interface
    
    commit 3ddd9a808cee7284931312f2f3e854c9617f44b2 upstream.
    
    Patch series "sysctl: first set of kernel/sysctl cleanups", v2.
    
    Finally had time to respin the series of the work we had started last
    year on cleaning up the kernel/sysct.c kitchen sink.  People keeps
    stuffing their sysctls in that file and this creates a maintenance
    burden.  So this effort is aimed at placing sysctls where they actually
    belong.
    
    I'm going to split patches up into series as there is quite a bit of
    work.
    
    This first set adds register_sysctl_init() for uses of registerting a
    sysctl on the init path, adds const where missing to a few places,
    generalizes common values so to be more easy to share, and starts the
    move of a few kernel/sysctl.c out where they belong.
    
    The majority of rework on v2 in this first patch set is 0-day fixes.
    Eric Biederman's feedback is later addressed in subsequent patch sets.
    
    I'll only post the first two patch sets for now.  We can address the
    rest once the first two patch sets get completely reviewed / Acked.
    
    This patch (of 9):
    
    The kernel/sysctl.c is a kitchen sink where everyone leaves their dirty
    dishes, this makes it very difficult to maintain.
    
    To help with this maintenance let's start by moving sysctls to places
    where they actually belong.  The proc sysctl maintainers do not want to
    know what sysctl knobs you wish to add for your own piece of code, we
    just care about the core logic.
    
    Today though folks heavily rely on tables on kernel/sysctl.c so they can
    easily just extend this table with their needed sysctls.  In order to
    help users move their sysctls out we need to provide a helper which can
    be used during code initialization.
    
    We special-case the initialization use of register_sysctl() since it
    *is* safe to fail, given all that sysctls do is provide a dynamic
    interface to query or modify at runtime an existing variable.  So the
    use case of register_sysctl() on init should *not* stop if the sysctls
    don't end up getting registered.  It would be counter productive to stop
    boot if a simple sysctl registration failed.
    
    Provide a helper for init then, and document the recommended init levels
    to use for callers of this routine.  We will later use this in
    subsequent patches to start slimming down kernel/sysctl.c tables and
    moving sysctl registration to the code which actually needs these
    sysctls.
    
    [mcgrof@kernel.org: major commit log and documentation rephrasing also moved to fs/proc/proc_sysctl.c                  ]
    
    Link: https://lkml.kernel.org/r/20211123202347.818157-1-mcgrof@kernel.org
    Link: https://lkml.kernel.org/r/20211123202347.818157-2-mcgrof@kernel.org
    Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Cc: Iurii Zaikin <yzaikin@google.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Paul Turner <pjt@google.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Sebastian Reichel <sre@kernel.org>
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
    Cc: Qing Wang <wangqing@vivo.com>
    Cc: Benjamin LaHaise <bcrl@kvack.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Amir Goldstein <amir73il@gmail.com>
    Cc: Stephen Kitt <steve@sk2.org>
    Cc: Antti Palosaari <crope@iki.fi>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Clemens Ladisch <clemens@ladisch.de>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Julia Lawall <julia.lawall@inria.fr>
    Cc: Lukas Middendorf <kernel@tuxforce.de>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Phillip Potter <phil@philpotter.co.uk>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: James E.J. Bottomley <jejb@linux.ibm.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: John Ogness <john.ogness@linutronix.de>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: avoid the lookup process failing to get sk in ehash table [+ + +]
Author: Jason Xing <kernelxing@tencent.com>
Date:   Wed Jan 18 09:59:41 2023 +0800

    tcp: avoid the lookup process failing to get sk in ehash table
    
    [ Upstream commit 3f4ca5fafc08881d7a57daa20449d171f2887043 ]
    
    While one cpu is working on looking up the right socket from ehash
    table, another cpu is done deleting the request socket and is about
    to add (or is adding) the big socket from the table. It means that
    we could miss both of them, even though it has little chance.
    
    Let me draw a call trace map of the server side.
       CPU 0                           CPU 1
       -----                           -----
    tcp_v4_rcv()                  syn_recv_sock()
                                inet_ehash_insert()
                                -> sk_nulls_del_node_init_rcu(osk)
    __inet_lookup_established()
                                -> __sk_nulls_add_node_rcu(sk, list)
    
    Notice that the CPU 0 is receiving the data after the final ack
    during 3-way shakehands and CPU 1 is still handling the final ack.
    
    Why could this be a real problem?
    This case is happening only when the final ack and the first data
    receiving by different CPUs. Then the server receiving data with
    ACK flag tries to search one proper established socket from ehash
    table, but apparently it fails as my map shows above. After that,
    the server fetches a listener socket and then sends a RST because
    it finds a ACK flag in the skb (data), which obeys RST definition
    in RFC 793.
    
    Besides, Eric pointed out there's one more race condition where it
    handles tw socket hashdance. Only by adding to the tail of the list
    before deleting the old one can we avoid the race if the reader has
    already begun the bucket traversal and it would possibly miss the head.
    
    Many thanks to Eric for great help from beginning to end.
    
    Fixes: 5e0724d027f0 ("tcp/dccp: fix hashdance race for passive sessions")
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/lkml/20230112065336.41034-1-kerneljasonxing@gmail.com/
    Link: https://lore.kernel.org/r/20230118015941.1313-1-kerneljasonxing@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: fix rate_app_limited to default to 1 [+ + +]
Author: David Morley <morleyd@google.com>
Date:   Thu Jan 19 19:00:28 2023 +0000

    tcp: fix rate_app_limited to default to 1
    
    [ Upstream commit 300b655db1b5152d6101bcb6801d50899b20c2d6 ]
    
    The initial default value of 0 for tp->rate_app_limited was incorrect,
    since a flow is indeed application-limited until it first sends
    data. Fixing the default to be 1 is generally correct but also
    specifically will help user-space applications avoid using the initial
    tcpi_delivery_rate value of 0 that persists until the connection has
    some non-zero bandwidth sample.
    
    Fixes: eb8329e0a04d ("tcp: export data delivery rate")
    Suggested-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David Morley <morleyd@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Tested-by: David Morley <morleyd@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal: intel: int340x: Add locking to int340x_thermal_get_trip_type() [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jan 25 13:17:42 2023 +0100

    thermal: intel: int340x: Add locking to int340x_thermal_get_trip_type()
    
    [ Upstream commit acd7e9ee57c880b99671dd99680cb707b7b5b0ee ]
    
    In order to prevent int340x_thermal_get_trip_type() from possibly
    racing with int340x_thermal_read_trips() invoked by int3403_notify()
    add locking to it in analogy with int340x_thermal_get_trip_temp().
    
    Fixes: 6757a7abe47b ("thermal: intel: int340x: Protect trip temperature from concurrent updates")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal: intel: int340x: Protect trip temperature from concurrent updates [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Mon Jan 23 09:21:10 2023 -0800

    thermal: intel: int340x: Protect trip temperature from concurrent updates
    
    commit 6757a7abe47bcb12cb2d45661067e182424b0ee3 upstream.
    
    Trip temperatures are read using ACPI methods and stored in the memory
    during zone initializtion and when the firmware sends a notification for
    change. This trip temperature is returned when the thermal core calls via
    callback get_trip_temp().
    
    But it is possible that while updating the memory copy of the trips when
    the firmware sends a notification for change, thermal core is reading the
    trip temperature via the callback get_trip_temp(). This may return invalid
    trip temperature.
    
    To address this add a mutex to protect the invalid temperature reads in
    the callback get_trip_temp() and int340x_thermal_read_trips().
    
    Fixes: 5fbf7f27fa3d ("Thermal/int340x: Add common thermal zone handler")
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: 5.0+ <stable@vger.kernel.org> # 5.0+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tomoyo: fix broken dependency on *.conf.default [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Jan 7 16:47:41 2023 +0900

    tomoyo: fix broken dependency on *.conf.default
    
    [ Upstream commit eaf2213ba563b2d74a1f2c13a6b258273f689802 ]
    
    If *.conf.default is updated, builtin-policy.h should be rebuilt,
    but this does not work when compiled with O= option.
    
    [Without this commit]
    
      $ touch security/tomoyo/policy/exception_policy.conf.default
      $ make O=/tmp security/tomoyo/
      make[1]: Entering directory '/tmp'
        GEN     Makefile
        CALL    /home/masahiro/ref/linux/scripts/checksyscalls.sh
        DESCEND objtool
      make[1]: Leaving directory '/tmp'
    
    [With this commit]
    
      $ touch security/tomoyo/policy/exception_policy.conf.default
      $ make O=/tmp security/tomoyo/
      make[1]: Entering directory '/tmp'
        GEN     Makefile
        CALL    /home/masahiro/ref/linux/scripts/checksyscalls.sh
        DESCEND objtool
        POLICY  security/tomoyo/builtin-policy.h
        CC      security/tomoyo/common.o
        AR      security/tomoyo/built-in.a
      make[1]: Leaving directory '/tmp'
    
    $(srctree)/ is essential because $(wildcard ) does not follow VPATH.
    
    Fixes: f02dee2d148b ("tomoyo: Do not generate empty policy files")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools: gpio: fix -c option of gpio-event-mon [+ + +]
Author: Ivo Borisov Shopov <ivoshopov@gmail.com>
Date:   Thu Jan 26 15:10:33 2023 +0200

    tools: gpio: fix -c option of gpio-event-mon
    
    [ Upstream commit 677d85e1a1ee69fa05ccea83847309484be3781c ]
    
    Following line should listen for a rising edge and exit after the first
    one since '-c 1' is provided.
    
        # gpio-event-mon -n gpiochip1 -o 0 -r -c 1
    
    It works with kernel 4.19 but it doesn't work with 5.10. In 5.10 the
    above command doesn't exit after the first rising edge it keep listening
    for an event forever. The '-c 1' is not taken into an account.
    The problem is in commit 62757c32d5db ("tools: gpio: add multi-line
    monitoring to gpio-event-mon").
    Before this commit the iterator 'i' in monitor_device() is used for
    counting of the events (loops). In the case of the above command (-c 1)
    we should start from 0 and increment 'i' only ones and hit the 'break'
    statement and exit the process. But after the above commit counting
    doesn't start from 0, it start from 1 when we listen on one line.
    It is because 'i' is used from one more purpose, counting of lines
    (num_lines) and it isn't restore to 0 after following code
    
        for (i = 0; i < num_lines; i++)
            gpiotools_set_bit(&values.mask, i);
    
    Restore the initial value of the iterator to 0 in order to allow counting
    of loops to work for any cases.
    
    Fixes: 62757c32d5db ("tools: gpio: add multi-line monitoring to gpio-event-mon")
    Signed-off-by: Ivo Borisov Shopov <ivoshopov@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    [Bartosz: tweak the commit message]
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
trace_events_hist: add check for return value of 'create_hist_field' [+ + +]
Author: Natalia Petrova <n.petrova@fintech.ru>
Date:   Wed Jan 11 15:04:09 2023 +0300

    trace_events_hist: add check for return value of 'create_hist_field'
    
    commit 8b152e9150d07a885f95e1fd401fc81af202d9a4 upstream.
    
    Function 'create_hist_field' is called recursively at
    trace_events_hist.c:1954 and can return NULL-value that's why we have
    to check it to avoid null pointer dereference.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lkml.kernel.org/r/20230111120409.4111-1-n.petrova@fintech.ru
    
    Cc: stable@vger.kernel.org
    Fixes: 30350d65ac56 ("tracing: Add variable support to hist triggers")
    Signed-off-by: Natalia Petrova <n.petrova@fintech.ru>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Make sure trace_printk() can output as soon as it can be used [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Jan 4 16:14:12 2023 -0500

    tracing: Make sure trace_printk() can output as soon as it can be used
    
    commit 3bb06eb6e9acf7c4a3e1b5bc87aed398ff8e2253 upstream.
    
    Currently trace_printk() can be used as soon as early_trace_init() is
    called from start_kernel(). But if a crash happens, and
    "ftrace_dump_on_oops" is set on the kernel command line, all you get will
    be:
    
      [    0.456075]   <idle>-0         0dN.2. 347519us : Unknown type 6
      [    0.456075]   <idle>-0         0dN.2. 353141us : Unknown type 6
      [    0.456075]   <idle>-0         0dN.2. 358684us : Unknown type 6
    
    This is because the trace_printk() event (type 6) hasn't been registered
    yet. That gets done via an early_initcall(), which may be early, but not
    early enough.
    
    Instead of registering the trace_printk() event (and other ftrace events,
    which are not trace events) via an early_initcall(), have them registered at
    the same time that trace_printk() can be used. This way, if there is a
    crash before early_initcall(), then the trace_printk()s will actually be
    useful.
    
    Link: https://lkml.kernel.org/r/20230104161412.019f6c55@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: e725c731e3bb1 ("tracing: Split tracing initialization into two for early initialization")
    Reported-by: "Joel Fernandes (Google)" <joel@joelfernandes.org>
    Tested-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ubsan: no need to unset panic_on_warn in ubsan_epilogue() [+ + +]
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Jan 24 11:29:48 2023 -0800

    ubsan: no need to unset panic_on_warn in ubsan_epilogue()
    
    commit d83ce027a54068fabb70d2c252e1ce2da86784a4 upstream.
    
    panic_on_warn is unset inside panic(), so no need to unset it before
    calling panic() in ubsan_epilogue().
    
    Link: https://lkml.kernel.org/r/1644324666-15947-5-git-send-email-yangtiezhu@loongson.cn
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Reviewed-by: Marco Elver <elver@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Xuefeng Li <lixuefeng@loongson.cn>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
units: Add SI metric prefix definitions [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jul 12 17:20:25 2021 +0300

    units: Add SI metric prefix definitions
    
    [ Upstream commit 26471d4a6cf8d5d0bd0fb55c7169de7d67cc703a ]
    
    Sometimes it's useful to have well-defined SI metric prefix to be used
    to self-describe the formulas or equations.
    
    List most popular ones in the units.h.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Stable-dep-of: c8c37bc51451 ("i2c: designware: use casting of u64 in clock multiplication to avoid overflow")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

units: Add Watt units [+ + +]
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Tue Dec 8 17:41:42 2020 +0100

    units: Add Watt units
    
    [ Upstream commit 2ee5f8f05949735fa2f4c463a5e13fcb3660c719 ]
    
    As there are the temperature units, let's add the Watt macros definition.
    
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c8c37bc51451 ("i2c: designware: use casting of u64 in clock multiplication to avoid overflow")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: gadget: f_fs: Ensure ep0req is dequeued before free_request [+ + +]
Author: Udipto Goswami <quic_ugoswami@quicinc.com>
Date:   Thu Dec 15 10:59:06 2022 +0530

    usb: gadget: f_fs: Ensure ep0req is dequeued before free_request
    
    [ Upstream commit ce405d561b020e5a46340eb5146805a625dcacee ]
    
    As per the documentation, function usb_ep_free_request guarantees
    the request will not be queued or no longer be re-queued (or
    otherwise used). However, with the current implementation it
    doesn't make sure that the request in ep0 isn't reused.
    
    Fix this by dequeuing the ep0req on functionfs_unbind before
    freeing the request to align with the definition.
    
    Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
    Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>
    Tested-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Link: https://lore.kernel.org/r/20221215052906.8993-3-quic_ugoswami@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait [+ + +]
Author: Udipto Goswami <quic_ugoswami@quicinc.com>
Date:   Thu Dec 15 10:59:05 2022 +0530

    usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
    
    [ Upstream commit 6a19da111057f69214b97c62fb0ac59023970850 ]
    
    While performing fast composition switch, there is a possibility that the
    process of ffs_ep0_write/ffs_ep0_read get into a race condition
    due to ep0req being freed up from functionfs_unbind.
    
    Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait
    by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't
    bounded so it can go ahead and mark the ep0req to NULL, and since there
    is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.
    
    Fix this by making a serialized execution between the two functions using
    a mutex_lock(ffs->mutex).
    
    Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
    Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>
    Tested-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Link: https://lore.kernel.org/r/20221215052906.8993-2-quic_ugoswami@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
w1: fix deadloop in __w1_remove_master_device() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 5 16:04:34 2022 +0800

    w1: fix deadloop in __w1_remove_master_device()
    
    [ Upstream commit 25d5648802f12ae486076ceca5d7ddf1fef792b2 ]
    
    I got a deadloop report while doing device(ds2482) add/remove test:
    
      [  162.241881] w1_master_driver w1_bus_master1: Waiting for w1_bus_master1 to become free: refcnt=1.
      [  163.272251] w1_master_driver w1_bus_master1: Waiting for w1_bus_master1 to become free: refcnt=1.
      [  164.296157] w1_master_driver w1_bus_master1: Waiting for w1_bus_master1 to become free: refcnt=1.
      ...
    
    __w1_remove_master_device() can't return, because the dev->refcnt is not zero.
    
    w1_add_master_device()                  |
      w1_alloc_dev()                        |
        atomic_set(&dev->refcnt, 2)         |
      kthread_run()                         |
                                            |__w1_remove_master_device()
                                            |  kthread_stop()
      // KTHREAD_SHOULD_STOP is set,        |
      // threadfn(w1_process) won't be      |
      // called.                            |
      kthread()                             |
                                            |  // refcnt will never be 0, it's deadloop.
                                            |  while (atomic_read(&dev->refcnt)) {...}
    
    After calling w1_add_master_device(), w1_process() is not really
    invoked, before w1_process() starting, if kthread_stop() is called
    in __w1_remove_master_device(), w1_process() will never be called,
    the refcnt can not be decreased, then it causes deadloop in remove
    function because of non-zero refcnt.
    
    We need to make sure w1_process() is really started, so move the
    set refcnt into w1_process() to fix this problem.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221205080434.3149205-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

w1: fix WARNING after calling w1_process() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 5 18:15:58 2022 +0800

    w1: fix WARNING after calling w1_process()
    
    [ Upstream commit 36225a7c72e9e3e1ce4001b6ce72849f5c9a2d3b ]
    
    I got the following WARNING message while removing driver(ds2482):
    
    ------------[ cut here ]------------
    do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire]
    WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0
    CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G                 N 6.1.0-rc3+ #307
    RIP: 0010:__might_sleep+0x98/0xa0
    Call Trace:
     exit_signals+0x6c/0x550
     do_exit+0x2b4/0x17e0
     kthread_exit+0x52/0x60
     kthread+0x16d/0x1e0
     ret_from_fork+0x1f/0x30
    
    The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),
    set it to TASK_RUNNING when it breaks out of the loop to avoid the
    warning.
    
    Fixes: 3c52e4e62789 ("W1: w1_process, block or sleep")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221205101558.3599162-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: rndis_wlan: Prevent buffer overflow in rndis_query_oid [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Wed Jan 11 18:50:31 2023 +0100

    wifi: rndis_wlan: Prevent buffer overflow in rndis_query_oid
    
    [ Upstream commit b870e73a56c4cccbec33224233eaf295839f228c ]
    
    Since resplen and respoffs are signed integers sufficiently
    large values of unsigned int len and offset members of RNDIS
    response will result in negative values of prior variables.
    This may be utilized to bypass implemented security checks
    to either extract memory contents by manipulating offset or
    overflow the data buffer via memcpy by manipulating both
    offset and len.
    
    Additionally assure that sum of resplen and respoffs does not
    overflow so buffer boundaries are kept.
    
    Fixes: 80f8c5b434f9 ("rndis_wlan: copy only useful data from rndis_command respond")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230111175031.7049-1-szymon.heidrich@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Jan 9 22:57:13 2023 +0100

    x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL
    
    commit 5fa55950729d0762a787451dc52862c3f850f859 upstream.
    
    Baoquan reported that after triggering a crash the subsequent crash-kernel
    fails to boot about half of the time. It triggers a NULL pointer
    dereference in the periodic tick code.
    
    This happens because the legacy timer interrupt (IRQ0) is resent in
    software which happens in soft interrupt (tasklet) context. In this context
    get_irq_regs() returns NULL which leads to the NULL pointer dereference.
    
    The reason for the resend is a spurious APIC interrupt on the IRQ0 vector
    which is captured and leads to a resend when the legacy timer interrupt is
    enabled. This is wrong because the legacy PIC interrupts are level
    triggered and therefore should never be resent in software, but nothing
    ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not
    know about their trigger type.
    
    Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.
    
    Fixes: a4633adcdbc1 ("[PATCH] genirq: add genirq sw IRQ-retrigger")
    Reported-by: Baoquan He <bhe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Baoquan He <bhe@redhat.com>
    Link: https://lore.kernel.org/r/87mt6rjrra.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86: ACPI: cstate: Optimize C3 entry on AMD CPUs [+ + +]
Author: Deepak Sharma <deepak.sharma@amd.com>
Date:   Thu Sep 23 23:12:05 2021 -0700

    x86: ACPI: cstate: Optimize C3 entry on AMD CPUs
    
    commit a8fb40966f19ff81520d9ccf8f7e2b95201368b8 upstream.
    
    All Zen or newer CPU which support C3 shares cache. Its not necessary to
    flush the caches in software before entering C3. This will cause drop in
    performance for the cores which share some caches. ARB_DIS is not used
    with current AMD C state implementation. So set related flags correctly.
    
    Signed-off-by: Deepak Sharma <deepak.sharma@amd.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci: Set HCD flag to defer primary roothub registration [+ + +]
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Tue May 10 14:46:30 2022 +0530

    xhci: Set HCD flag to defer primary roothub registration
    
    commit b7a4f9b5d0e4b6dd937678c546c0b322dd1a4054 upstream.
    
    Set "HCD_FLAG_DEFER_RH_REGISTER" to hcd->flags in xhci_run() to defer
    registering primary roothub in usb_add_hcd() if xhci has two roothubs.
    This will make sure both primary roothub and secondary roothub will be
    registered along with the second HCD.
    This is required for cold plugged USB devices to be detected in certain
    PCIe USB cards (like Inateck USB card connected to AM64 EVM or J7200 EVM).
    
    This patch has been added and reverted earier as it triggered a race
    in usb device enumeration.
    That race is now fixed in 5.16-rc3, and in stable back to 5.4
    commit 6cca13de26ee ("usb: hub: Fix locking issues with address0_mutex")
    commit 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0
    race")
    
    [minor rebase change, and commit message update -Mathias]
    
    CC: stable@vger.kernel.org # 5.4+
    Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Tested-by: Chris Chiu <chris.chiu@canonical.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Link: https://lore.kernel.org/r/20220510091630.16564-3-kishon@ti.com
    Signed-off-by: Adrian Zaharia <Adrian.Zaharia@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>