--- /dev/null
+From 1af997cad473d505248df6d9577183bb91f69670 Mon Sep 17 00:00:00 2001
+From: Shawn Guo <shawnguo@kernel.org>
+Date: Fri, 27 Feb 2026 15:22:10 +0800
+Subject: arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges
+
+From: Shawn Guo <shawnguo@kernel.org>
+
+commit 1af997cad473d505248df6d9577183bb91f69670 upstream.
+
+Reboot starts failing on Poplar since commit 8424ecdde7df ("arm64: mm:
+Set ZONE_DMA size based on devicetree's dma-ranges"), which effectively
+changes zone_dma_bits from 30 to 32 for arm64 platforms that do not
+properly define dma-ranges in device tree. It's unclear how Poplar reboot
+gets broken by this change exactly, but a dma-ranges limiting zone_dma to
+the first 1 GB fixes the regression.
+
+Fixes: 2f20182ed670 ("arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
++++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+@@ -122,6 +122,7 @@
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0xf0000000 0x10000000>;
++ dma-ranges = <0x0 0x0 0x0 0x40000000>;
+
+ crg: clock-reset-controller@8a22000 {
+ compatible = "hisilicon,hi3798cv200-crg", "syscon", "simple-mfd";
--- /dev/null
+From c1f2b0f2b5e37b2c27540a175aea2755a3799433 Mon Sep 17 00:00:00 2001
+From: Shawn Guo <shawnguo@kernel.org>
+Date: Fri, 27 Feb 2026 15:19:58 +0800
+Subject: arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity
+
+From: Shawn Guo <shawnguo@kernel.org>
+
+commit c1f2b0f2b5e37b2c27540a175aea2755a3799433 upstream.
+
+The PCIe reset GPIO on Poplar is actually active low. The active high
+worked before because kernel driver didn't respect the setting from DT.
+This is changed since commit 1d26a55fbeb9 ("PCI: histb: Switch to using
+gpiod API"), and thus PCIe on Poplar got brken since then.
+
+Fix the problem by correcting the polarity.
+
+Fixes: 32fa01761bd9 ("arm64: dts: hi3798cv200: enable PCIe support for poplar board")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
++++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
+@@ -179,7 +179,7 @@
+ };
+
+ &pcie {
+- reset-gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>;
++ reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie>;
+ status = "okay";
+ };
--- /dev/null
+From 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637 Mon Sep 17 00:00:00 2001
+From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Date: Sat, 21 Feb 2026 19:15:19 +0100
+Subject: arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+
+commit 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637 upstream.
+
+The minimal voltage of VDD_SOC sourced from BUCK1 is 0.81V, which
+is the currently set value. However, BD71837 only guarantees accuracy
+of ±0.01V, and this still doesn't factor other reasons for actual
+voltage to slightly drop in, resulting in the possibility of running
+out of the operational range.
+
+Bump the voltage up to 0.85V, which should give enough headroom.
+
+Cc: stable@vger.kernel.org
+Fixes: 8f0216b006e5 ("arm64: dts: Add a device tree for the Librem 5 phone")
+Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Signed-off-by: Frank Li <Frank.Li@nxp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
++++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+@@ -846,7 +846,7 @@
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <900000>;
+ rohm,dvs-idle-voltage = <850000>;
+- rohm,dvs-suspend-voltage = <810000>;
++ rohm,dvs-suspend-voltage = <850000>;
+ regulator-always-on;
+ };
+
--- /dev/null
+From ed8444006df9863ffa682e315352c44a49d9f4cb Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marek.vasut+renesas@mailbox.org>
+Date: Tue, 24 Mar 2026 15:33:28 +0100
+Subject: arm64: dts: renesas: sparrow-hawk: Reserve first 128 MiB of DRAM
+
+From: Marek Vasut <marek.vasut+renesas@mailbox.org>
+
+commit ed8444006df9863ffa682e315352c44a49d9f4cb upstream.
+
+Mark the first 128 MiB of DRAM as reserved. The first 128 MiB of DRAM
+may optionally be used by TFA and other firmware for its own purposes,
+and in such case, Linux must not use this memory.
+
+On this platform, U-Boot runs in EL3 and starts TFA BL31 and Linux from
+a single combined fitImage. U-Boot has full access to all memory in the
+0x40000000..0xbfffffff range, as well memory in the memory banks in the
+64-bit address ranges, and therefore U-Boot patches this full complete
+view of platform memory layout into the DT that is passed to the next
+stage.
+
+The next stage is TFA BL31 and then the Linux kernel. The TFA BL31 does
+not modify the DT passed from U-Boot to TFA BL31 and then to Linux with
+any new reserved-memory {} node to reserve memory areas used by the TFA
+BL31 to prevent the next stage from using those areas, which lets Linux
+to use all of the available DRAM as described in the DT that was passed
+in by U-Boot, including the areas that are newly utilized by TFA BL31.
+
+In case of high DRAM utilization, for example in case of four instances
+of "memtester 3900M" running in parallel, unless the memory used by TFA
+BL31 is properly reserved, Linux may use and corrupt the memory used by
+TFA BL31, which would often lead to system becoming unresponsive.
+
+Until TFA BL31 can properly fill its own reserved-memory node into the
+DT, and to assure older versions of TFA BL31 do not cause problems, add
+explicitly reserved-memory {} node which prevents Linux from using the
+first 128 MiB of DRAM.
+
+Note that TFA BL31 can be adjusted to use different memory areas, this
+newly added reserved-memory {} node follows longer-term practice on the
+R-Car SoCs where the first 128 MiB of DRAM is reserved for firmware use.
+In case user does modify TFA BL31 to use different memory ranges, they
+must either use a future version of TFA BL31 which properly patches a
+reserved-memory {} node into the DT, or they must adjust the address
+ranges of this reserved-memory {} node accordingly.
+
+Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Link: https://patch.msgid.link/20260324143342.17872-1-marek.vasut+renesas@mailbox.org
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
++++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
+@@ -118,6 +118,17 @@
+ reg = <0x6 0x00000000 0x1 0x00000000>;
+ };
+
++ reserved-memory {
++ #address-cells = <2>;
++ #size-cells = <2>;
++ ranges;
++
++ tfa@40000000 {
++ reg = <0x0 0x40000000 0x0 0x8000000>;
++ no-map;
++ };
++ };
++
+ /* Page 27 / DSI to Display */
+ dp-con {
+ compatible = "dp-connector";
--- /dev/null
+From 0f71866057262d669ed6a21246eaac0ad6d04d4e Mon Sep 17 00:00:00 2001
+From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
+Date: Wed, 8 Apr 2026 11:45:14 +0300
+Subject: ASoC: SOF: Intel: hda: modify period size constraints for ACE4
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
+
+commit 0f71866057262d669ed6a21246eaac0ad6d04d4e upstream.
+
+Intel ACE4 based products set more strict constraints on HDA BDLE start
+address and length alignment. Add a constraint to align period size to
+128 bytes.
+
+The commit removes the "minimum as per HDA spec" comment. This comment
+was misleading as spec actually does allow a 2 byte BDLE length, and
+more importantly, period size also directly impacts how the BDLE start
+addresses are aligned, so it is not sufficient just to consider allowed
+buffer length.
+
+Fixes: d3df422f66e8 ("ASoC: SOF: Intel: add initial support for NVL-S")
+Cc: stable@vger.kernel.org
+Reported-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
+Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
+Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
+Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
+Link: https://patch.msgid.link/20260408084514.24325-3-peter.ujfalusi@linux.intel.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/sof/intel/hda-pcm.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/sound/soc/sof/intel/hda-pcm.c b/sound/soc/sof/intel/hda-pcm.c
+index da6c1e7263cd..16a364072821 100644
+--- a/sound/soc/sof/intel/hda-pcm.c
++++ b/sound/soc/sof/intel/hda-pcm.c
+@@ -219,6 +219,7 @@ EXPORT_SYMBOL_NS(hda_dsp_pcm_pointer, "SND_SOC_SOF_INTEL_HDA_COMMON");
+ int hda_dsp_pcm_open(struct snd_sof_dev *sdev,
+ struct snd_pcm_substream *substream)
+ {
++ const struct sof_intel_dsp_desc *chip_info = get_chip_info(sdev->pdata);
+ struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_soc_component *scomp = sdev->component;
+@@ -268,8 +269,17 @@ int hda_dsp_pcm_open(struct snd_sof_dev *sdev,
+ return -ENODEV;
+ }
+
+- /* minimum as per HDA spec */
+- snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);
++ /*
++ * Set period size constraint to ensure BDLE buffer length and
++ * start address alignment requirements are met. Align to 128
++ * bytes for newer Intel platforms, with older ones using 4 byte alignment.
++ */
++ if (chip_info->hw_ip_version >= SOF_INTEL_ACE_4_0)
++ snd_pcm_hw_constraint_step(substream->runtime, 0,
++ SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128);
++ else
++ snd_pcm_hw_constraint_step(substream->runtime, 0,
++ SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);
+
+ /* avoid circular buffer wrap in middle of period */
+ snd_pcm_hw_constraint_integer(substream->runtime,
+--
+2.53.0
+
--- /dev/null
+From 82d8701b2c930d0e96b0dbc9115a218d791cb0d2 Mon Sep 17 00:00:00 2001
+From: Haoze Xie <royenheart@gmail.com>
+Date: Mon, 6 Apr 2026 21:17:28 +0800
+Subject: batman-adv: hold claim backbone gateways by reference
+
+From: Haoze Xie <royenheart@gmail.com>
+
+commit 82d8701b2c930d0e96b0dbc9115a218d791cb0d2 upstream.
+
+batadv_bla_add_claim() can replace claim->backbone_gw and drop the old
+gateway's last reference while readers still follow the pointer.
+
+The netlink claim dump path dereferences claim->backbone_gw->orig and
+takes claim->backbone_gw->crc_lock without pinning the underlying
+backbone gateway. batadv_bla_check_claim() still has the same naked
+pointer access pattern.
+
+Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate
+on a stable gateway reference until the read-side work is complete.
+This keeps the dump and claim-check paths aligned with the lifetime
+rules introduced for the other BLA claim readers.
+
+Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
+Fixes: 04f3f5bf1883 ("batman-adv: add B.A.T.M.A.N. Dump BLA claims via netlink")
+Cc: stable@vger.kernel.org
+Reported-by: Yifan Wu <yifanwucs@gmail.com>
+Reported-by: Juefei Pu <tomapufckgml@gmail.com>
+Co-developed-by: Yuan Tan <yuantan098@gmail.com>
+Signed-off-by: Yuan Tan <yuantan098@gmail.com>
+Suggested-by: Xin Liu <bird@lzu.edu.cn>
+Signed-off-by: Haoze Xie <royenheart@gmail.com>
+Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
+Signed-off-by: Sven Eckelmann <sven@narfation.org>
+Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/batman-adv/bridge_loop_avoidance.c | 27 ++++++++++++++++++---------
+ 1 file changed, 18 insertions(+), 9 deletions(-)
+
+--- a/net/batman-adv/bridge_loop_avoidance.c
++++ b/net/batman-adv/bridge_loop_avoidance.c
+@@ -2130,6 +2130,7 @@ batadv_bla_claim_dump_entry(struct sk_bu
+ struct batadv_bla_claim *claim)
+ {
+ const u8 *primary_addr = primary_if->net_dev->dev_addr;
++ struct batadv_bla_backbone_gw *backbone_gw;
+ u16 backbone_crc;
+ bool is_own;
+ void *hdr;
+@@ -2145,32 +2146,35 @@ batadv_bla_claim_dump_entry(struct sk_bu
+
+ genl_dump_check_consistent(cb, hdr);
+
+- is_own = batadv_compare_eth(claim->backbone_gw->orig,
+- primary_addr);
++ backbone_gw = batadv_bla_claim_get_backbone_gw(claim);
++
++ is_own = batadv_compare_eth(backbone_gw->orig, primary_addr);
+
+- spin_lock_bh(&claim->backbone_gw->crc_lock);
+- backbone_crc = claim->backbone_gw->crc;
+- spin_unlock_bh(&claim->backbone_gw->crc_lock);
++ spin_lock_bh(&backbone_gw->crc_lock);
++ backbone_crc = backbone_gw->crc;
++ spin_unlock_bh(&backbone_gw->crc_lock);
+
+ if (is_own)
+ if (nla_put_flag(msg, BATADV_ATTR_BLA_OWN)) {
+ genlmsg_cancel(msg, hdr);
+- goto out;
++ goto put_backbone_gw;
+ }
+
+ if (nla_put(msg, BATADV_ATTR_BLA_ADDRESS, ETH_ALEN, claim->addr) ||
+ nla_put_u16(msg, BATADV_ATTR_BLA_VID, claim->vid) ||
+ nla_put(msg, BATADV_ATTR_BLA_BACKBONE, ETH_ALEN,
+- claim->backbone_gw->orig) ||
++ backbone_gw->orig) ||
+ nla_put_u16(msg, BATADV_ATTR_BLA_CRC,
+ backbone_crc)) {
+ genlmsg_cancel(msg, hdr);
+- goto out;
++ goto put_backbone_gw;
+ }
+
+ genlmsg_end(msg, hdr);
+ ret = 0;
+
++put_backbone_gw:
++ batadv_backbone_gw_put(backbone_gw);
+ out:
+ return ret;
+ }
+@@ -2448,6 +2452,7 @@ out:
+ bool batadv_bla_check_claim(struct batadv_priv *bat_priv,
+ u8 *addr, unsigned short vid)
+ {
++ struct batadv_bla_backbone_gw *backbone_gw;
+ struct batadv_bla_claim search_claim;
+ struct batadv_bla_claim *claim = NULL;
+ struct batadv_hard_iface *primary_if = NULL;
+@@ -2470,9 +2475,13 @@ bool batadv_bla_check_claim(struct batad
+ * return false.
+ */
+ if (claim) {
+- if (!batadv_compare_eth(claim->backbone_gw->orig,
++ backbone_gw = batadv_bla_claim_get_backbone_gw(claim);
++
++ if (!batadv_compare_eth(backbone_gw->orig,
+ primary_if->net_dev->dev_addr))
+ ret = false;
++
++ batadv_backbone_gw_put(backbone_gw);
+ batadv_claim_put(claim);
+ }
+
--- /dev/null
+From 3a359bf5c61d52e7f09754108309d637532164a6 Mon Sep 17 00:00:00 2001
+From: Ruide Cao <caoruide123@gmail.com>
+Date: Thu, 2 Apr 2026 23:12:31 +0800
+Subject: batman-adv: reject oversized global TT response buffers
+
+From: Ruide Cao <caoruide123@gmail.com>
+
+commit 3a359bf5c61d52e7f09754108309d637532164a6 upstream.
+
+batadv_tt_prepare_tvlv_global_data() builds the allocation length for a
+global TT response in 16-bit temporaries. When a remote originator
+advertises a large enough global TT, the TT payload length plus the VLAN
+header offset can exceed 65535 and wrap before kmalloc().
+
+The full-table response path still uses the original TT payload length when
+it fills tt_change, so the wrapped allocation is too small and
+batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object
+before the later packet-size check runs.
+
+Fix this by rejecting TT responses whose TVLV value length cannot fit in
+the 16-bit TVLV payload length field.
+
+Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
+Cc: stable@vger.kernel.org
+Reported-by: Yifan Wu <yifanwucs@gmail.com>
+Reported-by: Juefei Pu <tomapufckgml@gmail.com>
+Co-developed-by: Yuan Tan <yuantan098@gmail.com>
+Signed-off-by: Yuan Tan <yuantan098@gmail.com>
+Suggested-by: Xin Liu <bird@lzu.edu.cn>
+Tested-by: Ren Wei <enjou1224z@gmail.com>
+Signed-off-by: Ruide Cao <caoruide123@gmail.com>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Signed-off-by: Sven Eckelmann <sven@narfation.org>
+Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/batman-adv/translation-table.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/net/batman-adv/translation-table.c
++++ b/net/batman-adv/translation-table.c
+@@ -798,8 +798,8 @@ batadv_tt_prepare_tvlv_global_data(struc
+ {
+ u16 num_vlan = 0;
+ u16 num_entries = 0;
+- u16 change_offset;
+- u16 tvlv_len;
++ u16 tvlv_len = 0;
++ unsigned int change_offset;
+ struct batadv_tvlv_tt_vlan_data *tt_vlan;
+ struct batadv_orig_node_vlan *vlan;
+ u8 *tt_change_ptr;
+@@ -816,6 +816,11 @@ batadv_tt_prepare_tvlv_global_data(struc
+ if (*tt_len < 0)
+ *tt_len = batadv_tt_len(num_entries);
+
++ if (change_offset > U16_MAX || *tt_len > U16_MAX - change_offset) {
++ *tt_len = 0;
++ goto out;
++ }
++
+ tvlv_len = *tt_len;
+ tvlv_len += change_offset;
+
--- /dev/null
+From 4c71fd099513bfa8acab529b626e1f0097b76061 Mon Sep 17 00:00:00 2001
+From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+Date: Wed, 1 Apr 2026 12:10:07 +0200
+Subject: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat
+
+From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+
+commit 4c71fd099513bfa8acab529b626e1f0097b76061 upstream.
+
+A use-after-free / refcount underflow is possible when the heartbeat
+worker and intel_engine_park_heartbeat() race to release the same
+engine->heartbeat.systole request.
+
+The heartbeat worker reads engine->heartbeat.systole and calls
+i915_request_put() on it when the request is complete, but clears
+the pointer in a separate, non-atomic step. Concurrently, a request
+retirement on another CPU can drop the engine wakeref to zero, triggering
+__engine_park() -> intel_engine_park_heartbeat(). If the heartbeat
+timer is pending at that point, cancel_delayed_work() returns true and
+intel_engine_park_heartbeat() reads the stale non-NULL systole pointer
+and calls i915_request_put() on it again, causing a refcount underflow:
+
+```
+<4> [487.221889] Workqueue: i915-unordered engine_retire [i915]
+<4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0
+...
+<4> [487.222707] Call Trace:
+<4> [487.222711] <TASK>
+<4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]
+<4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]
+<4> [487.223566] __engine_park+0xb9/0x650 [i915]
+<4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]
+<4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]
+<4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]
+<4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915]
+<4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]
+<4> [487.226178] i915_request_retire+0x1c/0x40 [i915]
+<4> [487.226625] engine_retire+0x122/0x180 [i915]
+<4> [487.227037] process_one_work+0x239/0x760
+<4> [487.227060] worker_thread+0x200/0x3f0
+<4> [487.227068] ? __pfx_worker_thread+0x10/0x10
+<4> [487.227075] kthread+0x10d/0x150
+<4> [487.227083] ? __pfx_kthread+0x10/0x10
+<4> [487.227092] ret_from_fork+0x3d4/0x480
+<4> [487.227099] ? __pfx_kthread+0x10/0x10
+<4> [487.227107] ret_from_fork_asm+0x1a/0x30
+<4> [487.227141] </TASK>
+```
+
+Fix this by replacing the non-atomic pointer read + separate clear with
+xchg() in both racing paths. xchg() is a single indivisible hardware
+instruction that atomically reads the old pointer and writes NULL. This
+guarantees only one of the two concurrent callers obtains the non-NULL
+pointer and performs the put, the other gets NULL and skips it.
+
+Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15880
+Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats")
+Cc: <stable@vger.kernel.org> # v5.5+
+Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
+Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com
+(cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)
+Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 26 +++++++++++++++--------
+ 1 file changed, 18 insertions(+), 8 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
++++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+@@ -148,10 +148,12 @@ static void heartbeat(struct work_struct
+ /* Just in case everything has gone horribly wrong, give it a kick */
+ intel_engine_flush_submission(engine);
+
+- rq = engine->heartbeat.systole;
+- if (rq && i915_request_completed(rq)) {
+- i915_request_put(rq);
+- engine->heartbeat.systole = NULL;
++ rq = xchg(&engine->heartbeat.systole, NULL);
++ if (rq) {
++ if (i915_request_completed(rq))
++ i915_request_put(rq);
++ else
++ engine->heartbeat.systole = rq;
+ }
+
+ if (!intel_engine_pm_get_if_awake(engine))
+@@ -232,8 +234,11 @@ static void heartbeat(struct work_struct
+ unlock:
+ mutex_unlock(&ce->timeline->mutex);
+ out:
+- if (!engine->i915->params.enable_hangcheck || !next_heartbeat(engine))
+- i915_request_put(fetch_and_zero(&engine->heartbeat.systole));
++ if (!engine->i915->params.enable_hangcheck || !next_heartbeat(engine)) {
++ rq = xchg(&engine->heartbeat.systole, NULL);
++ if (rq)
++ i915_request_put(rq);
++ }
+ intel_engine_pm_put(engine);
+ }
+
+@@ -247,8 +252,13 @@ void intel_engine_unpark_heartbeat(struc
+
+ void intel_engine_park_heartbeat(struct intel_engine_cs *engine)
+ {
+- if (cancel_delayed_work(&engine->heartbeat.work))
+- i915_request_put(fetch_and_zero(&engine->heartbeat.systole));
++ if (cancel_delayed_work(&engine->heartbeat.work)) {
++ struct i915_request *rq;
++
++ rq = xchg(&engine->heartbeat.systole, NULL);
++ if (rq)
++ i915_request_put(rq);
++ }
+ }
+
+ void intel_gt_unpark_heartbeats(struct intel_gt *gt)
--- /dev/null
+From 75519f5df2a9b23f7bf305e12dc9a6e3e65c24b7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jouni=20H=C3=B6gander?= <jouni.hogander@intel.com>
+Date: Fri, 27 Mar 2026 13:45:53 +0200
+Subject: drm/i915/psr: Do not use pipe_src as borders for SU area
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jouni Högander <jouni.hogander@intel.com>
+
+commit 75519f5df2a9b23f7bf305e12dc9a6e3e65c24b7 upstream.
+
+This far using crtc_state->pipe_src as borders for Selective Update area
+haven't caused visible problems as drm_rect_width(crtc_state->pipe_src) ==
+crtc_state->hw.adjusted_mode.crtc_hdisplay and
+drm_rect_height(crtc_state->pipe_src) ==
+crtc_state->hw.adjusted_mode.crtc_vdisplay when pipe scaling is not
+used. On the other hand using pipe scaling is forcing full frame updates and all the
+Selective Update area calculations are skipped. Now this improper usage of
+crtc_state->pipe_src is causing following warnings:
+
+<4> [7771.978166] xe 0000:00:02.0: [drm] drm_WARN_ON_ONCE(su_lines % vdsc_cfg->slice_height)
+
+after WARN_ON_ONCE was added by commit:
+
+"drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters"
+
+These warnings are seen when DSC and pipe scaling are enabled
+simultaneously. This is because on full frame update SU area is improperly
+set as pipe_src which is not aligned with DSC slice height.
+
+Fix these by creating local rectangle using
+crtc_state->hw.adjusted_mode.crtc_hdisplay and
+crtc_state->hw.adjusted_mode.crtc_vdisplay. Use this local rectangle as
+borders for SU area.
+
+Fixes: d6774b8c3c58 ("drm/i915: Ensure damage clip area is within pipe area")
+Cc: <stable@vger.kernel.org> # v6.0+
+Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
+Reviewed-by: Mika Kahola <mika.kahola@intel.com>
+Link: https://patch.msgid.link/20260327114553.195285-1-jouni.hogander@intel.com
+(cherry picked from commit da0cdc1c329dd2ff09c41fbbe9fbd9c92c5d2c6e)
+Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_psr.c | 30 +++++++++++++++++++-----------
+ 1 file changed, 19 insertions(+), 11 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_psr.c
++++ b/drivers/gpu/drm/i915/display/intel_psr.c
+@@ -2656,9 +2656,9 @@ static u32 psr2_pipe_srcsz_early_tpt_cal
+
+ static void clip_area_update(struct drm_rect *overlap_damage_area,
+ struct drm_rect *damage_area,
+- struct drm_rect *pipe_src)
++ struct drm_rect *display_area)
+ {
+- if (!drm_rect_intersect(damage_area, pipe_src))
++ if (!drm_rect_intersect(damage_area, display_area))
+ return;
+
+ if (overlap_damage_area->y1 == -1) {
+@@ -2709,6 +2709,7 @@ static bool intel_psr2_sel_fetch_pipe_al
+ static void
+ intel_psr2_sel_fetch_et_alignment(struct intel_atomic_state *state,
+ struct intel_crtc *crtc,
++ struct drm_rect *display_area,
+ bool *cursor_in_su_area)
+ {
+ struct intel_crtc_state *crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
+@@ -2736,7 +2737,7 @@ intel_psr2_sel_fetch_et_alignment(struct
+ continue;
+
+ clip_area_update(&crtc_state->psr2_su_area, &new_plane_state->uapi.dst,
+- &crtc_state->pipe_src);
++ display_area);
+ *cursor_in_su_area = true;
+ }
+ }
+@@ -2832,6 +2833,12 @@ int intel_psr2_sel_fetch_update(struct i
+ struct intel_crtc_state *crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
+ struct intel_plane_state *new_plane_state, *old_plane_state;
+ struct intel_plane *plane;
++ struct drm_rect display_area = {
++ .x1 = 0,
++ .y1 = 0,
++ .x2 = crtc_state->hw.adjusted_mode.crtc_hdisplay,
++ .y2 = crtc_state->hw.adjusted_mode.crtc_vdisplay,
++ };
+ bool full_update = false, su_area_changed;
+ int i, ret;
+
+@@ -2845,7 +2852,7 @@ int intel_psr2_sel_fetch_update(struct i
+
+ crtc_state->psr2_su_area.x1 = 0;
+ crtc_state->psr2_su_area.y1 = -1;
+- crtc_state->psr2_su_area.x2 = drm_rect_width(&crtc_state->pipe_src);
++ crtc_state->psr2_su_area.x2 = drm_rect_width(&display_area);
+ crtc_state->psr2_su_area.y2 = -1;
+
+ /*
+@@ -2883,14 +2890,14 @@ int intel_psr2_sel_fetch_update(struct i
+ damaged_area.y1 = old_plane_state->uapi.dst.y1;
+ damaged_area.y2 = old_plane_state->uapi.dst.y2;
+ clip_area_update(&crtc_state->psr2_su_area, &damaged_area,
+- &crtc_state->pipe_src);
++ &display_area);
+ }
+
+ if (new_plane_state->uapi.visible) {
+ damaged_area.y1 = new_plane_state->uapi.dst.y1;
+ damaged_area.y2 = new_plane_state->uapi.dst.y2;
+ clip_area_update(&crtc_state->psr2_su_area, &damaged_area,
+- &crtc_state->pipe_src);
++ &display_area);
+ }
+ continue;
+ } else if (new_plane_state->uapi.alpha != old_plane_state->uapi.alpha) {
+@@ -2898,7 +2905,7 @@ int intel_psr2_sel_fetch_update(struct i
+ damaged_area.y1 = new_plane_state->uapi.dst.y1;
+ damaged_area.y2 = new_plane_state->uapi.dst.y2;
+ clip_area_update(&crtc_state->psr2_su_area, &damaged_area,
+- &crtc_state->pipe_src);
++ &display_area);
+ continue;
+ }
+
+@@ -2914,7 +2921,7 @@ int intel_psr2_sel_fetch_update(struct i
+ damaged_area.x1 += new_plane_state->uapi.dst.x1 - src.x1;
+ damaged_area.x2 += new_plane_state->uapi.dst.x1 - src.x1;
+
+- clip_area_update(&crtc_state->psr2_su_area, &damaged_area, &crtc_state->pipe_src);
++ clip_area_update(&crtc_state->psr2_su_area, &damaged_area, &display_area);
+ }
+
+ /*
+@@ -2949,7 +2956,8 @@ int intel_psr2_sel_fetch_update(struct i
+ * cursor is added into affected planes even when
+ * cursor is not updated by itself.
+ */
+- intel_psr2_sel_fetch_et_alignment(state, crtc, &cursor_in_su_area);
++ intel_psr2_sel_fetch_et_alignment(state, crtc, &display_area,
++ &cursor_in_su_area);
+
+ su_area_changed = intel_psr2_sel_fetch_pipe_alignment(crtc_state);
+
+@@ -3025,8 +3033,8 @@ int intel_psr2_sel_fetch_update(struct i
+
+ skip_sel_fetch_set_loop:
+ if (full_update)
+- clip_area_update(&crtc_state->psr2_su_area, &crtc_state->pipe_src,
+- &crtc_state->pipe_src);
++ clip_area_update(&crtc_state->psr2_su_area, &display_area,
++ &display_area);
+
+ psr2_man_trk_ctl_calc(crtc_state, full_update);
+ crtc_state->pipe_srcsz_early_tpt =
--- /dev/null
+From 51520e03e70d6c73e33ee7cbe0319767d05764fe Mon Sep 17 00:00:00 2001
+From: "Borislav Petkov (AMD)" <bp@alien8.de>
+Date: Tue, 31 Mar 2026 14:16:23 +0200
+Subject: EDAC/mc: Fix error path ordering in edac_mc_alloc()
+
+From: Borislav Petkov (AMD) <bp@alien8.de>
+
+commit 51520e03e70d6c73e33ee7cbe0319767d05764fe upstream.
+
+When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path
+will call put_device() which will end up calling the device's release
+function.
+
+However, the init ordering is wrong such that device_initialize() happens
+*after* the failed allocation and thus the device itself and the release
+function pointer are not initialized yet when they're called:
+
+ MCE: In-kernel MCE decoding enabled.
+ ------------[ cut here ]------------
+ kobject: '(null)': is not initialized, yet kobject_put() is being called.
+ WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd
+ CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)
+ RIP: 0010:kobject_put
+ Call Trace:
+ <TASK>
+ edac_mc_alloc+0xbe/0xe0 [edac_core]
+ amd64_edac_init+0x7a4/0xff0 [amd64_edac]
+ ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]
+ do_one_initcall
+ ...
+
+Reorder the calling sequence so that the device is initialized and thus the
+release function pointer is properly set before it can be used.
+
+This was found by Claude while reviewing another EDAC patch.
+
+Fixes: 0bbb265f7089 ("EDAC/mc: Get rid of silly one-shot struct allocation in edac_mc_alloc()")
+Reported-by: Claude Code:claude-opus-4.5
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
+Cc: stable@kernel.org
+Link: https://patch.msgid.link/20260331121623.4871-1-bp@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/edac/edac_mc.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/edac/edac_mc.c
++++ b/drivers/edac/edac_mc.c
+@@ -370,13 +370,13 @@ struct mem_ctl_info *edac_mc_alloc(unsig
+ if (!mci->layers)
+ goto error;
+
++ mci->dev.release = mci_release;
++ device_initialize(&mci->dev);
++
+ mci->pvt_info = kzalloc(sz_pvt, GFP_KERNEL);
+ if (!mci->pvt_info)
+ goto error;
+
+- mci->dev.release = mci_release;
+- device_initialize(&mci->dev);
+-
+ /* setup index and various internal pointers */
+ mci->mc_idx = mc_num;
+ mci->tot_dimms = tot_dimms;
--- /dev/null
+From 88c4bd90725557796c15878b7cb70066e9e6b5ab Mon Sep 17 00:00:00 2001
+From: Michal Wilczynski <m.wilczynski@samsung.com>
+Date: Thu, 3 Apr 2025 15:10:51 +0200
+Subject: firmware: thead: Fix buffer overflow and use standard endian macros
+
+From: Michal Wilczynski <m.wilczynski@samsung.com>
+
+commit 88c4bd90725557796c15878b7cb70066e9e6b5ab upstream.
+
+Addresses two issues in the TH1520 AON firmware protocol driver:
+
+1. Fix a potential buffer overflow where the code used unsafe pointer
+ arithmetic to access the 'mode' field through the 'resource' pointer
+ with an offset. This was flagged by Smatch static checker as:
+ "buffer overflow 'data' 2 <= 3"
+
+2. Replace custom RPC_SET_BE* and RPC_GET_BE* macros with standard
+ kernel endianness conversion macros (cpu_to_be16, etc.) for better
+ portability and maintainability.
+
+The functionality was re-tested with the GPU power-up sequence,
+confirming the GPU powers up correctly and the driver probes
+successfully.
+
+[ 12.702370] powervr ffef400000.gpu: [drm] loaded firmware
+powervr/rogue_36.52.104.182_v1.fw
+[ 12.711043] powervr ffef400000.gpu: [drm] FW version v1.0 (build
+6645434 OS)
+[ 12.719787] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on
+minor 0
+
+Fixes: e4b3cbd840e5 ("firmware: thead: Add AON firmware protocol driver")
+Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
+Closes: https://lore.kernel.org/all/17a0ccce-060b-4b9d-a3c4-8d5d5823b1c9@stanley.mountain/
+Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
+Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
+Acked-by: Drew Fustini <fustini@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/thead,th1520-aon.c | 7 --
+ include/linux/firmware/thead/thead,th1520-aon.h | 74 ------------------------
+ 2 files changed, 3 insertions(+), 78 deletions(-)
+
+--- a/drivers/firmware/thead,th1520-aon.c
++++ b/drivers/firmware/thead,th1520-aon.c
+@@ -170,10 +170,9 @@ int th1520_aon_power_update(struct th152
+ hdr->func = TH1520_AON_PM_FUNC_SET_RESOURCE_POWER_MODE;
+ hdr->size = TH1520_AON_RPC_MSG_NUM;
+
+- RPC_SET_BE16(&msg.resource, 0, rsrc);
+- RPC_SET_BE16(&msg.resource, 2,
+- (power_on ? TH1520_AON_PM_PW_MODE_ON :
+- TH1520_AON_PM_PW_MODE_OFF));
++ msg.resource = cpu_to_be16(rsrc);
++ msg.mode = cpu_to_be16(power_on ? TH1520_AON_PM_PW_MODE_ON :
++ TH1520_AON_PM_PW_MODE_OFF);
+
+ ret = th1520_aon_call_rpc(aon_chan, &msg);
+ if (ret)
+--- a/include/linux/firmware/thead/thead,th1520-aon.h
++++ b/include/linux/firmware/thead/thead,th1520-aon.h
+@@ -97,80 +97,6 @@ struct th1520_aon_rpc_ack_common {
+ #define RPC_GET_SVC_FLAG_ACK_TYPE(MESG) (((MESG)->svc & 0x40) >> 6)
+ #define RPC_SET_SVC_FLAG_ACK_TYPE(MESG, ACK) ((MESG)->svc |= (ACK) << 6)
+
+-#define RPC_SET_BE64(MESG, OFFSET, SET_DATA) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- u64 _offset = (OFFSET); \
+- u64 _set_data = (SET_DATA); \
+- data[_offset + 7] = _set_data & 0xFF; \
+- data[_offset + 6] = (_set_data & 0xFF00) >> 8; \
+- data[_offset + 5] = (_set_data & 0xFF0000) >> 16; \
+- data[_offset + 4] = (_set_data & 0xFF000000) >> 24; \
+- data[_offset + 3] = (_set_data & 0xFF00000000) >> 32; \
+- data[_offset + 2] = (_set_data & 0xFF0000000000) >> 40; \
+- data[_offset + 1] = (_set_data & 0xFF000000000000) >> 48; \
+- data[_offset + 0] = (_set_data & 0xFF00000000000000) >> 56; \
+- } while (0)
+-
+-#define RPC_SET_BE32(MESG, OFFSET, SET_DATA) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- u64 _offset = (OFFSET); \
+- u64 _set_data = (SET_DATA); \
+- data[_offset + 3] = (_set_data) & 0xFF; \
+- data[_offset + 2] = (_set_data & 0xFF00) >> 8; \
+- data[_offset + 1] = (_set_data & 0xFF0000) >> 16; \
+- data[_offset + 0] = (_set_data & 0xFF000000) >> 24; \
+- } while (0)
+-
+-#define RPC_SET_BE16(MESG, OFFSET, SET_DATA) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- u64 _offset = (OFFSET); \
+- u64 _set_data = (SET_DATA); \
+- data[_offset + 1] = (_set_data) & 0xFF; \
+- data[_offset + 0] = (_set_data & 0xFF00) >> 8; \
+- } while (0)
+-
+-#define RPC_SET_U8(MESG, OFFSET, SET_DATA) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- data[OFFSET] = (SET_DATA) & 0xFF; \
+- } while (0)
+-
+-#define RPC_GET_BE64(MESG, OFFSET, PTR) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- u64 _offset = (OFFSET); \
+- *(u32 *)(PTR) = \
+- (data[_offset + 7] | data[_offset + 6] << 8 | \
+- data[_offset + 5] << 16 | data[_offset + 4] << 24 | \
+- data[_offset + 3] << 32 | data[_offset + 2] << 40 | \
+- data[_offset + 1] << 48 | data[_offset + 0] << 56); \
+- } while (0)
+-
+-#define RPC_GET_BE32(MESG, OFFSET, PTR) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- u64 _offset = (OFFSET); \
+- *(u32 *)(PTR) = \
+- (data[_offset + 3] | data[_offset + 2] << 8 | \
+- data[_offset + 1] << 16 | data[_offset + 0] << 24); \
+- } while (0)
+-
+-#define RPC_GET_BE16(MESG, OFFSET, PTR) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- u64 _offset = (OFFSET); \
+- *(u16 *)(PTR) = (data[_offset + 1] | data[_offset + 0] << 8); \
+- } while (0)
+-
+-#define RPC_GET_U8(MESG, OFFSET, PTR) \
+- do { \
+- u8 *data = (u8 *)(MESG); \
+- *(u8 *)(PTR) = (data[OFFSET]); \
+- } while (0)
+-
+ /*
+ * Defines for SC PM Power Mode
+ */
--- /dev/null
+From 39ed7d89b973329cc5c764b65ba6302b17b1907e Mon Sep 17 00:00:00 2001
+From: Anthony Pighin <anthony.pighin@nokia.com>
+Date: Tue, 31 Mar 2026 14:26:32 -0400
+Subject: i2c: imx: zero-initialize dma_slave_config for eDMA
+
+From: Anthony Pighin <anthony.pighin@nokia.com>
+
+commit 39ed7d89b973329cc5c764b65ba6302b17b1907e upstream.
+
+commit 66d88e16f204 ("dmaengine: fsl-edma: read/write multiple registers
+in cyclic transactions") causes fsl_edma_fill_tcd() to read
+dst_port_window_size and src_port_window_size when building transfer
+control descriptors.
+
+Initialize the structure so unset fields are explicitly zero.
+
+Fixes: 66d88e16f204 ("dmaengine: fsl-edma: read/write multiple registers in cyclic transactions")
+Signed-off-by: Anthony Pighin <anthony.pighin@nokia.com>
+Cc: <stable@vger.kernel.org> # v6.14+
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20260331182632.888110-1-anthony.pighin@nokia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-imx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-imx.c
++++ b/drivers/i2c/busses/i2c-imx.c
+@@ -401,7 +401,7 @@ static void i2c_imx_reset_regs(struct im
+ static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx, dma_addr_t phy_addr)
+ {
+ struct imx_i2c_dma *dma;
+- struct dma_slave_config dma_sconfig;
++ struct dma_slave_config dma_sconfig = {};
+ struct device *dev = i2c_imx->adapter.dev.parent;
+ int ret;
+
--- /dev/null
+From 591478118293c1bd628de330a99eb1eb2ef8d76b Mon Sep 17 00:00:00 2001
+From: Emil Tantilov <emil.s.tantilov@intel.com>
+Date: Thu, 19 Mar 2026 14:13:33 -0700
+Subject: idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
+
+From: Emil Tantilov <emil.s.tantilov@intel.com>
+
+commit 591478118293c1bd628de330a99eb1eb2ef8d76b upstream.
+
+Switch from using the completion's raw spinlock to a local lock in the
+idpf_vc_xn struct. The conversion is safe because complete/_all() are
+called outside the lock and there is no reason to share the completion
+lock in the current logic. This avoids invalid wait context reported by
+the kernel due to the async handler taking BH spinlock:
+
+[ 805.726977] =============================
+[ 805.726991] [ BUG: Invalid wait context ]
+[ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE
+[ 805.727026] -----------------------------
+[ 805.727038] kworker/u261:0/572 is trying to lock:
+[ 805.727051] ff190da6a8dbb6a0 (&vport_config->mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
+[ 805.727099] other info that might help us debug this:
+[ 805.727111] context-{5:5}
+[ 805.727119] 3 locks held by kworker/u261:0/572:
+[ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730
+[ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter->mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730
+[ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf]
+[ 805.727218] stack backtrace:
+...
+[ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf]
+[ 805.727247] Call Trace:
+[ 805.727249] <TASK>
+[ 805.727251] dump_stack_lvl+0x77/0xb0
+[ 805.727259] __lock_acquire+0xb3b/0x2290
+[ 805.727268] ? __irq_work_queue_local+0x59/0x130
+[ 805.727275] lock_acquire+0xc6/0x2f0
+[ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
+[ 805.727284] ? _printk+0x5b/0x80
+[ 805.727290] _raw_spin_lock_bh+0x38/0x50
+[ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
+[ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
+[ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf]
+[ 805.727317] process_one_work+0x226/0x730
+[ 805.727322] worker_thread+0x19e/0x340
+[ 805.727325] ? __pfx_worker_thread+0x10/0x10
+[ 805.727328] kthread+0xf4/0x130
+[ 805.727333] ? __pfx_kthread+0x10/0x10
+[ 805.727336] ret_from_fork+0x32c/0x410
+[ 805.727345] ? __pfx_kthread+0x10/0x10
+[ 805.727347] ret_from_fork_asm+0x1a/0x30
+[ 805.727354] </TASK>
+
+Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
+Cc: stable@vger.kernel.org
+Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Reported-by: Ray Zhang <sgzhang@google.com>
+Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Tested-by: Samuel Salin <Samuel.salin@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 14 +++++---------
+ drivers/net/ethernet/intel/idpf/idpf_virtchnl.h | 5 +++--
+ 2 files changed, 8 insertions(+), 11 deletions(-)
+
+--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+@@ -284,26 +284,21 @@ dma_mem_error:
+ return err;
+ }
+
+-/* API for virtchnl "transaction" support ("xn" for short).
+- *
+- * We are reusing the completion lock to serialize the accesses to the
+- * transaction state for simplicity, but it could be its own separate synchro
+- * as well. For now, this API is only used from within a workqueue context;
+- * raw_spin_lock() is enough.
+- */
++/* API for virtchnl "transaction" support ("xn" for short). */
++
+ /**
+ * idpf_vc_xn_lock - Request exclusive access to vc transaction
+ * @xn: struct idpf_vc_xn* to access
+ */
+ #define idpf_vc_xn_lock(xn) \
+- raw_spin_lock(&(xn)->completed.wait.lock)
++ spin_lock(&(xn)->lock)
+
+ /**
+ * idpf_vc_xn_unlock - Release exclusive access to vc transaction
+ * @xn: struct idpf_vc_xn* to access
+ */
+ #define idpf_vc_xn_unlock(xn) \
+- raw_spin_unlock(&(xn)->completed.wait.lock)
++ spin_unlock(&(xn)->lock)
+
+ /**
+ * idpf_vc_xn_release_bufs - Release reference to reply buffer(s) and
+@@ -335,6 +330,7 @@ static void idpf_vc_xn_init(struct idpf_
+ xn->state = IDPF_VC_XN_IDLE;
+ xn->idx = i;
+ idpf_vc_xn_release_bufs(xn);
++ spin_lock_init(&xn->lock);
+ init_completion(&xn->completed);
+ }
+
+--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
+@@ -42,8 +42,8 @@ typedef int (*async_vc_cb) (struct idpf_
+ * struct idpf_vc_xn - Data structure representing virtchnl transactions
+ * @completed: virtchnl event loop uses that to signal when a reply is
+ * available, uses kernel completion API
+- * @state: virtchnl event loop stores the data below, protected by the
+- * completion's lock.
++ * @lock: protects the transaction state fields below
++ * @state: virtchnl event loop stores the data below, protected by @lock
+ * @reply_sz: Original size of reply, may be > reply_buf.iov_len; it will be
+ * truncated on its way to the receiver thread according to
+ * reply_buf.iov_len.
+@@ -58,6 +58,7 @@ typedef int (*async_vc_cb) (struct idpf_
+ */
+ struct idpf_vc_xn {
+ struct completion completed;
++ spinlock_t lock;
+ enum idpf_vc_xn_state state;
+ size_t reply_sz;
+ struct kvec reply;
--- /dev/null
+From d086fae65006368618104ba4c57779440eab2217 Mon Sep 17 00:00:00 2001
+From: Emil Tantilov <emil.s.tantilov@intel.com>
+Date: Thu, 19 Mar 2026 14:13:34 -0700
+Subject: idpf: improve locking around idpf_vc_xn_push_free()
+
+From: Emil Tantilov <emil.s.tantilov@intel.com>
+
+commit d086fae65006368618104ba4c57779440eab2217 upstream.
+
+Protect the set_bit() operation for the free_xn bitmask in
+idpf_vc_xn_push_free(), to make the locking consistent with rest of the
+code and avoid potential races in that logic.
+
+Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
+Cc: stable@vger.kernel.org
+Reported-by: Ray Zhang <sgzhang@google.com>
+Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Tested-by: Samuel Salin <Samuel.salin@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+@@ -399,7 +399,9 @@ static void idpf_vc_xn_push_free(struct
+ struct idpf_vc_xn *xn)
+ {
+ idpf_vc_xn_release_bufs(xn);
++ spin_lock_bh(&vcxn_mngr->xn_bm_lock);
+ set_bit(xn->idx, vcxn_mngr->free_xn_bm);
++ spin_unlock_bh(&vcxn_mngr->xn_bm_lock);
+ }
+
+ /**
--- /dev/null
+From 8e2a2420e267a515f6db56a6e9570b5cacd92919 Mon Sep 17 00:00:00 2001
+From: Emil Tantilov <emil.s.tantilov@intel.com>
+Date: Thu, 19 Mar 2026 14:13:35 -0700
+Subject: idpf: set the payload size before calling the async handler
+
+From: Emil Tantilov <emil.s.tantilov@intel.com>
+
+commit 8e2a2420e267a515f6db56a6e9570b5cacd92919 upstream.
+
+Set the payload size before forwarding the reply to the async handler.
+Without this, xn->reply_sz will be 0 and idpf_mac_filter_async_handler()
+will never get past the size check.
+
+Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
+Cc: stable@vger.kernel.org
+Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Reviewed-by: Li Li <boolli@google.com>
+Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Tested-by: Samuel Salin <Samuel.salin@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+@@ -612,6 +612,10 @@ idpf_vc_xn_forward_reply(struct idpf_ada
+ err = -ENXIO;
+ goto out_unlock;
+ case IDPF_VC_XN_ASYNC:
++ /* Set reply_sz from the actual payload so that async_handler
++ * can evaluate the response.
++ */
++ xn->reply_sz = ctlq_msg->data_len;
+ err = idpf_vc_xn_forward_async(adapter, xn, ctlq_msg);
+ idpf_vc_xn_unlock(xn);
+ return err;
--- /dev/null
+From b1e067240379f950a0022208e0685f3465c211cb Mon Sep 17 00:00:00 2001
+From: Alex Dvoretsky <advoretsky@gmail.com>
+Date: Thu, 12 Mar 2026 14:52:55 +0100
+Subject: igb: remove napi_synchronize() in igb_down()
+
+From: Alex Dvoretsky <advoretsky@gmail.com>
+
+commit b1e067240379f950a0022208e0685f3465c211cb upstream.
+
+When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9),
+the XSK buffer pool is destroyed but NAPI polling continues.
+igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing
+napi_complete_done() from clearing NAPI_STATE_SCHED.
+
+igb_down() calls napi_synchronize() before napi_disable() for each queue
+vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear,
+which never happens. igb_down() blocks indefinitely, the TX watchdog
+fires, and the TX queue remains permanently stalled.
+
+napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE.
+After a full-budget poll, __napi_poll() checks napi_disable_pending(). If
+set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop
+that napi_synchronize() cannot.
+
+napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible
+panic caused by Rx traffic arrival while interface is down").
+napi_disable() provides stronger guarantees: it prevents further
+scheduling and waits for any active poll to exit.
+Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a
+preceding napi_synchronize() in their down paths.
+
+Remove redundant napi_synchronize() call and reorder napi_disable()
+before igb_set_queue_napi() so the queue-to-NAPI mapping is only
+cleared after polling has fully stopped.
+
+Fixes: 2c6196013f84 ("igb: Add AF_XDP zero-copy Rx support")
+Cc: stable@vger.kernel.org
+Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Signed-off-by: Alex Dvoretsky <advoretsky@gmail.com>
+Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Tested-by: Patryk Holda <patryk.holda@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/igb/igb_main.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/intel/igb/igb_main.c
++++ b/drivers/net/ethernet/intel/igb/igb_main.c
+@@ -2203,9 +2203,8 @@ void igb_down(struct igb_adapter *adapte
+
+ for (i = 0; i < adapter->num_q_vectors; i++) {
+ if (adapter->q_vector[i]) {
+- napi_synchronize(&adapter->q_vector[i]->napi);
+- igb_set_queue_napi(adapter, i, NULL);
+ napi_disable(&adapter->q_vector[i]->napi);
++ igb_set_queue_napi(adapter, i, NULL);
+ }
+ }
+
--- /dev/null
+From 742de64b62b690a368dbeb846499eb8ac8ceedb9 Mon Sep 17 00:00:00 2001
+From: Janne Grunau <j@jannau.net>
+Date: Fri, 27 Mar 2026 09:30:29 +0100
+Subject: kbuild: modules-cpio-pkg: Respect INSTALL_MOD_PATH
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Janne Grunau <j@jannau.net>
+
+commit 742de64b62b690a368dbeb846499eb8ac8ceedb9 upstream.
+
+The modules-cpio-pkg target added in commit 2a9c8c0b59d3 ("kbuild: add
+target to build a cpio containing modules") is incompatible with
+initramfs with merged /lib and /usr/lib directories [1]. "/lib" cannot
+be a link and directory at the same time.
+Respect a non-empty INSTALL_MOD_PATH in the modules-cpio-pkg target so
+that `make INSTALL_MOD_PATH=/usr modules-cpio-pkg` results in the same
+module install location as `make INSTALL_MOD_PATH=/usr modules_install`.
+
+Tested with Fedora distribution initramfs produced by dracut.
+
+Link: https://systemd.io/THE_CASE_FOR_THE_USR_MERGE/ [1]
+Fixes: 2a9c8c0b59d3 ("kbuild: add target to build a cpio containing modules")
+Cc: stable@vger.kernel.org
+Reviewed-by: Simon Glass <sjg@chromium.org>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+Signed-off-by: Janne Grunau <j@jannau.net>
+Reviewed-by: Nicolas Schier <nsc@kernel.org>
+Tested-by: Nicolas Schier <nsc@kernel.org>
+Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
+Link: https://patch.msgid.link/20260327-kbuild-modules-cpio-pkg-usr-merge-v3-1-ef507dfa006c@jannau.net
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/Makefile.package | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/scripts/Makefile.package
++++ b/scripts/Makefile.package
+@@ -195,7 +195,7 @@ tar%-pkg: linux-$(KERNELRELEASE)-$(ARCH)
+ .tmp_modules_cpio: FORCE
+ $(Q)$(MAKE) -f $(srctree)/Makefile
+ $(Q)rm -rf $@
+- $(Q)$(MAKE) -f $(srctree)/Makefile INSTALL_MOD_PATH=$@ modules_install
++ $(Q)$(MAKE) -f $(srctree)/Makefile INSTALL_MOD_PATH=$@/$(INSTALL_MOD_PATH) modules_install
+
+ quiet_cmd_cpio = CPIO $@
+ cmd_cpio = $(CONFIG_SHELL) $(srctree)/usr/gen_initramfs.sh -o $@ $<
+@@ -265,6 +265,7 @@ help:
+ @echo ' tarxz-pkg - Build the kernel as a xz compressed tarball'
+ @echo ' tarzst-pkg - Build the kernel as a zstd compressed tarball'
+ @echo ' modules-cpio-pkg - Build the kernel modules as cpio archive'
++ @echo ' (uses INSTALL_MOD_PATH inside the archive)'
+ @echo ' perf-tar-src-pkg - Build the perf source tarball with no compression'
+ @echo ' perf-targz-src-pkg - Build the perf source tarball with gzip compression'
+ @echo ' perf-tarbz2-src-pkg - Build the perf source tarball with bz2 compression'
--- /dev/null
+From 307e0c5859b0aecc34180468b1aa76684adcf539 Mon Sep 17 00:00:00 2001
+From: Leo Timmins <leotimmins1974@gmail.com>
+Date: Wed, 25 Mar 2026 12:46:07 +0800
+Subject: liveupdate: propagate file deserialization failures
+
+From: Leo Timmins <leotimmins1974@gmail.com>
+
+commit 307e0c5859b0aecc34180468b1aa76684adcf539 upstream.
+
+luo_session_deserialize() ignored the return value from
+luo_file_deserialize(). As a result, a session could be left partially
+restored even though the /dev/liveupdate open path treats deserialization
+failures as fatal.
+
+Propagate the error so a failed file deserialization aborts session
+deserialization instead of silently continuing.
+
+Link: https://lkml.kernel.org/r/20260325044608.8407-1-leotimmins1974@gmail.com
+Link: https://lkml.kernel.org/r/20260325044608.8407-2-leotimmins1974@gmail.com
+Fixes: 16cec0d26521 ("liveupdate: luo_session: add ioctls for file preservation")
+Signed-off-by: Leo Timmins <leotimmins1974@gmail.com>
+Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
+Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
+Cc: Mike Rapoport <rppt@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/liveupdate/luo_session.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/kernel/liveupdate/luo_session.c
++++ b/kernel/liveupdate/luo_session.c
+@@ -558,8 +558,13 @@ int luo_session_deserialize(void)
+ }
+
+ scoped_guard(mutex, &session->mutex) {
+- luo_file_deserialize(&session->file_set,
+- &sh->ser[i].file_set_ser);
++ err = luo_file_deserialize(&session->file_set,
++ &sh->ser[i].file_set_ser);
++ }
++ if (err) {
++ pr_warn("Failed to deserialize files for session [%s] %pe\n",
++ session->name, ERR_PTR(err));
++ return err;
+ }
+ }
+
--- /dev/null
+From 4c04c6b47c361612b1d70cec8f7a60b1482d1400 Mon Sep 17 00:00:00 2001
+From: SeongJae Park <sj@kernel.org>
+Date: Thu, 2 Apr 2026 06:44:17 -0700
+Subject: mm/damon/stat: deallocate damon_call() failure leaking damon_ctx
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: SeongJae Park <sj@kernel.org>
+
+commit 4c04c6b47c361612b1d70cec8f7a60b1482d1400 upstream.
+
+damon_stat_start() always allocates the module's damon_ctx object
+(damon_stat_context). Meanwhile, if damon_call() in the function fails,
+the damon_ctx object is not deallocated. Hence, if the damon_call() is
+failed, and the user writes Y to “enabled” again, the previously
+allocated damon_ctx object is leaked.
+
+This cannot simply be fixed by deallocating the damon_ctx object when
+damon_call() fails. That's because damon_call() failure doesn't guarantee
+the kdamond main function, which accesses the damon_ctx object, is
+completely finished. In other words, if damon_stat_start() deallocates
+the damon_ctx object after damon_call() failure, the not-yet-terminated
+kdamond could access the freed memory (use-after-free).
+
+Fix the leak while avoiding the use-after-free by keeping returning
+damon_stat_start() without deallocating the damon_ctx object after
+damon_call() failure, but deallocating it when the function is invoked
+again and the kdamond is completely terminated. If the kdamond is not yet
+terminated, simply return -EAGAIN, as the kdamond will soon be terminated.
+
+The issue was discovered [1] by sashiko.
+
+Link: https://lkml.kernel.org/r/20260402134418.74121-1-sj@kernel.org
+Link: https://lore.kernel.org/20260401012428.86694-1-sj@kernel.org [1]
+Fixes: 405f61996d9d ("mm/damon/stat: use damon_call() repeat mode instead of damon_callback")
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org> # 6.17.x
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/stat.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/mm/damon/stat.c
++++ b/mm/damon/stat.c
+@@ -253,6 +253,12 @@ static int damon_stat_start(void)
+ {
+ int err;
+
++ if (damon_stat_context) {
++ if (damon_is_running(damon_stat_context))
++ return -EAGAIN;
++ damon_destroy_ctx(damon_stat_context);
++ }
++
+ damon_stat_context = damon_stat_build_ctx();
+ if (!damon_stat_context)
+ return -ENOMEM;
+@@ -269,6 +275,7 @@ static void damon_stat_stop(void)
+ {
+ damon_stop(&damon_stat_context, 1);
+ damon_destroy_ctx(damon_stat_context);
++ damon_stat_context = NULL;
+ }
+
+ static int damon_stat_enabled_store(
--- /dev/null
+From 0199390a6b92fc21860e1b858abf525c7e73b956 Mon Sep 17 00:00:00 2001
+From: SeongJae Park <sj@kernel.org>
+Date: Thu, 26 Mar 2026 17:32:22 -0700
+Subject: mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails
+
+From: SeongJae Park <sj@kernel.org>
+
+commit 0199390a6b92fc21860e1b858abf525c7e73b956 upstream.
+
+damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow
+the kdamond is stopped before the damon_call(). It could happen, for
+example, when te damon context was made for monitroing of a virtual
+address processes, and the process is terminated immediately, before the
+damon_call() invocation. In the case, the dyanmically allocated
+repeat_call_control is not deallocated and leaked.
+
+Fix the leak by deallocating the repeat_call_control under the
+damon_call() failure.
+
+This issue is discovered by sashiko [1].
+
+Link: https://lkml.kernel.org/r/20260327003224.55752-1-sj@kernel.org
+Link: https://lore.kernel.org/20260320020630.962-1-sj@kernel.org [1]
+Fixes: 04a06b139ec0 ("mm/damon/sysfs: use dynamically allocated repeat mode damon_call_control")
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org> [6.17+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/sysfs.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/damon/sysfs.c
++++ b/mm/damon/sysfs.c
+@@ -1673,7 +1673,8 @@ static int damon_sysfs_turn_damon_on(str
+ repeat_call_control->data = kdamond;
+ repeat_call_control->repeat = true;
+ repeat_call_control->dealloc_on_cancel = true;
+- damon_call(ctx, repeat_call_control);
++ if (damon_call(ctx, repeat_call_control))
++ kfree(repeat_call_control);
+ return err;
+ }
+
--- /dev/null
+From f58df566524ebcdfa394329c64f47e3c9257516e Mon Sep 17 00:00:00 2001
+From: Baolin Wang <baolin.wang@linux.alibaba.com>
+Date: Tue, 17 Mar 2026 17:29:55 +0800
+Subject: mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Baolin Wang <baolin.wang@linux.alibaba.com>
+
+commit f58df566524ebcdfa394329c64f47e3c9257516e upstream.
+
+When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I
+encountered some very strange crash issues showing up as "Bad page state":
+
+"
+[ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb
+[ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb
+[ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff)
+[ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000
+[ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000
+[ 734.496442] page dumped because: nonzero mapcount
+"
+
+After analyzing this page’s state, it is hard to understand why the
+mapcount is not 0 while the refcount is 0, since this page is not where
+the issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can
+reproduce the crash as well and captured the first warning where the issue
+appears:
+
+"
+[ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0
+[ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
+[ 734.469315] memcg:ffff000807a8ec00
+[ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540"
+[ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff)
+......
+[ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1),
+const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *:
+(struct folio *)_compound_head(page + nr_pages - 1))) != folio)
+[ 734.469390] ------------[ cut here ]------------
+[ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468,
+CPU#90: stress-ng-mlock/9430
+[ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P)
+[ 734.469555] set_pte_range+0xd8/0x2f8
+[ 734.469566] filemap_map_folio_range+0x190/0x400
+[ 734.469579] filemap_map_pages+0x348/0x638
+[ 734.469583] do_fault_around+0x140/0x198
+......
+[ 734.469640] el0t_64_sync+0x184/0x188
+"
+
+The code that triggers the warning is: "VM_WARN_ON_FOLIO(page_folio(page +
+nr_pages - 1) != folio, folio)", which indicates that set_pte_range()
+tried to map beyond the large folio’s size.
+
+By adding more debug information, I found that 'nr_pages' had overflowed
+in filemap_map_pages(), causing set_pte_range() to establish mappings for
+a range exceeding the folio size, potentially corrupting fields of pages
+that do not belong to this folio (e.g., page->_mapcount).
+
+After above analysis, I think the possible race is as follows:
+
+CPU 0 CPU 1
+filemap_map_pages() ext4_setattr()
+ //get and lock folio with old inode->i_size
+ next_uptodate_folio()
+
+ .......
+ //shrink the inode->i_size
+ i_size_write(inode, attr->ia_size);
+
+ //calculate the end_pgoff with the new inode->i_size
+ file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1;
+ end_pgoff = min(end_pgoff, file_end);
+
+ ......
+ //nr_pages can be overflowed, cause xas.xa_index > end_pgoff
+ end = folio_next_index(folio) - 1;
+ nr_pages = min(end, end_pgoff) - xas.xa_index + 1;
+
+ ......
+ //map large folio
+ filemap_map_folio_range()
+ ......
+ //truncate folios
+ truncate_pagecache(inode, inode->i_size);
+
+To fix this issue, move the 'end_pgoff' calculation before
+next_uptodate_folio(), so the retrieved folio stays consistent with the
+file end to avoid 'nr_pages' calculation overflow. After this patch, the
+crash issue is gone.
+
+Link: https://lkml.kernel.org/r/1cf1ac59018fc647a87b0dad605d4056a71c14e4.1773739704.git.baolin.wang@linux.alibaba.com
+Fixes: 743a2753a02e ("filemap: cap PTE range to be created to allowed zero fill in folio_map_range()")
+Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
+Reported-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
+Tested-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
+Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
+Acked-by: David Hildenbrand (Arm) <david@kernel.org>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Daniel Gomez <da.gomez@samsung.com>
+Cc: "Darrick J. Wong" <djwong@kernel.org>
+Cc: Dave Chinner <dchinner@redhat.com>
+Cc: David Howells <dhowells@redhat.com>
+Cc: Hannes Reinecke <hare@suse.de>
+Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
+Cc: Luis Chamberalin <mcgrof@kernel.org>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Pankaj Raghav <p.raghav@samsung.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/filemap.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/mm/filemap.c
++++ b/mm/filemap.c
+@@ -3883,14 +3883,19 @@ vm_fault_t filemap_map_pages(struct vm_f
+ unsigned int nr_pages = 0, folio_type;
+ unsigned short mmap_miss = 0, mmap_miss_saved;
+
++ /*
++ * Recalculate end_pgoff based on file_end before calling
++ * next_uptodate_folio() to avoid races with concurrent
++ * truncation.
++ */
++ file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1;
++ end_pgoff = min(end_pgoff, file_end);
++
+ rcu_read_lock();
+ folio = next_uptodate_folio(&xas, mapping, end_pgoff);
+ if (!folio)
+ goto out;
+
+- file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1;
+- end_pgoff = min(end_pgoff, file_end);
+-
+ /*
+ * Do not allow to map with PMD across i_size to preserve
+ * SIGBUS semantics.
--- /dev/null
+From 2ecbe06abf9bfb2261cd6464a6bc3a3615625402 Mon Sep 17 00:00:00 2001
+From: Hao Li <hao.li@linux.dev>
+Date: Mon, 30 Mar 2026 11:57:49 +0800
+Subject: mm/memory_hotplug: maintain N_NORMAL_MEMORY during hotplug
+
+From: Hao Li <hao.li@linux.dev>
+
+commit 2ecbe06abf9bfb2261cd6464a6bc3a3615625402 upstream.
+
+N_NORMAL_MEMORY is initialized from zone population at boot, but memory
+hotplug currently only updates N_MEMORY. As a result, a node that gains
+normal memory via hotplug can remain invisible to users iterating over
+N_NORMAL_MEMORY, while a node that loses its last normal memory can stay
+incorrectly marked as such.
+
+The most visible effect is that
+/sys/devices/system/node/has_normal_memory does not report a node even
+after that node has gained normal memory via hotplug.
+
+Also, list_lru-based shrinkers can undercount objects on such a node
+and may skip reclaim on that node entirely, which can lead to a higher
+memory footprint than expected.
+
+Restore N_NORMAL_MEMORY maintenance directly in online_pages() and
+offline_pages(). Set the bit when a node that currently lacks normal
+memory onlines pages into a zone <= ZONE_NORMAL, and clear it when
+offlining removes the last present pages from zones <= ZONE_NORMAL.
+
+This restores the intended semantics without bringing back the old
+status_change_nid_normal notifier plumbing which was removed in
+8d2882a8edb8.
+
+Current users that benefit include list_lru, zswap, nfsd filecache,
+hugetlb_cgroup, and has_normal_memory sysfs reporting.
+
+Link: https://lkml.kernel.org/r/20260330035941.518186-1-hao.li@linux.dev
+Fixes: 8d2882a8edb8 ("mm,memory_hotplug: remove status_change_nid_normal and update documentation")
+Signed-off-by: Hao Li <hao.li@linux.dev>
+Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>
+Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
+Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>
+Acked-by: David Hildenbrand (Arm) <david@kernel.org>
+Cc: Oscar Salvador <osalvador@suse.de>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory_hotplug.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/mm/memory_hotplug.c
++++ b/mm/memory_hotplug.c
+@@ -1209,6 +1209,13 @@ int online_pages(unsigned long pfn, unsi
+
+ if (node_arg.nid >= 0)
+ node_set_state(nid, N_MEMORY);
++ /*
++ * Check whether we are adding normal memory to the node for the first
++ * time.
++ */
++ if (!node_state(nid, N_NORMAL_MEMORY) && zone_idx(zone) <= ZONE_NORMAL)
++ node_set_state(nid, N_NORMAL_MEMORY);
++
+ if (need_zonelists_rebuild)
+ build_all_zonelists(NULL);
+
+@@ -1908,6 +1915,8 @@ int offline_pages(unsigned long start_pf
+ unsigned long flags;
+ char *reason;
+ int ret;
++ unsigned long normal_pages = 0;
++ enum zone_type zt;
+
+ /*
+ * {on,off}lining is constrained to full memory sections (or more
+@@ -2056,6 +2065,17 @@ int offline_pages(unsigned long start_pf
+ init_per_zone_wmark_min();
+
+ /*
++ * Check whether this operation removes the last normal memory from
++ * the node. We do this before clearing N_MEMORY to avoid the possible
++ * transient "!N_MEMORY && N_NORMAL_MEMORY" state.
++ */
++ if (zone_idx(zone) <= ZONE_NORMAL) {
++ for (zt = 0; zt <= ZONE_NORMAL; zt++)
++ normal_pages += pgdat->node_zones[zt].present_pages;
++ if (!normal_pages)
++ node_clear_state(node, N_NORMAL_MEMORY);
++ }
++ /*
+ * Make sure to mark the node as memory-less before rebuilding the zone
+ * list. Otherwise this node would still appear in the fallback lists.
+ */
--- /dev/null
+From 894f99eb535edc4514f756818f3c4f688ba53a59 Mon Sep 17 00:00:00 2001
+From: Sechang Lim <rhkrqnwk98@gmail.com>
+Date: Tue, 31 Mar 2026 18:08:11 +0000
+Subject: mm/vma: fix memory leak in __mmap_region()
+
+From: Sechang Lim <rhkrqnwk98@gmail.com>
+
+commit 894f99eb535edc4514f756818f3c4f688ba53a59 upstream.
+
+commit 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare
+swaps the file") handled the success path by skipping get_file() via
+file_doesnt_need_get, but missed the error path.
+
+When /dev/zero is mmap'd with MAP_SHARED, mmap_zero_prepare() calls
+shmem_zero_setup_desc() which allocates a new shmem file to back the
+mapping. If __mmap_new_vma() subsequently fails, this replacement
+file is never fput()'d - the original is released by
+ksys_mmap_pgoff(), but nobody releases the new one.
+
+Add fput() for the swapped file in the error path.
+
+Reproducible with fault injection.
+
+FAULT_INJECTION: forcing a failure.
+name failslab, interval 1, probability 0, space 0, times 1
+CPU: 2 UID: 0 PID: 366 Comm: syz.7.14 Not tainted 7.0.0-rc6 #2 PREEMPT(full)
+Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x164/0x1f0
+ should_fail_ex+0x525/0x650
+ should_failslab+0xdf/0x140
+ kmem_cache_alloc_noprof+0x78/0x630
+ vm_area_alloc+0x24/0x160
+ __mmap_region+0xf6b/0x2660
+ mmap_region+0x2eb/0x3a0
+ do_mmap+0xc79/0x1240
+ vm_mmap_pgoff+0x252/0x4c0
+ ksys_mmap_pgoff+0xf8/0x120
+ __x64_sys_mmap+0x12a/0x190
+ do_syscall_64+0xa9/0x580
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+ </TASK>
+
+kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
+BUG: memory leak
+unreferenced object 0xffff8881118aca80 (size 360):
+ comm "syz.7.14", pid 366, jiffies 4294913255
+ hex dump (first 32 bytes):
+ 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
+ ff ff ff ff ff ff ff ff c0 28 4d ae ff ff ff ff .........(M.....
+ backtrace (crc db0f53bc):
+ kmem_cache_alloc_noprof+0x3ab/0x630
+ alloc_empty_file+0x5a/0x1e0
+ alloc_file_pseudo+0x135/0x220
+ __shmem_file_setup+0x274/0x420
+ shmem_zero_setup_desc+0x9c/0x170
+ mmap_zero_prepare+0x123/0x140
+ __mmap_region+0xdda/0x2660
+ mmap_region+0x2eb/0x3a0
+ do_mmap+0xc79/0x1240
+ vm_mmap_pgoff+0x252/0x4c0
+ ksys_mmap_pgoff+0xf8/0x120
+ __x64_sys_mmap+0x12a/0x190
+ do_syscall_64+0xa9/0x580
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+Found by syzkaller.
+
+Link: https://lkml.kernel.org/r/20260331180811.1333348-1-rhkrqnwk98@gmail.com
+Fixes: 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare swaps the file")
+Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
+Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
+Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
+Cc: Jann Horn <jannh@google.com>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
+Cc: Pedro Falcato <pfalcato@suse.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/vma.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/mm/vma.c
++++ b/mm/vma.c
+@@ -2774,6 +2774,13 @@ unacct_error:
+ if (map.charged)
+ vm_unacct_memory(map.charged);
+ abort_munmap:
++ /*
++ * This indicates that .mmap_prepare has set a new file, differing from
++ * desc->vm_file. But since we're aborting the operation, only the
++ * original file will be cleaned up. Ensure we clean up both.
++ */
++ if (map.file_doesnt_need_get)
++ fput(map.file);
+ vms_abort_munmap_vmas(&map.vms, &map.mas_detach);
+ return error;
+ }
--- /dev/null
+From dff34ef879c5e73298443956a8b391311ba78d57 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 27 Mar 2026 11:52:05 +0100
+Subject: mmc: vub300: fix NULL-deref on disconnect
+
+From: Johan Hovold <johan@kernel.org>
+
+commit dff34ef879c5e73298443956a8b391311ba78d57 upstream.
+
+Make sure to deregister the controller before dropping the reference to
+the driver data on disconnect to avoid NULL-pointer dereferences or
+use-after-free.
+
+Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
+Cc: stable@vger.kernel.org # 3.0+
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/vub300.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/vub300.c
++++ b/drivers/mmc/host/vub300.c
+@@ -2365,8 +2365,8 @@ static void vub300_disconnect(struct usb
+ usb_set_intfdata(interface, NULL);
+ /* prevent more I/O from starting */
+ vub300->interface = NULL;
+- kref_put(&vub300->kref, vub300_delete);
+ mmc_remove_host(mmc);
++ kref_put(&vub300->kref, vub300_delete);
+ pr_info("USB vub300 remote SDIO host controller[%d]"
+ " now disconnected", ifnum);
+ return;
--- /dev/null
+From 8f4d20a710225ec7a565f6a0459862d3b1f32330 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 27 Mar 2026 11:52:06 +0100
+Subject: mmc: vub300: fix use-after-free on disconnect
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 8f4d20a710225ec7a565f6a0459862d3b1f32330 upstream.
+
+The vub300 driver maintains an explicit reference count for the
+controller and its driver data and the last reference can in theory be
+dropped after the driver has been unbound.
+
+This specifically means that the controller allocation must not be
+device managed as that can lead to use-after-free.
+
+Note that the lifetime is currently also incorrectly tied the parent USB
+device rather than interface, which can lead to memory leaks if the
+driver is unbound without its device being physically disconnected (e.g.
+on probe deferral).
+
+Fix both issues by reverting to non-managed allocation of the controller.
+
+Fixes: dcfdd698dc52 ("mmc: vub300: Use devm_mmc_alloc_host() helper")
+Cc: stable@vger.kernel.org # 6.17+
+Cc: Binbin Zhou <zhoubinbin@loongson.cn>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/vub300.c | 17 +++++++++++------
+ 1 file changed, 11 insertions(+), 6 deletions(-)
+
+--- a/drivers/mmc/host/vub300.c
++++ b/drivers/mmc/host/vub300.c
+@@ -369,11 +369,14 @@ struct vub300_mmc_host {
+ static void vub300_delete(struct kref *kref)
+ { /* kref callback - softirq */
+ struct vub300_mmc_host *vub300 = kref_to_vub300_mmc_host(kref);
++ struct mmc_host *mmc = vub300->mmc;
++
+ usb_free_urb(vub300->command_out_urb);
+ vub300->command_out_urb = NULL;
+ usb_free_urb(vub300->command_res_urb);
+ vub300->command_res_urb = NULL;
+ usb_put_dev(vub300->udev);
++ mmc_free_host(mmc);
+ /*
+ * and hence also frees vub300
+ * which is contained at the end of struct mmc
+@@ -2112,7 +2115,7 @@ static int vub300_probe(struct usb_inter
+ goto error1;
+ }
+ /* this also allocates memory for our VUB300 mmc host device */
+- mmc = devm_mmc_alloc_host(&udev->dev, sizeof(*vub300));
++ mmc = mmc_alloc_host(sizeof(*vub300), &udev->dev);
+ if (!mmc) {
+ retval = -ENOMEM;
+ dev_err(&udev->dev, "not enough memory for the mmc_host\n");
+@@ -2269,7 +2272,7 @@ static int vub300_probe(struct usb_inter
+ dev_err(&vub300->udev->dev,
+ "Could not find two sets of bulk-in/out endpoint pairs\n");
+ retval = -EINVAL;
+- goto error4;
++ goto err_free_host;
+ }
+ retval =
+ usb_control_msg(vub300->udev, usb_rcvctrlpipe(vub300->udev, 0),
+@@ -2278,14 +2281,14 @@ static int vub300_probe(struct usb_inter
+ 0x0000, 0x0000, &vub300->hc_info,
+ sizeof(vub300->hc_info), 1000);
+ if (retval < 0)
+- goto error4;
++ goto err_free_host;
+ retval =
+ usb_control_msg(vub300->udev, usb_sndctrlpipe(vub300->udev, 0),
+ SET_ROM_WAIT_STATES,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ firmware_rom_wait_states, 0x0000, NULL, 0, 1000);
+ if (retval < 0)
+- goto error4;
++ goto err_free_host;
+ dev_info(&vub300->udev->dev,
+ "operating_mode = %s %s %d MHz %s %d byte USB packets\n",
+ (mmc->caps & MMC_CAP_SDIO_IRQ) ? "IRQs" : "POLL",
+@@ -2300,7 +2303,7 @@ static int vub300_probe(struct usb_inter
+ 0x0000, 0x0000, &vub300->system_port_status,
+ sizeof(vub300->system_port_status), 1000);
+ if (retval < 0) {
+- goto error4;
++ goto err_free_host;
+ } else if (sizeof(vub300->system_port_status) == retval) {
+ vub300->card_present =
+ (0x0001 & vub300->system_port_status.port_flags) ? 1 : 0;
+@@ -2308,7 +2311,7 @@ static int vub300_probe(struct usb_inter
+ (0x0010 & vub300->system_port_status.port_flags) ? 1 : 0;
+ } else {
+ retval = -EINVAL;
+- goto error4;
++ goto err_free_host;
+ }
+ usb_set_intfdata(interface, vub300);
+ INIT_DELAYED_WORK(&vub300->pollwork, vub300_pollwork_thread);
+@@ -2338,6 +2341,8 @@ static int vub300_probe(struct usb_inter
+ return 0;
+ error6:
+ timer_delete_sync(&vub300->inactivity_timer);
++err_free_host:
++ mmc_free_host(mmc);
+ /*
+ * and hence also frees vub300
+ * which is contained at the end of struct mmc
--- /dev/null
+From deb4605671cfae3b2803cfbbf4739e7245248398 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Wed, 25 Mar 2026 18:20:30 -0700
+Subject: modpost: Declare extra_warn with unused attribute
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit deb4605671cfae3b2803cfbbf4739e7245248398 upstream.
+
+A recent strengthening of -Wunused-but-set-variable (enabled with -Wall)
+in clang under a new subwarning, -Wunused-but-set-global, points out an
+unused static global variable in scripts/mod/modpost.c:
+
+ scripts/mod/modpost.c:59:13: error: variable 'extra_warn' set but not used [-Werror,-Wunused-but-set-global]
+ 59 | static bool extra_warn;
+ | ^
+
+This variable has been unused since commit 6c6c1fc09de3 ("modpost:
+require a MODULE_DESCRIPTION()") but that is expected, as there are
+currently no extra warnings at W=1 right now. Declare the variable with
+the unused attribute to make it clear to the compiler that this variable
+may be unused.
+
+Cc: stable@vger.kernel.org
+Fixes: 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()")
+Link: https://patch.msgid.link/20260325-modpost-extra_warn-unused-but-set-global-v1-1-2e84003b7e81@kernel.org
+Reviewed-by: Nicolas Schier <nsc@kernel.org>
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/mod/modpost.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/scripts/mod/modpost.c
++++ b/scripts/mod/modpost.c
+@@ -56,7 +56,7 @@ static bool allow_missing_ns_imports;
+
+ static bool error_occurred;
+
+-static bool extra_warn;
++static bool extra_warn __attribute__((unused));
+
+ bool target_is_big_endian;
+ bool host_is_big_endian;
--- /dev/null
+From 6dede3967619b5944003227a5d09fdc21ed57d10 Mon Sep 17 00:00:00 2001
+From: David Carlier <devnexen@gmail.com>
+Date: Wed, 1 Apr 2026 22:12:18 +0100
+Subject: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()
+
+From: David Carlier <devnexen@gmail.com>
+
+commit 6dede3967619b5944003227a5d09fdc21ed57d10 upstream.
+
+When dma_map_single() fails in tse_start_xmit(), the function returns
+NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the
+stack the packet was consumed, the skb is never freed, leaking memory
+on every DMA mapping failure.
+
+Add dev_kfree_skb_any() before returning to properly free the skb.
+
+Fixes: bbd2190ce96d ("Altera TSE: Add main and header file for Altera Ethernet Driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Carlier <devnexen@gmail.com>
+Link: https://patch.msgid.link/20260401211218.279185-1-devnexen@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/altera/altera_tse_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/altera/altera_tse_main.c
++++ b/drivers/net/ethernet/altera/altera_tse_main.c
+@@ -572,6 +572,7 @@ static netdev_tx_t tse_start_xmit(struct
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(priv->device, dma_addr)) {
+ netdev_err(priv->dev, "%s: DMA mapping error\n", __func__);
++ dev_kfree_skb_any(skb);
+ ret = NETDEV_TX_OK;
+ goto out;
+ }
--- /dev/null
+From 076344a6ad9d1308faaed1402fdcfdda68b604ab Mon Sep 17 00:00:00 2001
+From: David Carlier <devnexen@gmail.com>
+Date: Sun, 5 Apr 2026 06:52:40 +0100
+Subject: net: lan966x: fix page pool leak in error paths
+
+From: David Carlier <devnexen@gmail.com>
+
+commit 076344a6ad9d1308faaed1402fdcfdda68b604ab upstream.
+
+lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if
+the subsequent fdma_alloc_coherent() call fails, leaking the pool.
+
+Similarly, lan966x_fdma_init() frees the coherent DMA memory when
+lan966x_fdma_tx_alloc() fails but does not destroy the page pool that
+was successfully created by lan966x_fdma_rx_alloc(), leaking it.
+
+Add the missing page_pool_destroy() calls in both error paths.
+
+Fixes: 11871aba1974 ("net: lan96x: Use page_pool API")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Carlier <devnexen@gmail.com>
+Link: https://patch.msgid.link/20260405055241.35767-3-devnexen@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+@@ -119,8 +119,10 @@ static int lan966x_fdma_rx_alloc(struct
+ return PTR_ERR(rx->page_pool);
+
+ err = fdma_alloc_coherent(lan966x->dev, fdma);
+- if (err)
++ if (err) {
++ page_pool_destroy(rx->page_pool);
+ return err;
++ }
+
+ fdma_dcbs_init(fdma, FDMA_DCB_INFO_DATAL(fdma->db_size),
+ FDMA_DCB_STATUS_INTR);
+@@ -958,6 +960,7 @@ int lan966x_fdma_init(struct lan966x *la
+ err = lan966x_fdma_tx_alloc(&lan966x->tx);
+ if (err) {
+ fdma_free_coherent(lan966x->dev, &lan966x->rx.fdma);
++ page_pool_destroy(lan966x->rx.page_pool);
+ return err;
+ }
+
--- /dev/null
+From 3fd0da4fd8851a7e62d009b7db6c4a05b092bc19 Mon Sep 17 00:00:00 2001
+From: David Carlier <devnexen@gmail.com>
+Date: Sun, 5 Apr 2026 06:52:39 +0100
+Subject: net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()
+
+From: David Carlier <devnexen@gmail.com>
+
+commit 3fd0da4fd8851a7e62d009b7db6c4a05b092bc19 upstream.
+
+page_pool_create() can return an ERR_PTR on failure. The return value
+is used unconditionally in the loop that follows, passing the error
+pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),
+which dereferences it, causing a kernel oops.
+
+Add an IS_ERR check after page_pool_create() to return early on failure.
+
+Fixes: 11871aba1974 ("net: lan96x: Use page_pool API")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Carlier <devnexen@gmail.com>
+Link: https://patch.msgid.link/20260405055241.35767-2-devnexen@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+@@ -91,6 +91,8 @@ static int lan966x_fdma_rx_alloc_page_po
+ pp_params.dma_dir = DMA_BIDIRECTIONAL;
+
+ rx->page_pool = page_pool_create(&pp_params);
++ if (unlikely(IS_ERR(rx->page_pool)))
++ return PTR_ERR(rx->page_pool);
+
+ for (int i = 0; i < lan966x->num_phys_ports; ++i) {
+ struct lan966x_port *port;
--- /dev/null
+From 59c3d55a946cacdb4181600723c20ac4f4c20c84 Mon Sep 17 00:00:00 2001
+From: David Carlier <devnexen@gmail.com>
+Date: Sun, 5 Apr 2026 06:52:41 +0100
+Subject: net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()
+
+From: David Carlier <devnexen@gmail.com>
+
+commit 59c3d55a946cacdb4181600723c20ac4f4c20c84 upstream.
+
+When lan966x_fdma_reload() fails to allocate new RX buffers, the restore
+path restarts DMA using old descriptors whose pages were already freed
+via lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() can
+release pages back to the buddy allocator, the hardware may DMA into
+memory now owned by other kernel subsystems.
+
+Additionally, on the restore path, the newly created page pool (if
+allocation partially succeeded) is overwritten without being destroyed,
+leaking it.
+
+Fix both issues by deferring the release of old pages until after the
+new allocation succeeds. Save the old page array before the allocation
+so old pages can be freed on the success path. On the failure path, the
+old descriptors, pages and page pool are all still valid, making the
+restore safe. Also ensure the restore path re-enables NAPI and wakes
+the netdev, matching the success path.
+
+Fixes: 89ba464fcf54 ("net: lan966x: refactor buffer reload function")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Carlier <devnexen@gmail.com>
+Link: https://patch.msgid.link/20260405055241.35767-4-devnexen@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 21 +++++++++++++++---
+ 1 file changed, 18 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+@@ -813,9 +813,15 @@ static int lan966x_qsys_sw_status(struct
+
+ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
+ {
++ struct page *(*old_pages)[FDMA_RX_DCB_MAX_DBS];
+ struct page_pool *page_pool;
+ struct fdma fdma_rx_old;
+- int err;
++ int err, i, j;
++
++ old_pages = kmemdup(lan966x->rx.page, sizeof(lan966x->rx.page),
++ GFP_KERNEL);
++ if (!old_pages)
++ return -ENOMEM;
+
+ /* Store these for later to free them */
+ memcpy(&fdma_rx_old, &lan966x->rx.fdma, sizeof(struct fdma));
+@@ -826,7 +832,6 @@ static int lan966x_fdma_reload(struct la
+ lan966x_fdma_stop_netdev(lan966x);
+
+ lan966x_fdma_rx_disable(&lan966x->rx);
+- lan966x_fdma_rx_free_pages(&lan966x->rx);
+ lan966x->rx.page_order = round_up(new_mtu, PAGE_SIZE) / PAGE_SIZE - 1;
+ lan966x->rx.max_mtu = new_mtu;
+ err = lan966x_fdma_rx_alloc(&lan966x->rx);
+@@ -834,6 +839,11 @@ static int lan966x_fdma_reload(struct la
+ goto restore;
+ lan966x_fdma_rx_start(&lan966x->rx);
+
++ for (i = 0; i < fdma_rx_old.n_dcbs; ++i)
++ for (j = 0; j < fdma_rx_old.n_dbs; ++j)
++ page_pool_put_full_page(page_pool,
++ old_pages[i][j], false);
++
+ fdma_free_coherent(lan966x->dev, &fdma_rx_old);
+
+ page_pool_destroy(page_pool);
+@@ -841,12 +851,17 @@ static int lan966x_fdma_reload(struct la
+ lan966x_fdma_wakeup_netdev(lan966x);
+ napi_enable(&lan966x->napi);
+
+- return err;
++ kfree(old_pages);
++ return 0;
+ restore:
+ lan966x->rx.page_pool = page_pool;
+ memcpy(&lan966x->rx.fdma, &fdma_rx_old, sizeof(struct fdma));
+ lan966x_fdma_rx_start(&lan966x->rx);
+
++ lan966x_fdma_wakeup_netdev(lan966x);
++ napi_enable(&lan966x->napi);
++
++ kfree(old_pages);
+ return err;
+ }
+
--- /dev/null
+From a9d4f4f6e65e0bf9bbddedecc84d67249991979c Mon Sep 17 00:00:00 2001
+From: Michael Guralnik <michaelgur@nvidia.com>
+Date: Fri, 3 Apr 2026 12:17:56 +0300
+Subject: net/mlx5: Update the list of the PCI supported devices
+
+From: Michael Guralnik <michaelgur@nvidia.com>
+
+commit a9d4f4f6e65e0bf9bbddedecc84d67249991979c upstream.
+
+Add the upcoming ConnectX-10 NVLink-C2C device ID to the table of
+supported PCI device IDs.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
+Reviewed-by: Patrisious Haddad <phaddad@nvidia.com>
+Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20260403091756.139583-1-tariqt@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
+@@ -2267,6 +2267,7 @@ static const struct pci_device_id mlx5_c
+ { PCI_VDEVICE(MELLANOX, 0x1023) }, /* ConnectX-8 */
+ { PCI_VDEVICE(MELLANOX, 0x1025) }, /* ConnectX-9 */
+ { PCI_VDEVICE(MELLANOX, 0x1027) }, /* ConnectX-10 */
++ { PCI_VDEVICE(MELLANOX, 0x2101) }, /* ConnectX-10 NVLink-C2C */
+ { PCI_VDEVICE(MELLANOX, 0xa2d2) }, /* BlueField integrated ConnectX-5 network controller */
+ { PCI_VDEVICE(MELLANOX, 0xa2d3), MLX5_PCI_DEV_IS_VF}, /* BlueField integrated ConnectX-5 network controller VF */
+ { PCI_VDEVICE(MELLANOX, 0xa2d6) }, /* BlueField-2 integrated ConnectX-6 Dx network controller */
--- /dev/null
+From b76254c55dc8f23edc089027dd3f8792554c69fb Mon Sep 17 00:00:00 2001
+From: Pengpeng Hou <pengpeng@iscas.ac.cn>
+Date: Thu, 2 Apr 2026 15:12:07 +0800
+Subject: net: qualcomm: qca_uart: report the consumed byte on RX skb allocation failure
+
+From: Pengpeng Hou <pengpeng@iscas.ac.cn>
+
+commit b76254c55dc8f23edc089027dd3f8792554c69fb upstream.
+
+qca_tty_receive() consumes each input byte before checking whether a
+completed frame needs a fresh receive skb. When the current byte completes
+a frame, the driver delivers that frame and then allocates a new skb for
+the next one.
+
+If that allocation fails, the current code returns i even though data[i]
+has already been consumed and may already have completed the delivered
+frame. Since serdev interprets the return value as the number of accepted
+bytes, this under-reports progress by one byte and can replay the final
+byte of the completed frame into a fresh parser state on the next call.
+
+Return i + 1 in that failure path so the accepted-byte count matches the
+actual receive-state progress.
+
+Fixes: dfc768fbe618 ("net: qualcomm: add QCA7000 UART driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
+Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20260402071207.4036-1-pengpeng@iscas.ac.cn
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/qualcomm/qca_uart.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/qualcomm/qca_uart.c
++++ b/drivers/net/ethernet/qualcomm/qca_uart.c
+@@ -100,7 +100,7 @@ qca_tty_receive(struct serdev_device *se
+ if (!qca->rx_skb) {
+ netdev_dbg(netdev, "recv: out of RX resources\n");
+ n_stats->rx_errors++;
+- return i;
++ return i + 1;
+ }
+ }
+ }
--- /dev/null
+From 51f4e090b9f87b40c21b6daadb5c06e6c0a07b67 Mon Sep 17 00:00:00 2001
+From: Tyllis Xu <livelycarpet87@gmail.com>
+Date: Tue, 31 Mar 2026 23:47:07 -0500
+Subject: net: stmmac: fix integer underflow in chain mode
+
+From: Tyllis Xu <livelycarpet87@gmail.com>
+
+commit 51f4e090b9f87b40c21b6daadb5c06e6c0a07b67 upstream.
+
+The jumbo_frm() chain-mode implementation unconditionally computes
+
+ len = nopaged_len - bmax;
+
+where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is
+BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit()
+decides to invoke jumbo_frm() based on skb->len (total length including
+page fragments):
+
+ is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc);
+
+When a packet has a small linear portion (nopaged_len <= bmax) but a
+large total length due to page fragments (skb->len > bmax), the
+subtraction wraps as an unsigned integer, producing a huge len value
+(~0xFFFFxxxx). This causes the while (len != 0) loop to execute
+hundreds of thousands of iterations, passing skb->data + bmax * i
+pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less
+SoCs (the typical deployment for stmmac), this maps arbitrary kernel
+memory to the DMA engine, constituting a kernel memory disclosure and
+potential memory corruption from hardware.
+
+Fix this by introducing a buf_len local variable clamped to
+min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then
+always safe: it is zero when the linear portion fits within a single
+descriptor, causing the while (len != 0) loop to be skipped naturally,
+and the fragment loop in stmmac_xmit() handles page fragments afterward.
+
+Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tyllis Xu <LivelyCarpet87@gmail.com>
+Link: https://patch.msgid.link/20260401044708.1386919-1-LivelyCarpet87@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
++++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+@@ -20,7 +20,7 @@ static int jumbo_frm(struct stmmac_tx_qu
+ unsigned int nopaged_len = skb_headlen(skb);
+ struct stmmac_priv *priv = tx_q->priv_data;
+ unsigned int entry = tx_q->cur_tx;
+- unsigned int bmax, des2;
++ unsigned int bmax, buf_len, des2;
+ unsigned int i = 1, len;
+ struct dma_desc *desc;
+
+@@ -31,17 +31,18 @@ static int jumbo_frm(struct stmmac_tx_qu
+ else
+ bmax = BUF_SIZE_2KiB;
+
+- len = nopaged_len - bmax;
++ buf_len = min_t(unsigned int, nopaged_len, bmax);
++ len = nopaged_len - buf_len;
+
+ des2 = dma_map_single(priv->device, skb->data,
+- bmax, DMA_TO_DEVICE);
++ buf_len, DMA_TO_DEVICE);
+ desc->des2 = cpu_to_le32(des2);
+ if (dma_mapping_error(priv->device, des2))
+ return -1;
+ tx_q->tx_skbuff_dma[entry].buf = des2;
+- tx_q->tx_skbuff_dma[entry].len = bmax;
++ tx_q->tx_skbuff_dma[entry].len = buf_len;
+ /* do not close the descriptor and do not set own bit */
+- stmmac_prepare_tx_desc(priv, desc, 1, bmax, csum, STMMAC_CHAIN_MODE,
++ stmmac_prepare_tx_desc(priv, desc, 1, buf_len, csum, STMMAC_CHAIN_MODE,
+ 0, false, skb->len);
+
+ while (len != 0) {
--- /dev/null
+From a9b8b18364fffce4c451e6f6fd218fa4ab646705 Mon Sep 17 00:00:00 2001
+From: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg>
+Date: Fri, 3 Apr 2026 09:36:17 +0800
+Subject: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption
+
+From: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg>
+
+commit a9b8b18364fffce4c451e6f6fd218fa4ab646705 upstream.
+
+The -EBUSY handling in tls_do_encryption(), introduced by commit
+859054147318 ("net: tls: handle backlogging of crypto requests"), has
+a use-after-free due to double cleanup of encrypt_pending and the
+scatterlist entry.
+
+When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to
+the cryptd backlog and the async callback tls_encrypt_done() will be
+invoked upon completion. That callback unconditionally restores the
+scatterlist entry (sge->offset, sge->length) and decrements
+ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an
+error, the synchronous error path in tls_do_encryption() performs the
+same cleanup again, double-decrementing encrypt_pending and
+double-restoring the scatterlist.
+
+The double-decrement corrupts the encrypt_pending sentinel (initialized
+to 1), making tls_encrypt_async_wait() permanently skip the wait for
+pending async callbacks. A subsequent sendmsg can then free the
+tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still
+pending, resulting in a use-after-free when the callback fires on the
+freed record.
+
+Fix this by skipping the synchronous cleanup when the -EBUSY async
+wait returns an error, since the callback has already handled
+encrypt_pending and sge restoration.
+
+Fixes: 859054147318 ("net: tls: handle backlogging of crypto requests")
+Cc: stable@vger.kernel.org
+Signed-off-by: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg>
+Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
+Link: https://patch.msgid.link/20260403013617.2838875-1-ramdhan@starlabs.sg
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tls/tls_sw.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/net/tls/tls_sw.c
++++ b/net/tls/tls_sw.c
+@@ -584,6 +584,16 @@ static int tls_do_encryption(struct sock
+ if (rc == -EBUSY) {
+ rc = tls_encrypt_async_wait(ctx);
+ rc = rc ?: -EINPROGRESS;
++ /*
++ * The async callback tls_encrypt_done() has already
++ * decremented encrypt_pending and restored the sge on
++ * both success and error. Skip the synchronous cleanup
++ * below on error, just remove the record and return.
++ */
++ if (rc != -EINPROGRESS) {
++ list_del(&rec->list);
++ return rc;
++ }
+ }
+ if (!rc || rc != -EINPROGRESS) {
+ atomic_dec(&ctx->encrypt_pending);
--- /dev/null
+From f8dca15a1b190787bbd03285304b569631160eda Mon Sep 17 00:00:00 2001
+From: Tuan Do <tuan@calif.io>
+Date: Fri, 3 Apr 2026 00:33:17 -0700
+Subject: netfilter: nft_ct: fix use-after-free in timeout object destroy
+
+From: Tuan Do <tuan@calif.io>
+
+commit f8dca15a1b190787bbd03285304b569631160eda upstream.
+
+nft_ct_timeout_obj_destroy() frees the timeout object with kfree()
+immediately after nf_ct_untimeout(), without waiting for an RCU grace
+period. Concurrent packet processing on other CPUs may still hold
+RCU-protected references to the timeout object obtained via
+rcu_dereference() in nf_ct_timeout_data().
+
+Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer
+freeing until after an RCU grace period, matching the approach already
+used in nfnetlink_cttimeout.c.
+
+KASAN report:
+ BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0
+ Read of size 4 at addr ffff8881035fe19c by task exploit/80
+
+ Call Trace:
+ nf_conntrack_tcp_packet+0x1381/0x29d0
+ nf_conntrack_in+0x612/0x8b0
+ nf_hook_slow+0x70/0x100
+ __ip_local_out+0x1b2/0x210
+ tcp_sendmsg_locked+0x722/0x1580
+ __sys_sendto+0x2d8/0x320
+
+ Allocated by task 75:
+ nft_ct_timeout_obj_init+0xf6/0x290
+ nft_obj_init+0x107/0x1b0
+ nf_tables_newobj+0x680/0x9c0
+ nfnetlink_rcv_batch+0xc29/0xe00
+
+ Freed by task 26:
+ nft_obj_destroy+0x3f/0xa0
+ nf_tables_trans_destroy_work+0x51c/0x5c0
+ process_one_work+0x2c4/0x5a0
+
+Fixes: 7e0b2b57f01d ("netfilter: nft_ct: add ct timeout support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tuan Do <tuan@calif.io>
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/netfilter/nf_conntrack_timeout.h | 1 +
+ net/netfilter/nft_ct.c | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/net/netfilter/nf_conntrack_timeout.h
++++ b/include/net/netfilter/nf_conntrack_timeout.h
+@@ -14,6 +14,7 @@
+ struct nf_ct_timeout {
+ __u16 l3num;
+ const struct nf_conntrack_l4proto *l4proto;
++ struct rcu_head rcu;
+ char data[];
+ };
+
+--- a/net/netfilter/nft_ct.c
++++ b/net/netfilter/nft_ct.c
+@@ -1021,7 +1021,7 @@ static void nft_ct_timeout_obj_destroy(c
+ nf_queue_nf_hook_drop(ctx->net);
+ nf_ct_untimeout(ctx->net, timeout);
+ nf_ct_netns_put(ctx->net, ctx->family);
+- kfree(priv->timeout);
++ kfree_rcu(priv->timeout, rcu);
+ }
+
+ static int nft_ct_timeout_obj_dump(struct sk_buff *skb,
--- /dev/null
+From c71ba669b570c7b3f86ec875be222ea11dacb352 Mon Sep 17 00:00:00 2001
+From: Pengpeng Hou <pengpeng@iscas.ac.cn>
+Date: Sun, 5 Apr 2026 08:40:00 +0800
+Subject: nfc: pn533: allocate rx skb before consuming bytes
+
+From: Pengpeng Hou <pengpeng@iscas.ac.cn>
+
+commit c71ba669b570c7b3f86ec875be222ea11dacb352 upstream.
+
+pn532_receive_buf() reports the number of accepted bytes to the serdev
+core. The current code consumes bytes into recv_skb and may already hand
+a complete frame to pn533_recv_frame() before allocating a fresh receive
+buffer.
+
+If that alloc_skb() fails, the callback returns 0 even though it has
+already consumed bytes, and it leaves recv_skb as NULL for the next
+receive callback. That breaks the receive_buf() accounting contract and
+can also lead to a NULL dereference on the next skb_put_u8().
+
+Allocate the receive skb lazily before consuming the next byte instead.
+If allocation fails, return the number of bytes already accepted.
+
+Fixes: c656aa4c27b1 ("nfc: pn533: add UART phy driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
+Link: https://patch.msgid.link/20260405094003.3-pn533-v2-pengpeng@iscas.ac.cn
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nfc/pn533/uart.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/nfc/pn533/uart.c
++++ b/drivers/nfc/pn533/uart.c
+@@ -211,6 +211,13 @@ static size_t pn532_receive_buf(struct s
+
+ timer_delete(&dev->cmd_timeout);
+ for (i = 0; i < count; i++) {
++ if (!dev->recv_skb) {
++ dev->recv_skb = alloc_skb(PN532_UART_SKB_BUFF_LEN,
++ GFP_KERNEL);
++ if (!dev->recv_skb)
++ return i;
++ }
++
+ if (unlikely(!skb_tailroom(dev->recv_skb)))
+ skb_trim(dev->recv_skb, 0);
+
+@@ -219,9 +226,7 @@ static size_t pn532_receive_buf(struct s
+ continue;
+
+ pn533_recv_frame(dev->priv, dev->recv_skb, 0);
+- dev->recv_skb = alloc_skb(PN532_UART_SKB_BUFF_LEN, GFP_KERNEL);
+- if (!dev->recv_skb)
+- return 0;
++ dev->recv_skb = NULL;
+ }
+
+ return i;
--- /dev/null
+From 4ab604b3f3aa8dcccc7505f5d310016682a99d5f Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Wed, 25 Mar 2026 12:29:09 -0700
+Subject: platform/x86/intel-uncore-freq: Handle autonomous UFS status bit
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit 4ab604b3f3aa8dcccc7505f5d310016682a99d5f upstream.
+
+When the AUTONOMOUS_UFS_DISABLED bit is set in the header, the ELC
+(Efficiency Latency Control) feature is non-functional. Hence, return
+error for read or write to ELC attributes.
+
+Fixes: bb516dc79c4a ("platform/x86/intel-uncore-freq: Add support for efficiency latency control")
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260325192909.3417322-1-srinivas.pandruvada@linux.intel.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
++++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
+@@ -537,6 +537,7 @@ static void set_cdie_id(int domain_id, s
+ #define UNCORE_VERSION_MASK GENMASK_ULL(7, 0)
+ #define UNCORE_LOCAL_FABRIC_CLUSTER_ID_MASK GENMASK_ULL(15, 8)
+ #define UNCORE_CLUSTER_OFF_MASK GENMASK_ULL(7, 0)
++#define UNCORE_AUTONOMOUS_UFS_DISABLED BIT(32)
+ #define UNCORE_MAX_CLUSTER_PER_DOMAIN 8
+
+ static int uncore_probe(struct auxiliary_device *auxdev, const struct auxiliary_device_id *id)
+@@ -598,6 +599,7 @@ static int uncore_probe(struct auxiliary
+
+ for (i = 0; i < num_resources; ++i) {
+ struct tpmi_uncore_power_domain_info *pd_info;
++ bool auto_ufs_enabled;
+ struct resource *res;
+ u64 cluster_offset;
+ u8 cluster_mask;
+@@ -647,6 +649,8 @@ static int uncore_probe(struct auxiliary
+ continue;
+ }
+
++ auto_ufs_enabled = !(header & UNCORE_AUTONOMOUS_UFS_DISABLED);
++
+ /* Find out number of clusters in this resource */
+ pd_info->cluster_count = hweight8(cluster_mask);
+
+@@ -689,7 +693,9 @@ static int uncore_probe(struct auxiliary
+
+ cluster_info->uncore_root = tpmi_uncore;
+
+- if (TPMI_MINOR_VERSION(pd_info->ufs_header_ver) >= UNCORE_ELC_SUPPORTED_VERSION)
++ if ((TPMI_MINOR_VERSION(pd_info->ufs_header_ver) >=
++ UNCORE_ELC_SUPPORTED_VERSION) &&
++ auto_ufs_enabled)
+ cluster_info->elc_supported = true;
+
+ ret = uncore_freq_add_entry(&cluster_info->uncore_data, 0);
--- /dev/null
+From e1415b9418eb22b4a7a1ef4b4aec9dd0a49e3fa7 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Wed, 25 Mar 2026 12:26:38 -0700
+Subject: platform/x86: ISST: Reset core count to 0
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit e1415b9418eb22b4a7a1ef4b4aec9dd0a49e3fa7 upstream.
+
+Based on feature revision, number of buckets can be less than the
+TRL_MAX_BUCKETS. In that case core counts in the remaining buckets
+can be set to some invalid values.
+
+Hence reset core count to 0 for all buckets before assigning correct
+values.
+
+Fixes: 885d1c2a30b7 ("platform/x86: ISST: Support SST-TF revision 2")
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260325192638.3417281-1-srinivas.pandruvada@linux.intel.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
++++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
+@@ -1460,6 +1460,8 @@ static int isst_if_get_turbo_freq_info(v
+ SST_MUL_FACTOR_FREQ)
+ }
+
++ memset(turbo_freq.bucket_core_counts, 0, sizeof(turbo_freq.bucket_core_counts));
++
+ if (feature_rev >= 2) {
+ bool has_tf_info_8 = false;
+
--- /dev/null
+From e91d5f94acf68618ea3ad9c92ac28614e791ae7d Mon Sep 17 00:00:00 2001
+From: Jacky Bai <ping.bai@nxp.com>
+Date: Fri, 20 Mar 2026 16:43:46 +0800
+Subject: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled
+
+From: Jacky Bai <ping.bai@nxp.com>
+
+commit e91d5f94acf68618ea3ad9c92ac28614e791ae7d upstream.
+
+Keep the NOC_HDCP clock always enabled to fix the potential hang
+caused by the NoC ADB400 port power down handshake.
+
+Fixes: 77b0ddb42add ("soc: imx: add i.MX8MP HDMI blk ctrl HDCP/HRV_MWR")
+Signed-off-by: Jacky Bai <ping.bai@nxp.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
++++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
+@@ -352,9 +352,6 @@ static void imx8mp_hdmi_blk_ctrl_power_o
+ regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(12));
+ regmap_clear_bits(bc->regmap, HDMI_TX_CONTROL0, BIT(3));
+ break;
+- case IMX8MP_HDMIBLK_PD_HDCP:
+- regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(11));
+- break;
+ case IMX8MP_HDMIBLK_PD_HRV:
+ regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(3) | BIT(4) | BIT(5));
+ regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(15));
+@@ -408,9 +405,6 @@ static void imx8mp_hdmi_blk_ctrl_power_o
+ regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(7));
+ regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(22) | BIT(24));
+ break;
+- case IMX8MP_HDMIBLK_PD_HDCP:
+- regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(11));
+- break;
+ case IMX8MP_HDMIBLK_PD_HRV:
+ regmap_clear_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(15));
+ regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(3) | BIT(4) | BIT(5));
+@@ -439,7 +433,7 @@ static int imx8mp_hdmi_power_notifier(st
+ regmap_write(bc->regmap, HDMI_RTX_CLK_CTL0, 0x0);
+ regmap_write(bc->regmap, HDMI_RTX_CLK_CTL1, 0x0);
+ regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL0,
+- BIT(0) | BIT(1) | BIT(10));
++ BIT(0) | BIT(1) | BIT(10) | BIT(11));
+ regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(0));
+
+ /*
--- /dev/null
+From 4cd46ea0eb4504f7f4fea92cb4601c5c9a3e545e Mon Sep 17 00:00:00 2001
+From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Date: Sat, 21 Feb 2026 19:15:18 +0100
+Subject: Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower"
+
+From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+
+commit 4cd46ea0eb4504f7f4fea92cb4601c5c9a3e545e upstream.
+
+This reverts commit c24a9b698fb02cd0723fa8375abab07f94b97b10.
+
+It's been found that there's a significant per-unit variance in accepted
+supply voltages and the current set still makes some units unstable.
+
+Revert back to nominal values.
+
+Cc: stable@vger.kernel.org
+Fixes: c24a9b698fb0 ("arm64: dts: imx8mq-librem5: Set the DVS voltages lower")
+Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Signed-off-by: Frank Li <Frank.Li@nxp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts | 2 -
+ arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 22 +++++---------------
+ 2 files changed, 7 insertions(+), 17 deletions(-)
+
+--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
++++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
+@@ -7,7 +7,7 @@
+
+ &a53_opp_table {
+ opp-1000000000 {
+- opp-microvolt = <950000>;
++ opp-microvolt = <1000000>;
+ };
+ };
+
+--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
++++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+@@ -844,8 +844,8 @@
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-ramp-delay = <1250>;
+- rohm,dvs-run-voltage = <880000>;
+- rohm,dvs-idle-voltage = <820000>;
++ rohm,dvs-run-voltage = <900000>;
++ rohm,dvs-idle-voltage = <850000>;
+ rohm,dvs-suspend-voltage = <810000>;
+ regulator-always-on;
+ };
+@@ -856,8 +856,8 @@
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-ramp-delay = <1250>;
+- rohm,dvs-run-voltage = <950000>;
+- rohm,dvs-idle-voltage = <850000>;
++ rohm,dvs-run-voltage = <1000000>;
++ rohm,dvs-idle-voltage = <900000>;
+ regulator-always-on;
+ };
+
+@@ -866,14 +866,14 @@
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+- rohm,dvs-run-voltage = <850000>;
++ rohm,dvs-run-voltage = <900000>;
+ };
+
+ buck4_reg: BUCK4 {
+ regulator-name = "buck4";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+- rohm,dvs-run-voltage = <930000>;
++ rohm,dvs-run-voltage = <1000000>;
+ };
+
+ buck5_reg: BUCK5 {
+@@ -1407,13 +1407,3 @@
+ fsl,ext-reset-output;
+ status = "okay";
+ };
+-
+-&a53_opp_table {
+- opp-1000000000 {
+- opp-microvolt = <850000>;
+- };
+-
+- opp-1500000000 {
+- opp-microvolt = <950000>;
+- };
+-};
--- /dev/null
+From 29d1f56c4f3001b7f547123e0a307c009ac717f8 Mon Sep 17 00:00:00 2001
+From: Heiko Stuebner <heiko@sntech.de>
+Date: Tue, 10 Feb 2026 13:01:42 +0100
+Subject: Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro"
+
+From: Heiko Stuebner <heiko@sntech.de>
+
+commit 29d1f56c4f3001b7f547123e0a307c009ac717f8 upstream.
+
+This reverts commit 6d54d935062e2d4a7d3f779ceb9eeff108d0535d.
+
+It seems there are different variants of the Wifi chipset in use on the
+Pinebook Pro. And according to the reported regression - see Closes
+below, the reverted change causes issues with one Wifi chipset.
+
+The original commit message indicates a "further description" only and
+does not indicate this would fix an actual problem, so a revert should
+not cause further problems.
+
+Fixes: 6d54d935062e ("arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro")
+Cc: Jan Palus <jpalus@fastmail.com>
+Cc: Peter Robinson <pbrobinson@gmail.com>
+Cc: Thorsten Leemhuis <regressions@leemhuis.info>
+Cc: stable@vger.kernel.org
+Closes: https://lore.kernel.org/r/aUKOlj-RvTYlrpiS@rock.grzadka/
+Tested-by: Jan Palus <jpalus@fastmail.com>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patch.msgid.link/20260210120142.698512-1-heiko@sntech.de
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 18 ------------------
+ 1 file changed, 18 deletions(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+@@ -879,12 +879,6 @@
+ };
+ };
+
+- wifi {
+- wifi_host_wake_l: wifi-host-wake-l {
+- rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+- };
+- };
+-
+ wireless-bluetooth {
+ bt_wake_pin: bt-wake-pin {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+@@ -942,19 +936,7 @@
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+- #address-cells = <1>;
+- #size-cells = <0>;
+ status = "okay";
+-
+- brcmf: wifi@1 {
+- compatible = "brcm,bcm4329-fmac";
+- reg = <1>;
+- interrupt-parent = <&gpio0>;
+- interrupts = <RK_PA3 IRQ_TYPE_LEVEL_HIGH>;
+- interrupt-names = "host-wake";
+- pinctrl-names = "default";
+- pinctrl-0 = <&wifi_host_wake_l>;
+- };
+ };
+
+ &sdhci {
mips-mm-rewrite-tlb-uniquification-for-the-hidden-bi.patch
btrfs-remove-pointless-out-labels-from-extent-tree.c.patch
btrfs-fix-incorrect-return-value-after-changing-leaf.patch
+i2c-imx-zero-initialize-dma_slave_config-for-edma.patch
+netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.patch
+firmware-thead-fix-buffer-overflow-and-use-standard-endian-macros.patch
+workqueue-add-pool_workqueue-to-pending_pwqs-list-when-unplugging-multiple-inactive-works.patch
+modpost-declare-extra_warn-with-unused-attribute.patch
+xfrm-clear-trailing-padding-in-build_polexpire.patch
+xfrm-hold-dev-ref-until-after-transport_finish-nf_hook.patch
+tipc-fix-bc_ackers-underflow-on-duplicate-grp_ack_msg.patch
+kbuild-modules-cpio-pkg-respect-install_mod_path.patch
+asoc-sof-intel-hda-modify-period-size-constraints-for-ace4.patch
+wifi-brcmsmac-fix-dma_free_coherent-size.patch
+x86-mce-amd-filter-bogus-hardware-errors-on-zen3-clients.patch
+platform-x86-isst-reset-core-count-to-0.patch
+platform-x86-intel-uncore-freq-handle-autonomous-ufs-status-bit.patch
+revert-arm64-dts-rockchip-further-describe-the-wifi-for-the-pinebook-pro.patch
+revert-arm64-dts-imx8mq-librem5-set-the-dvs-voltages-lower.patch
+arm64-dts-imx8mq-librem5-bump-buck1-suspend-voltage-up-to-0.85v.patch
+arm64-dts-renesas-sparrow-hawk-reserve-first-128-mib-of-dram.patch
+arm64-dts-hisilicon-poplar-correct-pcie-reset-gpio-polarity.patch
+arm64-dts-hisilicon-hi3798cv200-add-missing-dma-ranges.patch
+liveupdate-propagate-file-deserialization-failures.patch
+nfc-pn533-allocate-rx-skb-before-consuming-bytes.patch
+batman-adv-reject-oversized-global-tt-response-buffers.patch
+x.509-fix-out-of-bounds-access-when-parsing-extensions.patch
+edac-mc-fix-error-path-ordering-in-edac_mc_alloc.patch
+net-tls-fix-use-after-free-in-ebusy-error-path-of-tls_do_encryption.patch
+net-altera-tse-fix-skb-leak-on-dma-mapping-error-in-tse_start_xmit.patch
+batman-adv-hold-claim-backbone-gateways-by-reference.patch
+drm-i915-gt-fix-refcount-underflow-in-intel_engine_park_heartbeat.patch
+drm-i915-psr-do-not-use-pipe_src-as-borders-for-su-area.patch
+net-mlx5-update-the-list-of-the-pci-supported-devices.patch
+pmdomain-imx8mp-blk-ctrl-keep-the-noc_hdcp-clock-enabled.patch
+igb-remove-napi_synchronize-in-igb_down.patch
+mm-vma-fix-memory-leak-in-__mmap_region.patch
+mm-memory_hotplug-maintain-n_normal_memory-during-hotplug.patch
+mm-damon-sysfs-dealloc-repeat_call_control-if-damon_call-fails.patch
+mm-damon-stat-deallocate-damon_call-failure-leaking-damon_ctx.patch
+mmc-vub300-fix-null-deref-on-disconnect.patch
+mmc-vub300-fix-use-after-free-on-disconnect.patch
+net-qualcomm-qca_uart-report-the-consumed-byte-on-rx-skb-allocation-failure.patch
+net-stmmac-fix-integer-underflow-in-chain-mode.patch
+mm-filemap-fix-nr_pages-calculation-overflow-in-filemap_map_pages.patch
+idpf-fix-preempt_rt-raw-bh-spinlock-nesting-for-async-vc-handling.patch
+idpf-improve-locking-around-idpf_vc_xn_push_free.patch
+idpf-set-the-payload-size-before-calling-the-async-handler.patch
+net-lan966x-fix-page_pool-error-handling-in-lan966x_fdma_rx_alloc_page_pool.patch
+net-lan966x-fix-page-pool-leak-in-error-paths.patch
+net-lan966x-fix-use-after-free-and-leak-in-lan966x_fdma_reload.patch
--- /dev/null
+From 48a5fe38772b6f039522469ee6131a67838221a8 Mon Sep 17 00:00:00 2001
+From: Oleh Konko <security@1seal.org>
+Date: Thu, 2 Apr 2026 09:48:57 +0000
+Subject: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG
+
+From: Oleh Konko <security@1seal.org>
+
+commit 48a5fe38772b6f039522469ee6131a67838221a8 upstream.
+
+The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements
+bc_ackers on every inbound group ACK, even when the same member has
+already acknowledged the current broadcast round.
+
+Because bc_ackers is a u16, a duplicate ACK received after the last
+legitimate ACK wraps the counter to 65535. Once wrapped,
+tipc_group_bc_cong() keeps reporting congestion and later group
+broadcasts on the affected socket stay blocked until the group is
+recreated.
+
+Fix this by ignoring duplicate or stale ACKs before touching bc_acked or
+bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and
+prevents the underflow path.
+
+Fixes: 2f487712b893 ("tipc: guarantee that group broadcast doesn't bypass group unicast")
+Cc: stable@vger.kernel.org
+Signed-off-by: Oleh Konko <security@1seal.org>
+Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/41a4833f368641218e444fdcff822039.security@1seal.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tipc/group.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/tipc/group.c
++++ b/net/tipc/group.c
+@@ -746,6 +746,7 @@ void tipc_group_proto_rcv(struct tipc_gr
+ u32 port = msg_origport(hdr);
+ struct tipc_member *m, *pm;
+ u16 remitted, in_flight;
++ u16 acked;
+
+ if (!grp)
+ return;
+@@ -798,7 +799,10 @@ void tipc_group_proto_rcv(struct tipc_gr
+ case GRP_ACK_MSG:
+ if (!m)
+ return;
+- m->bc_acked = msg_grp_bc_acked(hdr);
++ acked = msg_grp_bc_acked(hdr);
++ if (less_eq(acked, m->bc_acked))
++ return;
++ m->bc_acked = acked;
+ if (--grp->bc_ackers)
+ return;
+ list_del_init(&m->small_win);
--- /dev/null
+From 12cd7632757a54ce586e36040210b1a738a0fc53 Mon Sep 17 00:00:00 2001
+From: Thomas Fourier <fourier.thomas@gmail.com>
+Date: Wed, 18 Feb 2026 14:07:37 +0100
+Subject: wifi: brcmsmac: Fix dma_free_coherent() size
+
+From: Thomas Fourier <fourier.thomas@gmail.com>
+
+commit 12cd7632757a54ce586e36040210b1a738a0fc53 upstream.
+
+dma_alloc_consistent() may change the size to align it. The new size is
+saved in alloced.
+
+Change the free size to match the allocation size.
+
+Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
+Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
+Link: https://patch.msgid.link/20260218130741.46566-3-fourier.thomas@gmail.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
+@@ -483,7 +483,7 @@ static void *dma_ringalloc(struct dma_in
+ if (((desc_strtaddr + size - 1) & boundary) != (desc_strtaddr
+ & boundary)) {
+ *alignbits = dma_align_sizetobits(size);
+- dma_free_coherent(di->dmadev, size, va, *descpa);
++ dma_free_coherent(di->dmadev, *alloced, va, *descpa);
+ va = dma_alloc_consistent(di, size, *alignbits,
+ alloced, descpa);
+ }
--- /dev/null
+From 703ccb63ae9f7444d6ff876d024e17f628103c69 Mon Sep 17 00:00:00 2001
+From: Matthew Brost <matthew.brost@intel.com>
+Date: Tue, 31 Mar 2026 18:07:39 -0700
+Subject: workqueue: Add pool_workqueue to pending_pwqs list when unplugging multiple inactive works
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthew Brost <matthew.brost@intel.com>
+
+commit 703ccb63ae9f7444d6ff876d024e17f628103c69 upstream.
+
+In unplug_oldest_pwq(), the first inactive work item on the
+pool_workqueue is activated correctly. However, if multiple inactive
+works exist on the same pool_workqueue, subsequent works fail to
+activate because wq_node_nr_active.pending_pwqs is empty — the list
+insertion is skipped when the pool_workqueue is plugged.
+
+Fix this by checking for additional inactive works in
+unplug_oldest_pwq() and updating wq_node_nr_active.pending_pwqs
+accordingly.
+
+Fixes: 4c065dbce1e8 ("workqueue: Enable unbound cpumask update on ordered workqueues")
+Cc: stable@vger.kernel.org
+Cc: Carlos Santa <carlos.santa@intel.com>
+Cc: Ryan Neph <ryanneph@google.com>
+Cc: Lai Jiangshan <jiangshanlai@gmail.com>
+Cc: Waiman Long <longman@redhat.com>
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Matthew Brost <matthew.brost@intel.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Acked-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/workqueue.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/kernel/workqueue.c
++++ b/kernel/workqueue.c
+@@ -1849,8 +1849,20 @@ static void unplug_oldest_pwq(struct wor
+ raw_spin_lock_irq(&pwq->pool->lock);
+ if (pwq->plugged) {
+ pwq->plugged = false;
+- if (pwq_activate_first_inactive(pwq, true))
++ if (pwq_activate_first_inactive(pwq, true)) {
++ /*
++ * While plugged, queueing skips activation which
++ * includes bumping the nr_active count and adding the
++ * pwq to nna->pending_pwqs if the count can't be
++ * obtained. We need to restore both for the pwq being
++ * unplugged. The first call activates the first
++ * inactive work item and the second, if there are more
++ * inactive, puts the pwq on pending_pwqs.
++ */
++ pwq_activate_first_inactive(pwq, false);
++
+ kick_pool(pwq->pool);
++ }
+ }
+ raw_spin_unlock_irq(&pwq->pool->lock);
+ }
--- /dev/null
+From d702c3408213bb12bd570bb97204d8340d141c51 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Tue, 7 Apr 2026 12:58:18 +0200
+Subject: X.509: Fix out-of-bounds access when parsing extensions
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit d702c3408213bb12bd570bb97204d8340d141c51 upstream.
+
+Leo reports an out-of-bounds access when parsing a certificate with
+empty Basic Constraints or Key Usage extension because the first byte of
+the extension is read before checking its length. Fix it.
+
+The bug can be triggered by an unprivileged user by submitting a
+specially crafted certificate to the kernel through the keyrings(7) API.
+Leo has demonstrated this with a proof-of-concept program responsibly
+disclosed off-list.
+
+Fixes: 30eae2b037af ("KEYS: X.509: Parse Basic Constraints for CA")
+Fixes: 567671281a75 ("KEYS: X.509: Parse Key Usage")
+Reported-by: Leo Lin <leo@depthfirst.com> # off-list
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Reviewed-by: Ignat Korchagin <ignat@linux.win>
+Cc: stable@vger.kernel.org # v6.4+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/asymmetric_keys/x509_cert_parser.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/crypto/asymmetric_keys/x509_cert_parser.c
++++ b/crypto/asymmetric_keys/x509_cert_parser.c
+@@ -584,10 +584,10 @@ int x509_process_extension(void *context
+ * 0x04 is where keyCertSign lands in this bit string
+ * 0x80 is where digitalSignature lands in this bit string
+ */
+- if (v[0] != ASN1_BTS)
+- return -EBADMSG;
+ if (vlen < 4)
+ return -EBADMSG;
++ if (v[0] != ASN1_BTS)
++ return -EBADMSG;
+ if (v[2] >= 8)
+ return -EBADMSG;
+ if (v[3] & 0x80)
+@@ -620,10 +620,10 @@ int x509_process_extension(void *context
+ * (Expect 0xFF if the CA is TRUE)
+ * vlen should match the entire extension size
+ */
+- if (v[0] != (ASN1_CONS_BIT | ASN1_SEQ))
+- return -EBADMSG;
+ if (vlen < 2)
+ return -EBADMSG;
++ if (v[0] != (ASN1_CONS_BIT | ASN1_SEQ))
++ return -EBADMSG;
+ if (v[1] != vlen - 2)
+ return -EBADMSG;
+ /* Empty SEQUENCE means CA:FALSE (default value omitted per DER) */
--- /dev/null
+From 0422b07bc4c296b736e240d95d21fbfebbfaa2ca Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Sat, 28 Feb 2026 09:08:14 -0500
+Subject: x86/mce/amd: Filter bogus hardware errors on Zen3 clients
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+commit 0422b07bc4c296b736e240d95d21fbfebbfaa2ca upstream.
+
+Users have been observing multiple L3 cache deferred errors after recent
+kernel rework of deferred error handling.¹ ⁴
+
+The errors are bogus due to inconsistent status values. Also, user verified
+that bogus MCA_DESTAT values are present on the system even with an older
+kernel.²
+
+The errors seem to be garbage values present in the MCA_DESTAT of some L3
+cache banks. These were implicitly ignored before the recent kernel rework
+because these do not generate a deferred error interrupt.
+
+A later revision of the rework patch was merged for v6.19. This naturally
+filtered out most of the bogus error logs. However, a few signatures still
+remain.³
+
+Minimize the scope of the filter to the reported CPU
+family/model/stepping and only for errors which don't have the Enabled
+bit in the MCi status MSR.
+
+¹ https://lore.kernel.org/20250915010010.3547-1-spasswolf@web.de
+² https://lore.kernel.org/6e1eda7dd55f6fa30405edf7b0f75695cf55b237.camel@web.de
+³ https://lore.kernel.org/21ba47fa8893b33b94370c2a42e5084cf0d2e975.camel@web.de
+⁴ https://lore.kernel.org/r/CAKFB093B2k3sKsGJ_QNX1jVQsaXVFyy=wNwpzCGLOXa_vSDwXw@mail.gmail.com
+
+ [ bp: Generalize the condition according to which errors are bogus. ]
+
+Fixes: 7cb735d7c0cb ("x86/mce: Unify AMD DFR handler with MCA Polling")
+Closes: https://lore.kernel.org/20250915010010.3547-1-spasswolf@web.de
+Reported-by: Bert Karwatzki <spasswolf@web.de>
+Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Tested-By: Bert Karwatzki <spasswolf@web.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/20250915010010.3547-1-spasswolf@web.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/amd.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
+index a030ee4cecc2..28deaba08833 100644
+--- a/arch/x86/kernel/cpu/mce/amd.c
++++ b/arch/x86/kernel/cpu/mce/amd.c
+@@ -604,6 +604,14 @@ bool amd_filter_mce(struct mce *m)
+ enum smca_bank_types bank_type = smca_get_bank_type(m->extcpu, m->bank);
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+
++ /* Bogus hw errors on Cezanne A0. */
++ if (c->x86 == 0x19 &&
++ c->x86_model == 0x50 &&
++ c->x86_stepping == 0x0) {
++ if (!(m->status & MCI_STATUS_EN))
++ return true;
++ }
++
+ /* See Family 17h Models 10h-2Fh Erratum #1114. */
+ if (c->x86 == 0x17 &&
+ c->x86_model >= 0x10 && c->x86_model <= 0x2F &&
+--
+2.53.0
+
--- /dev/null
+From 71a98248c63c535eaa4d4c22f099b68d902006d0 Mon Sep 17 00:00:00 2001
+From: Yasuaki Torimaru <yasuakitorimaru@gmail.com>
+Date: Thu, 26 Mar 2026 14:58:00 +0900
+Subject: xfrm: clear trailing padding in build_polexpire()
+
+From: Yasuaki Torimaru <yasuakitorimaru@gmail.com>
+
+commit 71a98248c63c535eaa4d4c22f099b68d902006d0 upstream.
+
+build_expire() clears the trailing padding bytes of struct
+xfrm_user_expire after setting the hard field via memset_after(),
+but the analogous function build_polexpire() does not do this for
+struct xfrm_user_polexpire.
+
+The padding bytes after the __u8 hard field are left
+uninitialized from the heap allocation, and are then sent to
+userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,
+leaking kernel heap memory contents.
+
+Add the missing memset_after() call, matching build_expire().
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yasuaki Torimaru <yasuakitorimaru@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Reviewed-by: Breno Leitao <leitao@debian.org>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/xfrm/xfrm_user.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -3951,6 +3951,8 @@ static int build_polexpire(struct sk_buf
+ return err;
+ }
+ upe->hard = !!hard;
++ /* clear the padding bytes */
++ memset_after(upe, 0, hard);
+
+ nlmsg_end(skb, nlh);
+ return 0;
--- /dev/null
+From 1c428b03840094410c5fb6a5db30640486bbbfcb Mon Sep 17 00:00:00 2001
+From: Qi Tang <tpluszz77@gmail.com>
+Date: Thu, 2 Apr 2026 19:44:01 +0800
+Subject: xfrm: hold dev ref until after transport_finish NF_HOOK
+
+From: Qi Tang <tpluszz77@gmail.com>
+
+commit 1c428b03840094410c5fb6a5db30640486bbbfcb upstream.
+
+After async crypto completes, xfrm_input_resume() calls dev_put()
+immediately on re-entry before the skb reaches transport_finish.
+The skb->dev pointer is then used inside NF_HOOK and its okfn,
+which can race with device teardown.
+
+Remove the dev_put from the async resumption entry and instead
+drop the reference after the NF_HOOK call in transport_finish,
+using a saved device pointer since NF_HOOK may consume the skb.
+This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip
+the okfn.
+
+For non-transport exits (decaps, gro, drop) and secondary
+async return points, release the reference inline when
+async is set.
+
+Suggested-by: Florian Westphal <fw@strlen.de>
+Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet")
+Cc: stable@vger.kernel.org
+Signed-off-by: Qi Tang <tpluszz77@gmail.com>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/xfrm4_input.c | 5 ++++-
+ net/ipv6/xfrm6_input.c | 5 ++++-
+ net/xfrm/xfrm_input.c | 18 ++++++++++++++----
+ 3 files changed, 22 insertions(+), 6 deletions(-)
+
+--- a/net/ipv4/xfrm4_input.c
++++ b/net/ipv4/xfrm4_input.c
+@@ -50,6 +50,7 @@ int xfrm4_transport_finish(struct sk_buf
+ {
+ struct xfrm_offload *xo = xfrm_offload(skb);
+ struct iphdr *iph = ip_hdr(skb);
++ struct net_device *dev = skb->dev;
+
+ iph->protocol = XFRM_MODE_SKB_CB(skb)->protocol;
+
+@@ -73,8 +74,10 @@ int xfrm4_transport_finish(struct sk_buf
+ }
+
+ NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
+- dev_net(skb->dev), NULL, skb, skb->dev, NULL,
++ dev_net(dev), NULL, skb, dev, NULL,
+ xfrm4_rcv_encap_finish);
++ if (async)
++ dev_put(dev);
+ return 0;
+ }
+
+--- a/net/ipv6/xfrm6_input.c
++++ b/net/ipv6/xfrm6_input.c
+@@ -43,6 +43,7 @@ static int xfrm6_transport_finish2(struc
+ int xfrm6_transport_finish(struct sk_buff *skb, int async)
+ {
+ struct xfrm_offload *xo = xfrm_offload(skb);
++ struct net_device *dev = skb->dev;
+ int nhlen = -skb_network_offset(skb);
+
+ skb_network_header(skb)[IP6CB(skb)->nhoff] =
+@@ -68,8 +69,10 @@ int xfrm6_transport_finish(struct sk_buf
+ }
+
+ NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
+- dev_net(skb->dev), NULL, skb, skb->dev, NULL,
++ dev_net(dev), NULL, skb, dev, NULL,
+ xfrm6_transport_finish2);
++ if (async)
++ dev_put(dev);
+ return 0;
+ }
+
+--- a/net/xfrm/xfrm_input.c
++++ b/net/xfrm/xfrm_input.c
+@@ -503,7 +503,6 @@ int xfrm_input(struct sk_buff *skb, int
+ /* An encap_type of -1 indicates async resumption. */
+ if (encap_type == -1) {
+ async = 1;
+- dev_put(skb->dev);
+ seq = XFRM_SKB_CB(skb)->seq.input.low;
+ spin_lock(&x->lock);
+ goto resume;
+@@ -656,8 +655,11 @@ process:
+ dev_hold(skb->dev);
+
+ nexthdr = x->type->input(x, skb);
+- if (nexthdr == -EINPROGRESS)
++ if (nexthdr == -EINPROGRESS) {
++ if (async)
++ dev_put(skb->dev);
+ return 0;
++ }
+
+ dev_put(skb->dev);
+ spin_lock(&x->lock);
+@@ -692,9 +694,11 @@ resume:
+ XFRM_MODE_SKB_CB(skb)->protocol = nexthdr;
+
+ err = xfrm_inner_mode_input(x, skb);
+- if (err == -EINPROGRESS)
++ if (err == -EINPROGRESS) {
++ if (async)
++ dev_put(skb->dev);
+ return 0;
+- else if (err) {
++ } else if (err) {
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEMODEERROR);
+ goto drop;
+ }
+@@ -731,6 +735,8 @@ resume_decapped:
+ sp->olen = 0;
+ if (skb_valid_dst(skb))
+ skb_dst_drop(skb);
++ if (async)
++ dev_put(skb->dev);
+ gro_cells_receive(&gro_cells, skb);
+ return 0;
+ } else {
+@@ -750,6 +756,8 @@ resume_decapped:
+ sp->olen = 0;
+ if (skb_valid_dst(skb))
+ skb_dst_drop(skb);
++ if (async)
++ dev_put(skb->dev);
+ gro_cells_receive(&gro_cells, skb);
+ return err;
+ }
+@@ -760,6 +768,8 @@ resume_decapped:
+ drop_unlock:
+ spin_unlock(&x->lock);
+ drop:
++ if (async)
++ dev_put(skb->dev);
+ xfrm_rcv_cb(skb, family, x && x->type ? x->type->proto : nexthdr, -1);
+ kfree_skb(skb);
+ return 0;
projects / thirdparty / kernel / stable-queue.git / commitdiff
