--- /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
+@@ -847,7 +847,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 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
+@@ -2132,6 +2132,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;
+@@ -2147,32 +2148,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;
+ }
+@@ -2468,6 +2472,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;
+@@ -2490,9 +2495,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
+@@ -844,8 +844,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;
+@@ -863,6 +863,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
+@@ -145,10 +145,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))
+@@ -229,8 +231,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);
+ }
+
+@@ -244,8 +249,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
+@@ -2375,9 +2375,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) {
+@@ -2429,6 +2429,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);
+@@ -2456,7 +2457,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;
+ }
+ }
+@@ -2504,6 +2505,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;
+
+@@ -2517,7 +2524,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;
+
+ /*
+@@ -2555,14 +2562,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) {
+@@ -2570,7 +2577,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;
+ }
+
+@@ -2586,7 +2593,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);
+ }
+
+ /*
+@@ -2626,7 +2633,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);
+
+@@ -2702,8 +2710,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 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
+@@ -431,7 +431,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
+@@ -641,6 +641,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 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
+@@ -3655,14 +3655,19 @@ vm_fault_t filemap_map_pages(struct vm_f
+ unsigned int nr_pages = 0, mmap_miss = 0, mmap_miss_saved, folio_type;
+ bool can_map_large;
+
++ /*
++ * 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 PTEs beyond i_size and with PMD
+ * across i_size to preserve SIGBUS semantics.
--- /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
+@@ -2369,8 +2369,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 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
+@@ -2246,6 +2246,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
+@@ -1002,7 +1002,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
+
+ del_timer(&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
+@@ -421,6 +421,7 @@ static void remove_cluster_entries(struc
+ #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)
+@@ -482,6 +483,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;
+@@ -531,6 +533,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);
+
+@@ -568,7 +572,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 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
+@@ -845,8 +845,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;
+ };
+@@ -857,8 +857,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;
+ };
+
+@@ -867,14 +867,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 {
+@@ -1405,13 +1405,3 @@
+ fsl,ext-reset-output;
+ status = "okay";
+ };
+-
+-&a53_opp_table {
+- opp-1000000000 {
+- opp-microvolt = <850000>;
+- };
+-
+- opp-1500000000 {
+- opp-microvolt = <950000>;
+- };
+-};
mptcp-fix-soft-lockup-in-mptcp_recvmsg.patch
loongarch-remove-unnecessary-checks-for-orc-unwinder.patch
loongarch-handle-percpu-handler-address-for-orc-unwinder.patch
+netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.patch
+workqueue-add-pool_workqueue-to-pending_pwqs-list-when-unplugging-multiple-inactive-works.patch
+xfrm-clear-trailing-padding-in-build_polexpire.patch
+tipc-fix-bc_ackers-underflow-on-duplicate-grp_ack_msg.patch
+wifi-brcmsmac-fix-dma_free_coherent-size.patch
+platform-x86-intel-uncore-freq-handle-autonomous-ufs-status-bit.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-hisilicon-poplar-correct-pcie-reset-gpio-polarity.patch
+arm64-dts-hisilicon-hi3798cv200-add-missing-dma-ranges.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
+mmc-vub300-fix-null-deref-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-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
+@@ -1856,8 +1856,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
+@@ -585,10 +585,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)
+@@ -621,10 +621,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 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
+@@ -3849,6 +3849,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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
