From: Greg Kroah-Hartman Date: Mon, 13 Apr 2026 12:26:21 +0000 (+0200) Subject: 6.6-stable patches X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=808fd7bfc8f03e0afe2db68531838c59bfecf3c6;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: arm64-dts-hisilicon-hi3798cv200-add-missing-dma-ranges.patch arm64-dts-hisilicon-poplar-correct-pcie-reset-gpio-polarity.patch arm64-dts-imx8mq-librem5-bump-buck1-suspend-voltage-up-to-0.85v.patch batman-adv-hold-claim-backbone-gateways-by-reference.patch batman-adv-reject-oversized-global-tt-response-buffers.patch drm-i915-gt-fix-refcount-underflow-in-intel_engine_park_heartbeat.patch edac-mc-fix-error-path-ordering-in-edac_mc_alloc.patch mm-filemap-fix-nr_pages-calculation-overflow-in-filemap_map_pages.patch mmc-vub300-fix-null-deref-on-disconnect.patch net-altera-tse-fix-skb-leak-on-dma-mapping-error-in-tse_start_xmit.patch net-lan966x-fix-page_pool-error-handling-in-lan966x_fdma_rx_alloc_page_pool.patch net-mlx5-update-the-list-of-the-pci-supported-devices.patch net-qualcomm-qca_uart-report-the-consumed-byte-on-rx-skb-allocation-failure.patch net-stmmac-fix-integer-underflow-in-chain-mode.patch net-tls-fix-use-after-free-in-ebusy-error-path-of-tls_do_encryption.patch netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.patch nfc-pn533-allocate-rx-skb-before-consuming-bytes.patch pmdomain-imx8mp-blk-ctrl-keep-the-noc_hdcp-clock-enabled.patch revert-arm64-dts-imx8mq-librem5-set-the-dvs-voltages-lower.patch tipc-fix-bc_ackers-underflow-on-duplicate-grp_ack_msg.patch wifi-brcmsmac-fix-dma_free_coherent-size.patch x.509-fix-out-of-bounds-access-when-parsing-extensions.patch xfrm-clear-trailing-padding-in-build_polexpire.patch --- diff --git a/queue-6.6/arm64-dts-hisilicon-hi3798cv200-add-missing-dma-ranges.patch b/queue-6.6/arm64-dts-hisilicon-hi3798cv200-add-missing-dma-ranges.patch new file mode 100644 index 0000000000..0f778922cb --- /dev/null +++ b/queue-6.6/arm64-dts-hisilicon-hi3798cv200-add-missing-dma-ranges.patch @@ -0,0 +1,35 @@ +From 1af997cad473d505248df6d9577183bb91f69670 Mon Sep 17 00:00:00 2001 +From: Shawn Guo +Date: Fri, 27 Feb 2026 15:22:10 +0800 +Subject: arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges + +From: Shawn Guo + +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 +Signed-off-by: Wei Xu +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -81,6 +81,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"; diff --git a/queue-6.6/arm64-dts-hisilicon-poplar-correct-pcie-reset-gpio-polarity.patch b/queue-6.6/arm64-dts-hisilicon-poplar-correct-pcie-reset-gpio-polarity.patch new file mode 100644 index 0000000000..f3653d71a3 --- /dev/null +++ b/queue-6.6/arm64-dts-hisilicon-poplar-correct-pcie-reset-gpio-polarity.patch @@ -0,0 +1,36 @@ +From c1f2b0f2b5e37b2c27540a175aea2755a3799433 Mon Sep 17 00:00:00 2001 +From: Shawn Guo +Date: Fri, 27 Feb 2026 15:19:58 +0800 +Subject: arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity + +From: Shawn Guo + +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 +Signed-off-by: Wei Xu +Signed-off-by: Greg Kroah-Hartman +--- + 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"; + }; diff --git a/queue-6.6/arm64-dts-imx8mq-librem5-bump-buck1-suspend-voltage-up-to-0.85v.patch b/queue-6.6/arm64-dts-imx8mq-librem5-bump-buck1-suspend-voltage-up-to-0.85v.patch new file mode 100644 index 0000000000..0945f8b0dc --- /dev/null +++ b/queue-6.6/arm64-dts-imx8mq-librem5-bump-buck1-suspend-voltage-up-to-0.85v.patch @@ -0,0 +1,40 @@ +From 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637 Mon Sep 17 00:00:00 2001 +From: Sebastian Krzyszkowiak +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 + +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 +Signed-off-by: Frank Li +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -849,7 +849,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; + }; + diff --git a/queue-6.6/batman-adv-hold-claim-backbone-gateways-by-reference.patch b/queue-6.6/batman-adv-hold-claim-backbone-gateways-by-reference.patch new file mode 100644 index 0000000000..3860eaa955 --- /dev/null +++ b/queue-6.6/batman-adv-hold-claim-backbone-gateways-by-reference.patch @@ -0,0 +1,116 @@ +From 82d8701b2c930d0e96b0dbc9115a218d791cb0d2 Mon Sep 17 00:00:00 2001 +From: Haoze Xie +Date: Mon, 6 Apr 2026 21:17:28 +0800 +Subject: batman-adv: hold claim backbone gateways by reference + +From: Haoze Xie + +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 +Reported-by: Juefei Pu +Co-developed-by: Yuan Tan +Signed-off-by: Yuan Tan +Suggested-by: Xin Liu +Signed-off-by: Haoze Xie +Signed-off-by: Ao Zhou +Signed-off-by: Sven Eckelmann +Signed-off-by: Simon Wunderlich +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-6.6/batman-adv-reject-oversized-global-tt-response-buffers.patch b/queue-6.6/batman-adv-reject-oversized-global-tt-response-buffers.patch new file mode 100644 index 0000000000..5054b5251d --- /dev/null +++ b/queue-6.6/batman-adv-reject-oversized-global-tt-response-buffers.patch @@ -0,0 +1,64 @@ +From 3a359bf5c61d52e7f09754108309d637532164a6 Mon Sep 17 00:00:00 2001 +From: Ruide Cao +Date: Thu, 2 Apr 2026 23:12:31 +0800 +Subject: batman-adv: reject oversized global TT response buffers + +From: Ruide Cao + +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 +Reported-by: Juefei Pu +Co-developed-by: Yuan Tan +Signed-off-by: Yuan Tan +Suggested-by: Xin Liu +Tested-by: Ren Wei +Signed-off-by: Ruide Cao +Signed-off-by: Ren Wei +Signed-off-by: Sven Eckelmann +Signed-off-by: Simon Wunderlich +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.6/drm-i915-gt-fix-refcount-underflow-in-intel_engine_park_heartbeat.patch b/queue-6.6/drm-i915-gt-fix-refcount-underflow-in-intel_engine_park_heartbeat.patch new file mode 100644 index 0000000000..66541059a9 --- /dev/null +++ b/queue-6.6/drm-i915-gt-fix-refcount-underflow-in-intel_engine_park_heartbeat.patch @@ -0,0 +1,119 @@ +From 4c71fd099513bfa8acab529b626e1f0097b76061 Mon Sep 17 00:00:00 2001 +From: Sebastian Brzezinka +Date: Wed, 1 Apr 2026 12:10:07 +0200 +Subject: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat + +From: Sebastian Brzezinka + +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] +<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] +``` + +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: # v5.5+ +Signed-off-by: Sebastian Brzezinka +Reviewed-by: Krzysztof Karas +Reviewed-by: Andi Shyti +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com +(cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) +Signed-off-by: Joonas Lahtinen +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -144,10 +144,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)) +@@ -228,8 +230,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); + } + +@@ -243,8 +248,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) diff --git a/queue-6.6/edac-mc-fix-error-path-ordering-in-edac_mc_alloc.patch b/queue-6.6/edac-mc-fix-error-path-ordering-in-edac_mc_alloc.patch new file mode 100644 index 0000000000..b3811eb238 --- /dev/null +++ b/queue-6.6/edac-mc-fix-error-path-ordering-in-edac_mc_alloc.patch @@ -0,0 +1,66 @@ +From 51520e03e70d6c73e33ee7cbe0319767d05764fe Mon Sep 17 00:00:00 2001 +From: "Borislav Petkov (AMD)" +Date: Tue, 31 Mar 2026 14:16:23 +0200 +Subject: EDAC/mc: Fix error path ordering in edac_mc_alloc() + +From: Borislav Petkov (AMD) + +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: + + 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) +Reviewed-by: Qiuxu Zhuo +Cc: stable@kernel.org +Link: https://patch.msgid.link/20260331121623.4871-1-bp@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -369,13 +369,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; diff --git a/queue-6.6/mm-filemap-fix-nr_pages-calculation-overflow-in-filemap_map_pages.patch b/queue-6.6/mm-filemap-fix-nr_pages-calculation-overflow-in-filemap_map_pages.patch new file mode 100644 index 0000000000..088d27d6d0 --- /dev/null +++ b/queue-6.6/mm-filemap-fix-nr_pages-calculation-overflow-in-filemap_map_pages.patch @@ -0,0 +1,142 @@ +From f58df566524ebcdfa394329c64f47e3c9257516e Mon Sep 17 00:00:00 2001 +From: Baolin Wang +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 + +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 +Reported-by: Yuanhe Shu +Tested-by: Yuanhe Shu +Acked-by: Kiryl Shutsemau (Meta) +Acked-by: David Hildenbrand (Arm) +Cc: Christian Brauner +Cc: Daniel Gomez +Cc: "Darrick J. Wong" +Cc: Dave Chinner +Cc: David Howells +Cc: Hannes Reinecke +Cc: Lorenzo Stoakes (Oracle) +Cc: Luis Chamberalin +Cc: Matthew Wilcox (Oracle) +Cc: Pankaj Raghav +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/filemap.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/mm/filemap.c ++++ b/mm/filemap.c +@@ -3616,14 +3616,19 @@ vm_fault_t filemap_map_pages(struct vm_f + unsigned int nr_pages = 0, mmap_miss = 0, mmap_miss_saved; + 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. diff --git a/queue-6.6/mmc-vub300-fix-null-deref-on-disconnect.patch b/queue-6.6/mmc-vub300-fix-null-deref-on-disconnect.patch new file mode 100644 index 0000000000..de07f03a66 --- /dev/null +++ b/queue-6.6/mmc-vub300-fix-null-deref-on-disconnect.patch @@ -0,0 +1,34 @@ +From dff34ef879c5e73298443956a8b391311ba78d57 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 27 Mar 2026 11:52:05 +0100 +Subject: mmc: vub300: fix NULL-deref on disconnect + +From: Johan Hovold + +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 +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.6/net-altera-tse-fix-skb-leak-on-dma-mapping-error-in-tse_start_xmit.patch b/queue-6.6/net-altera-tse-fix-skb-leak-on-dma-mapping-error-in-tse_start_xmit.patch new file mode 100644 index 0000000000..5abc14bd91 --- /dev/null +++ b/queue-6.6/net-altera-tse-fix-skb-leak-on-dma-mapping-error-in-tse_start_xmit.patch @@ -0,0 +1,36 @@ +From 6dede3967619b5944003227a5d09fdc21ed57d10 Mon Sep 17 00:00:00 2001 +From: David Carlier +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 + +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 +Link: https://patch.msgid.link/20260401211218.279185-1-devnexen@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -574,6 +574,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; + } diff --git a/queue-6.6/net-lan966x-fix-page_pool-error-handling-in-lan966x_fdma_rx_alloc_page_pool.patch b/queue-6.6/net-lan966x-fix-page_pool-error-handling-in-lan966x_fdma_rx_alloc_page_pool.patch new file mode 100644 index 0000000000..6df0e5acf4 --- /dev/null +++ b/queue-6.6/net-lan966x-fix-page_pool-error-handling-in-lan966x_fdma_rx_alloc_page_pool.patch @@ -0,0 +1,37 @@ +From 3fd0da4fd8851a7e62d009b7db6c4a05b092bc19 Mon Sep 17 00:00:00 2001 +From: David Carlier +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 + +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 +Link: https://patch.msgid.link/20260405055241.35767-2-devnexen@gmail.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -85,6 +85,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; diff --git a/queue-6.6/net-mlx5-update-the-list-of-the-pci-supported-devices.patch b/queue-6.6/net-mlx5-update-the-list-of-the-pci-supported-devices.patch new file mode 100644 index 0000000000..50ef61b99c --- /dev/null +++ b/queue-6.6/net-mlx5-update-the-list-of-the-pci-supported-devices.patch @@ -0,0 +1,34 @@ +From a9d4f4f6e65e0bf9bbddedecc84d67249991979c Mon Sep 17 00:00:00 2001 +From: Michael Guralnik +Date: Fri, 3 Apr 2026 12:17:56 +0300 +Subject: net/mlx5: Update the list of the PCI supported devices + +From: Michael Guralnik + +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 +Reviewed-by: Patrisious Haddad +Signed-off-by: Tariq Toukan +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20260403091756.139583-1-tariqt@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -2208,6 +2208,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 */ diff --git a/queue-6.6/net-qualcomm-qca_uart-report-the-consumed-byte-on-rx-skb-allocation-failure.patch b/queue-6.6/net-qualcomm-qca_uart-report-the-consumed-byte-on-rx-skb-allocation-failure.patch new file mode 100644 index 0000000000..83b077e239 --- /dev/null +++ b/queue-6.6/net-qualcomm-qca_uart-report-the-consumed-byte-on-rx-skb-allocation-failure.patch @@ -0,0 +1,46 @@ +From b76254c55dc8f23edc089027dd3f8792554c69fb Mon Sep 17 00:00:00 2001 +From: Pengpeng Hou +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 + +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 +Reviewed-by: Stefan Wahren +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20260402071207.4036-1-pengpeng@iscas.ac.cn +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -114,7 +114,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; + } + } + } diff --git a/queue-6.6/net-stmmac-fix-integer-underflow-in-chain-mode.patch b/queue-6.6/net-stmmac-fix-integer-underflow-in-chain-mode.patch new file mode 100644 index 0000000000..70e445d8b4 --- /dev/null +++ b/queue-6.6/net-stmmac-fix-integer-underflow-in-chain-mode.patch @@ -0,0 +1,80 @@ +From 51f4e090b9f87b40c21b6daadb5c06e6c0a07b67 Mon Sep 17 00:00:00 2001 +From: Tyllis Xu +Date: Tue, 31 Mar 2026 23:47:07 -0500 +Subject: net: stmmac: fix integer underflow in chain mode + +From: Tyllis Xu + +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 +Link: https://patch.msgid.link/20260401044708.1386919-1-LivelyCarpet87@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-6.6/net-tls-fix-use-after-free-in-ebusy-error-path-of-tls_do_encryption.patch b/queue-6.6/net-tls-fix-use-after-free-in-ebusy-error-path-of-tls_do_encryption.patch new file mode 100644 index 0000000000..67a2568339 --- /dev/null +++ b/queue-6.6/net-tls-fix-use-after-free-in-ebusy-error-path-of-tls_do_encryption.patch @@ -0,0 +1,64 @@ +From a9b8b18364fffce4c451e6f6fd218fa4ab646705 Mon Sep 17 00:00:00 2001 +From: Muhammad Alifa Ramdhan +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 + +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 +Reviewed-by: Sabrina Dubroca +Link: https://patch.msgid.link/20260403013617.2838875-1-ramdhan@starlabs.sg +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.6/netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.patch b/queue-6.6/netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.patch new file mode 100644 index 0000000000..a6bcc449da --- /dev/null +++ b/queue-6.6/netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.patch @@ -0,0 +1,73 @@ +From f8dca15a1b190787bbd03285304b569631160eda Mon Sep 17 00:00:00 2001 +From: Tuan Do +Date: Fri, 3 Apr 2026 00:33:17 -0700 +Subject: netfilter: nft_ct: fix use-after-free in timeout object destroy + +From: Tuan Do + +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 +Signed-off-by: Florian Westphal +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.6/nfc-pn533-allocate-rx-skb-before-consuming-bytes.patch b/queue-6.6/nfc-pn533-allocate-rx-skb-before-consuming-bytes.patch new file mode 100644 index 0000000000..2a27e08bc6 --- /dev/null +++ b/queue-6.6/nfc-pn533-allocate-rx-skb-before-consuming-bytes.patch @@ -0,0 +1,59 @@ +From c71ba669b570c7b3f86ec875be222ea11dacb352 Mon Sep 17 00:00:00 2001 +From: Pengpeng Hou +Date: Sun, 5 Apr 2026 08:40:00 +0800 +Subject: nfc: pn533: allocate rx skb before consuming bytes + +From: Pengpeng Hou + +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 +Link: https://patch.msgid.link/20260405094003.3-pn533-v2-pengpeng@iscas.ac.cn +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 int pn532_receive_buf(struct serd + + 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 int pn532_receive_buf(struct serd + 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; diff --git a/queue-6.6/pmdomain-imx8mp-blk-ctrl-keep-the-noc_hdcp-clock-enabled.patch b/queue-6.6/pmdomain-imx8mp-blk-ctrl-keep-the-noc_hdcp-clock-enabled.patch new file mode 100644 index 0000000000..5ac481fea5 --- /dev/null +++ b/queue-6.6/pmdomain-imx8mp-blk-ctrl-keep-the-noc_hdcp-clock-enabled.patch @@ -0,0 +1,52 @@ +From e91d5f94acf68618ea3ad9c92ac28614e791ae7d Mon Sep 17 00:00:00 2001 +From: Jacky Bai +Date: Fri, 20 Mar 2026 16:43:46 +0800 +Subject: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled + +From: Jacky Bai + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + 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)); + + /* diff --git a/queue-6.6/revert-arm64-dts-imx8mq-librem5-set-the-dvs-voltages-lower.patch b/queue-6.6/revert-arm64-dts-imx8mq-librem5-set-the-dvs-voltages-lower.patch new file mode 100644 index 0000000000..a5a602b237 --- /dev/null +++ b/queue-6.6/revert-arm64-dts-imx8mq-librem5-set-the-dvs-voltages-lower.patch @@ -0,0 +1,92 @@ +From 4cd46ea0eb4504f7f4fea92cb4601c5c9a3e545e Mon Sep 17 00:00:00 2001 +From: Sebastian Krzyszkowiak +Date: Sat, 21 Feb 2026 19:15:18 +0100 +Subject: Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower" + +From: Sebastian Krzyszkowiak + +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 +Signed-off-by: Frank Li +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -847,8 +847,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; + }; +@@ -859,8 +859,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; + }; + +@@ -869,14 +869,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 { +@@ -1410,13 +1410,3 @@ + fsl,ext-reset-output; + status = "okay"; + }; +- +-&a53_opp_table { +- opp-1000000000 { +- opp-microvolt = <850000>; +- }; +- +- opp-1500000000 { +- opp-microvolt = <950000>; +- }; +-}; diff --git a/queue-6.6/series b/queue-6.6/series index 5ddab8b86f..e32e8dd766 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -17,3 +17,26 @@ revert-mptcp-add-needs_id-for-netlink-appending-addr.patch seg6-separate-dst_cache-for-input-and-output-paths-in-seg6-lwtunnel.patch netfilter-nft_set_pipapo-do-not-rely-on-zero_size_ptr.patch revert-drm-fix-use-after-free-on-framebuffers-and-property-blobs-when-calling-drm_dev_unplug.patch +netfilter-nft_ct-fix-use-after-free-in-timeout-object-destroy.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 +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 +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 +net-lan966x-fix-page_pool-error-handling-in-lan966x_fdma_rx_alloc_page_pool.patch diff --git a/queue-6.6/tipc-fix-bc_ackers-underflow-on-duplicate-grp_ack_msg.patch b/queue-6.6/tipc-fix-bc_ackers-underflow-on-duplicate-grp_ack_msg.patch new file mode 100644 index 0000000000..9f3b2f93f1 --- /dev/null +++ b/queue-6.6/tipc-fix-bc_ackers-underflow-on-duplicate-grp_ack_msg.patch @@ -0,0 +1,57 @@ +From 48a5fe38772b6f039522469ee6131a67838221a8 Mon Sep 17 00:00:00 2001 +From: Oleh Konko +Date: Thu, 2 Apr 2026 09:48:57 +0000 +Subject: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG + +From: Oleh Konko + +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 +Reviewed-by: Tung Nguyen +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/41a4833f368641218e444fdcff822039.security@1seal.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.6/wifi-brcmsmac-fix-dma_free_coherent-size.patch b/queue-6.6/wifi-brcmsmac-fix-dma_free_coherent-size.patch new file mode 100644 index 0000000000..81c40d2e03 --- /dev/null +++ b/queue-6.6/wifi-brcmsmac-fix-dma_free_coherent-size.patch @@ -0,0 +1,36 @@ +From 12cd7632757a54ce586e36040210b1a738a0fc53 Mon Sep 17 00:00:00 2001 +From: Thomas Fourier +Date: Wed, 18 Feb 2026 14:07:37 +0100 +Subject: wifi: brcmsmac: Fix dma_free_coherent() size + +From: Thomas Fourier + +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: +Signed-off-by: Thomas Fourier +Acked-by: Arend van Spriel +Link: https://patch.msgid.link/20260218130741.46566-3-fourier.thomas@gmail.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-6.6/x.509-fix-out-of-bounds-access-when-parsing-extensions.patch b/queue-6.6/x.509-fix-out-of-bounds-access-when-parsing-extensions.patch new file mode 100644 index 0000000000..f595673404 --- /dev/null +++ b/queue-6.6/x.509-fix-out-of-bounds-access-when-parsing-extensions.patch @@ -0,0 +1,58 @@ +From d702c3408213bb12bd570bb97204d8340d141c51 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Tue, 7 Apr 2026 12:58:18 +0200 +Subject: X.509: Fix out-of-bounds access when parsing extensions + +From: Lukas Wunner + +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 # off-list +Signed-off-by: Lukas Wunner +Reviewed-by: Ignat Korchagin +Cc: stable@vger.kernel.org # v6.4+ +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -592,10 +592,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) +@@ -628,10 +628,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) */ diff --git a/queue-6.6/xfrm-clear-trailing-padding-in-build_polexpire.patch b/queue-6.6/xfrm-clear-trailing-padding-in-build_polexpire.patch new file mode 100644 index 0000000000..62dd9dec22 --- /dev/null +++ b/queue-6.6/xfrm-clear-trailing-padding-in-build_polexpire.patch @@ -0,0 +1,43 @@ +From 71a98248c63c535eaa4d4c22f099b68d902006d0 Mon Sep 17 00:00:00 2001 +From: Yasuaki Torimaru +Date: Thu, 26 Mar 2026 14:58:00 +0900 +Subject: xfrm: clear trailing padding in build_polexpire() + +From: Yasuaki Torimaru + +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 +Reviewed-by: Simon Horman +Reviewed-by: Breno Leitao +Signed-off-by: Steffen Klassert +Signed-off-by: Greg Kroah-Hartman +--- + net/xfrm/xfrm_user.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/xfrm/xfrm_user.c ++++ b/net/xfrm/xfrm_user.c +@@ -3583,6 +3583,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;