October 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] x86/resctrl: Fix miscount of bandwidth event when" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102054-slacks-ambush-f774@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 Mon Sep 17 00:00:00 2001 From: Babu Moger <babu.moger(a)amd.com> Date: Fri, 10 Oct 2025 12:08:35 -0500 Subject: [PATCH] x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state. When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked. resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked. This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter). Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again. Example scenario that results in mistaken overflow ================================================== 1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group. $mount -t resctrl resctrl /sys/fs/resctrl $mkdir /sys/fs/resctrl/mon_groups/test1/ $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 21323 <- Total bytes on domain 0 "Unavailable" <- Total bytes on domain 1 Task is running on domain 0. Counter on domain 1 is "Unavailable". 2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 7345357 <- Total bytes on domain 0 4545 <- Total bytes on domain 1 3. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes "Unavailable" <- Total bytes on domain 0 434341 <- Total bytes on domain 1 4. Since the task continues to migrate between domains, it may eventually return to domain 0. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 17592178699059 <- Overflow on domain 0 3232332 <- Total bytes on domain 1 In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0. Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta. In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state. Here is the text from APM [1] available from [2]. "In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first QM_CTR read when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, a QM_CTR read with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read." [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM). [ bp: Split commit message into smaller paragraph chunks for better consumption. ] Fixes: 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger <babu.moger(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre(a)intel.com> Tested-by: Reinette Chatre <reinette.chatre(a)intel.com> Cc: stable(a)vger.kernel.org # needs adjustments for <= v6.17 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2] diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index c8945610d455..2cd25a0d4637 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -242,7 +242,9 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d, u32 unused, u32 rmid, enum resctrl_event_id eventid, u64 *val, void *ignored) { + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); int cpu = cpumask_any(&d->hdr.cpu_mask); + struct arch_mbm_state *am; u64 msr_val; u32 prmid; int ret; @@ -251,12 +253,16 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d, prmid = logical_rmid_to_physical_rmid(cpu, rmid); ret = __rmid_read_phys(prmid, eventid, &msr_val); - if (ret) - return ret; - *val = get_corrected_val(r, d, rmid, eventid, msr_val); + if (!ret) { + *val = get_corrected_val(r, d, rmid, eventid, msr_val); + } else if (ret == -EINVAL) { + am = get_arch_mbm_state(hw_dom, rmid, eventid); + if (am) + am->prev_msr = 0; + } - return 0; + return ret; } static int __cntr_id_read(u32 cntr_id, u64 *val)

1 week, 5 days

2
1
0 0

[PATCH v2] leds: leds-lp50xx: enable chip before any communication

by Christian Hitz

From: Christian Hitz <christian.hitz(a)bbv.ch> If a GPIO is used to control the chip's enable pin, it needs to be pulled high before any i2c communication is attempted. Currently, the enable GPIO handling is not correct. Assume the enable GPIO is low when the probe function is entered. In this case the device is in SHUTDOWN mode and does not react to i2c commands. During probe the following sequence happens: 1. The call to lp50xx_reset() on line 548 has no effect as i2c is not possible yet. 2. Then - on line 552 - lp50xx_enable_disable() is called. As "priv->enable_gpio“ has not yet been initialized, setting the GPIO has no effect. Also the i2c enable command is not executed as the device is still in SHUTDOWN. 3. On line 556 the call to lp50xx_probe_dt() finally parses the rest of the DT and the configured priv->enable_gpio is set up. As a result the device is still in SHUTDOWN mode and not ready for operation. Split lp50xx_enable_disable() into distinct enable and disable functions to enforce correct ordering between enable_gpio manipulations and i2c commands. Read enable_gpio configuration from DT before attempting to manipulate enable_gpio. Add delays to observe correct wait timing after manipulating enable_gpio and before any i2c communication. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Hitz <christian.hitz(a)bbv.ch> --- Changes in v2: - Unconditionally reset in lp50xx_enable - Define magic numbers - Improve log message --- drivers/leds/leds-lp50xx.c | 55 +++++++++++++++++++++++++++----------- 1 file changed, 40 insertions(+), 15 deletions(-) diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c index 94f8ef6b482c..d3485d814cf4 100644 --- a/drivers/leds/leds-lp50xx.c +++ b/drivers/leds/leds-lp50xx.c @@ -50,6 +50,12 @@ #define LP50XX_SW_RESET 0xff #define LP50XX_CHIP_EN BIT(6) +#define LP50XX_CHIP_DISABLE 0x00 +#define LP50XX_START_TIME_US 500 +#define LP50XX_RESET_TIME_US 3 + +#define LP50XX_EN_GPIO_LOW 0 +#define LP50XX_EN_GPIO_HIGH 1 /* There are 3 LED outputs per bank */ #define LP50XX_LEDS_PER_MODULE 3 @@ -371,19 +377,42 @@ static int lp50xx_reset(struct lp50xx *priv) return regmap_write(priv->regmap, priv->chip_info->reset_reg, LP50XX_SW_RESET); } -static int lp50xx_enable_disable(struct lp50xx *priv, int enable_disable) +static int lp50xx_enable(struct lp50xx *priv) { int ret; - ret = gpiod_direction_output(priv->enable_gpio, enable_disable); + if (priv->enable_gpio) { + ret = gpiod_direction_output(priv->enable_gpio, LP50XX_EN_GPIO_HIGH); + if (ret) + return ret; + + udelay(LP50XX_START_TIME_US); + } + + ret = lp50xx_reset(priv); if (ret) return ret; - if (enable_disable) - return regmap_write(priv->regmap, LP50XX_DEV_CFG0, LP50XX_CHIP_EN); - else - return regmap_write(priv->regmap, LP50XX_DEV_CFG0, 0); + return regmap_write(priv->regmap, LP50XX_DEV_CFG0, LP50XX_CHIP_EN); +} +static int lp50xx_disable(struct lp50xx *priv) +{ + int ret; + + ret = regmap_write(priv->regmap, LP50XX_DEV_CFG0, LP50XX_CHIP_DISABLE); + if (ret) + return ret; + + if (priv->enable_gpio) { + ret = gpiod_direction_output(priv->enable_gpio, LP50XX_EN_GPIO_LOW); + if (ret) + return ret; + + udelay(LP50XX_RESET_TIME_US); + } + + return 0; } static int lp50xx_probe_leds(struct fwnode_handle *child, struct lp50xx *priv, @@ -447,6 +476,10 @@ static int lp50xx_probe_dt(struct lp50xx *priv) return dev_err_probe(priv->dev, PTR_ERR(priv->enable_gpio), "Failed to get enable GPIO\n"); + ret = lp50xx_enable(priv); + if (ret) + return ret; + priv->regulator = devm_regulator_get(priv->dev, "vled"); if (IS_ERR(priv->regulator)) priv->regulator = NULL; @@ -547,14 +580,6 @@ static int lp50xx_probe(struct i2c_client *client) return ret; } - ret = lp50xx_reset(led); - if (ret) - return ret; - - ret = lp50xx_enable_disable(led, 1); - if (ret) - return ret; - return lp50xx_probe_dt(led); } @@ -563,7 +588,7 @@ static void lp50xx_remove(struct i2c_client *client) struct lp50xx *led = i2c_get_clientdata(client); int ret; - ret = lp50xx_enable_disable(led, 0); + ret = lp50xx_disable(led); if (ret) dev_err(led->dev, "Failed to disable chip\n"); -- 2.51.1

1 week, 5 days

1
0
0 0

[PATCH] iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source

by Miaoqian Lin

When simple_write_to_buffer() succeeds, it returns the number of bytes actually copied to the buffer, which may be less than the requested 'count' if the buffer size is insufficient. However, the current code incorrectly uses 'count' as the index for null termination instead of the actual bytes copied, leading to out-of-bound write. Add a check for the count and use the return value as the index. Found via static analysis. This is similar to the commit da9374819eb3 ("iio: backend: fix out-of-bound write") Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/iio/dac/ad3552r-hs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/iio/dac/ad3552r-hs.c b/drivers/iio/dac/ad3552r-hs.c index 41b96b48ba98..a9578afa7015 100644 --- a/drivers/iio/dac/ad3552r-hs.c +++ b/drivers/iio/dac/ad3552r-hs.c @@ -549,12 +549,15 @@ static ssize_t ad3552r_hs_write_data_source(struct file *f, guard(mutex)(&st->lock); + if (count >= sizeof(buf)) + return -ENOSPC; + ret = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, userbuf, count); if (ret < 0) return ret; - buf[count] = '\0'; + buf[ret] = '\0'; ret = match_string(dbgfs_attr_source, ARRAY_SIZE(dbgfs_attr_source), buf); -- 2.39.5 (Apple Git-154)

1 week, 5 days

5
12
0 0

[PATCH] drm/mediatek: fix device use-after-free on unbind

by Johan Hovold

A recent change fixed device reference leaks when looking up drm platform device driver data during bind() but failed to remove a partial fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix kobject put for component sub-drivers"). This results in a reference imbalance on component bind() failures and on unbind() which could lead to a user-after-free. Make sure to only drop the references after retrieving the driver data by effectively reverting the previous partial fix. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: 1f403699c40f ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv") Reported-by: Sjoerd Simons <sjoerd(a)collabora.com> Link: https://lore.kernel.org/r/20251003-mtk-drm-refcount-v1-1-3b3f2813b0db@colla… Cc: stable(a)vger.kernel.org Cc: Ma Ke <make24(a)iscas.ac.cn> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 384b0510272c..a94c51a83261 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -686,10 +686,6 @@ static int mtk_drm_bind(struct device *dev) for (i = 0; i < private->data->mmsys_dev_num; i++) private->all_drm_private[i]->drm = NULL; err_put_dev: - for (i = 0; i < private->data->mmsys_dev_num; i++) { - /* For device_find_child in mtk_drm_get_all_priv() */ - put_device(private->all_drm_private[i]->dev); - } put_device(private->mutex_dev); return ret; } @@ -697,18 +693,12 @@ static int mtk_drm_bind(struct device *dev) static void mtk_drm_unbind(struct device *dev) { struct mtk_drm_private *private = dev_get_drvdata(dev); - int i; /* for multi mmsys dev, unregister drm dev in mmsys master */ if (private->drm_master) { drm_dev_unregister(private->drm); mtk_drm_kms_deinit(private->drm); drm_dev_put(private->drm); - - for (i = 0; i < private->data->mmsys_dev_num; i++) { - /* For device_find_child in mtk_drm_get_all_priv() */ - put_device(private->all_drm_private[i]->dev); - } put_device(private->mutex_dev); } private->mtk_drm_bound = false; -- 2.49.1

1 week, 5 days

6
6
0 0

[PATCH] drm/of: Fix device node reference leak in drm_of_panel_bridge_remove

by Miaoqian Lin

of_graph_get_remote_node() returns a device node with its reference count incremented. The caller is responsible for releasing this reference when the node is no longer needed. Add of_node_put(remote) to fix the reference leak. Found via static analysis. Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- include/drm/drm_of.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h index 7f0256dae3f1..5940b1cd542b 100644 --- a/include/drm/drm_of.h +++ b/include/drm/drm_of.h @@ -171,6 +171,7 @@ static inline int drm_of_panel_bridge_remove(const struct device_node *np, return -ENODEV; bridge = of_drm_find_bridge(remote); + of_node_put(remote); drm_panel_bridge_remove(bridge); return 0; -- 2.39.5 (Apple Git-154)

1 week, 5 days

2
3
0 0

[PATCH] iio: accel: bmc150: Fix irq assumption regression

by Linus Walleij

The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read CPU: 0 UID: 0 PID: 393 Comm: iio-sensor-prox Not tainted 6.18.0-rc1-postmarketos-stericsson-00001-g6b43386e3737 #73 PREEMPT Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 kernfs_fop_write_iter from do_iter_readv_writev+0x178/0x1e4 do_iter_readv_writev from vfs_writev+0x158/0x3f4 vfs_writev from do_writev+0x74/0xe4 do_writev from __sys_trace_return+0x0/0x10 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Cc: stable(a)vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/iio/accel/bmc150-accel-core.c | 5 +++++ drivers/iio/accel/bmc150-accel.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c index 3c5d1560b163..f4421a3b0ef2 100644 --- a/drivers/iio/accel/bmc150-accel-core.c +++ b/drivers/iio/accel/bmc150-accel-core.c @@ -523,6 +523,10 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i, const struct bmc150_accel_interrupt_info *info = intr->info; int ret; + /* We do not always have an IRQ */ + if (!data->has_irq) + return 0; + if (state) { if (atomic_inc_return(&intr->users) > 1) return 0; @@ -1696,6 +1700,7 @@ int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq, } if (irq > 0) { + data->has_irq = true; ret = devm_request_threaded_irq(dev, irq, bmc150_accel_irq_handler, bmc150_accel_irq_thread_handler, diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h index 7a7baf52e595..6e9bb69a1fd4 100644 --- a/drivers/iio/accel/bmc150-accel.h +++ b/drivers/iio/accel/bmc150-accel.h @@ -59,6 +59,7 @@ enum bmc150_accel_trigger_id { struct bmc150_accel_data { struct regmap *regmap; struct regulator_bulk_data regulators[2]; + bool has_irq; struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS]; struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS]; struct mutex mutex; --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20251027-fix-bmc150-7e568122b265 Best regards, -- Linus Walleij <linus.walleij(a)linaro.org>

1 week, 5 days

2
4
0 0

[PATCH 5.10] ipv6: sr: Fix MAC comparison to be constant-time

by Andrey Troshin

From: Eric Biggers <ebiggers(a)kernel.org> commit a458b2902115b26a25d67393b12ddd57d1216aaa upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> Reviewed-by: Andrea Mayer <andrea.mayer(a)uniroma2.it> Link: https://patch.msgid.link/20250818202724.15713-1-ebiggers@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Andrey Troshin: backport fix for 5.10] Signed-off-by: Andrey Troshin <drtrosh(a)yandex-team.ru> --- Backport fix for CVE-2025-39702 Link: https://nvd.nist.gov/vuln/detail/CVE-2025-39702 --- net/ipv6/seg6_hmac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c index 4a3f7bb027ed..8bb7f94cba1e 100644 --- a/net/ipv6/seg6_hmac.c +++ b/net/ipv6/seg6_hmac.c @@ -35,6 +35,7 @@ #include <net/xfrm.h> #include <crypto/hash.h> +#include <crypto/algapi.h> #include <crypto/sha.h> #include <net/seg6.h> #include <net/genetlink.h> @@ -270,7 +271,7 @@ bool seg6_hmac_validate_skb(struct sk_buff *skb) if (seg6_hmac_compute(hinfo, srh, &ipv6_hdr(skb)->saddr, hmac_output)) return false; - if (memcmp(hmac_output, tlv->hmac, SEG6_HMAC_FIELD_LEN) != 0) + if (crypto_memneq(hmac_output, tlv->hmac, SEG6_HMAC_FIELD_LEN)) return false; return true; -- 2.34.1

1 week, 5 days

1
0
0 0

[PATCH 2/2] ext4: fix string copying in parse_apply_sb_mount_options()

by Fedor Pchelkin

strscpy_pad() can't be used to copy a possibly non-NUL-term string into a NUL-term string. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostr_pad()") provides additional information in that regard. So if this happens, the following warning is observed: strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Call Trace: <TASK> __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sized_strscpy include/linux/fortify-string.h:309 [inline] parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline] __ext4_fill_super fs/ext4/super.c:5261 [inline] ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706 get_tree_bdev_flags+0x387/0x620 fs/super.c:1636 vfs_get_tree+0x93/0x380 fs/super.c:1814 do_new_mount fs/namespace.c:3553 [inline] path_mount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __do_sys_mount fs/namespace.c:4103 [inline] __se_sys_mount fs/namespace.c:4080 [inline] __x64_sys_mount+0x280/0x300 fs/namespace.c:4080 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e Since s_es->s_mount_opts might be non-NUL-term, annotate it with __nonstring and use the proper memtostr_pad() routine to get its NULL-term copy. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 8ecb790ea8c3 ("ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- fs/ext4/ext4.h | 2 +- fs/ext4/super.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 57087da6c7be..4c8698316457 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1429,7 +1429,7 @@ struct ext4_super_block { __le64 s_last_error_block; /* block involved of last error */ __u8 s_last_error_func[32] __nonstring; /* function where the error happened */ #define EXT4_S_ERR_END offsetof(struct ext4_super_block, s_mount_opts) - __u8 s_mount_opts[64]; + __u8 s_mount_opts[64] __nonstring; __le32 s_usr_quota_inum; /* inode for tracking user quota */ __le32 s_grp_quota_inum; /* inode for tracking group quota */ __le32 s_overhead_clusters; /* overhead blocks/clusters in fs */ diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 33e7c08c9529..57df129873e3 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2483,7 +2483,7 @@ static int parse_apply_sb_mount_options(struct super_block *sb, if (!sbi->s_es->s_mount_opts[0]) return 0; - strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts); + memtostr_pad(s_mount_opts, sbi->s_es->s_mount_opts); fc = kzalloc(sizeof(struct fs_context), GFP_KERNEL); if (!fc) -- 2.51.0

1 week, 5 days

1
1
0 0

[PATCH] iommu/of: Fix device node reference leak in of_iommu_get_resv_regions

by Miaoqian Lin

In of_iommu_get_resv_regions(), of_find_node_by_phandle() returns a device node with its reference count incremented. The caller is responsible for releasing this reference when the node is no longer needed. Add a call to of_node_put() to release the reference after the usage. Found via static analysis. Fixes: a5bf3cfce8cb ("iommu: Implement of_iommu_get_resv_regions()") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/iommu/of_iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 6b989a62def2..02448da8ff90 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -256,6 +256,7 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list) maps = of_translate_dma_region(np, maps, &iova, &length); if (length == 0) { dev_warn(dev, "Cannot reserve IOVA region of 0 size\n"); + of_node_put(np); continue; } type = iommu_resv_region_get_type(dev, &phys, iova, length); @@ -265,6 +266,7 @@ void of_iommu_get_resv_regions(struct device *dev, struct list_head *list) if (region) list_add_tail(&region->list, list); } + of_node_put(np); } } #endif -- 2.39.5 (Apple Git-154)

1 week, 5 days

3
2
0 0

[PATCH AUTOSEL 6.17-6.1] spi: intel-pci: Add support for Intel Wildcat Lake SPI serial flash

by Sasha Levin

From: Mika Westerberg <mika.westerberg(a)linux.intel.com> [ Upstream commit f7e37affbc9085f2b77ccb6596521a44eabf7505 ] Add Intel Wildcat Lake SPI serial flash PCI ID to the list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-4-mika.westerberg@linux.int… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## BACKPORT ANALYSIS COMPLETE **Backport Status: YES** --- ## DETAILED ANALYSIS ### 1. COMMIT CHARACTERIZATION **Type**: Hardware enablement (PCI device ID addition) **Code Changes**: - Single line addition to `drivers/spi/spi-intel-pci.c` - Adds PCI device ID `0x4d23` (Intel Wildcat Lake SPI serial flash) - Maps to existing `cnl_info` configuration structure - No behavioral changes to existing code paths ### 2. SEMANTIC CODE ANALYSIS FINDINGS #### Tools Used: - **Read**: Examined the complete file structure (drivers/spi/spi-intel- pci.c:68-99) - **Grep**: Located PCI device table usage and MODULE_DEVICE_TABLE macro - **Git analysis**: Reviewed commit history and backport precedents #### Impact Scope Analysis: - **Direct impact**: Only affects systems with PCI ID 0x4d23 (Wildcat Lake hardware) - **Caller analysis**: The PCI device table is used by the kernel's PCI subsystem for automatic device-driver matching - **Dependency analysis**: Uses `cnl_info` structure (drivers/spi/spi- intel-pci.c:38-41), which has existed since 2022 - **Risk assessment**: Zero risk to existing hardware - new entry only triggers on matching PCI ID ### 3. BACKPORT PRECEDENT (Strong Evidence) I found multiple similar commits that **WERE backported** to stable trees: **Example 1 - Lunar Lake-M** (commit ec33549be99fe): ``` commit ec33549be99fe25c6927c8b3d6ed13918b27656e Author: Mika Westerberg <mika.westerberg(a)linux.intel.com> Commit: Sasha Levin <sashal(a)kernel.org> [STABLE MAINTAINER] spi: intel-pci: Add support for Lunar Lake-M SPI serial flash [ Upstream commit 8f44e3808200c1434c26ef459722f88f48b306df ] ``` **Example 2 - Granite Rapids** (commit 60446b5e74865): ``` commit 60446b5e74865acff1af5f2d89d99551c8e6e2c1 Author: Mika Westerberg <mika.westerberg(a)linux.intel.com> Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [STABLE MAINTAINER] spi: intel-pci: Add support for Granite Rapids SPI serial flash [ Upstream commit 9855d60cfc720ff32355484c119acafd3c4dc806 ] ``` **Key Finding**: Both commits were backported to stable trees by stable maintainers (Sasha Levin, Greg Kroah-Hartman) **despite having NO explicit stable tags** in the original commits. ### 4. STABLE TREE COMPLIANCE **Positive Factors**: - ✅ Fixes a real user problem (Wildcat Lake users cannot access SPI flash on stable kernels) - ✅ Extremely low risk (single line, static table entry) - ✅ No architectural changes - ✅ No dependencies on unreleased features - ✅ Follows established backporting pattern for PCI ID additions - ✅ "Obviously correct" - uses tested configuration from 20+ other Intel platforms **Considerations**: - ⚠️ Technically a "new feature" (new hardware support) - ✅ However, PCI ID additions are a **special exception** routinely accepted by stable maintainers - ✅ Hardware enablement is considered "fixing" missing support for existing hardware ### 5. DEPENDENCY VERIFICATION - **cnl_info structure**: Present since 2022, exists in all stable kernels that would receive this backport - **PCI_VDEVICE macro**: Standard kernel infrastructure - **intel_spi_probe()**: Core function, no recent changes that would conflict - **Clean backport**: No conflicts expected with any stable kernel version ### 6. RISK ANALYSIS **Regression Risk**: **MINIMAL** - Only triggered when PCI ID 0x4d23 is detected - No effect on systems without Wildcat Lake hardware - Uses well-tested code path (cnl_info shared with 20+ other platforms) - No user-space API changes **Testing Coverage**: - Same code path used by numerous Intel platforms (Ice Lake, Tiger Lake, Alder Lake, etc.) - Configuration structure (cnl_info) battle-tested across multiple generations ### 7. COMMIT MESSAGE ANALYSIS The commit message is: - ✅ Clear and descriptive - ✅ Identifies specific hardware (Intel Wildcat Lake) - ✅ Consistent with previous similar commits - ❌ No "Fixes:" tag (not applicable - this is new hardware support) - ❌ No "Cc: stable(a)vger.kernel.org" tag (but precedent shows this doesn't prevent backporting) --- ## RECOMMENDATION **YES - This commit SHOULD be backported to stable kernel trees** ### Rationale: 1. **Strong precedent**: Multiple similar PCI ID additions for Intel platforms (Lunar Lake, Granite Rapids, Arrow Lake) have been backported to stable trees by stable maintainers 2. **User benefit**: Enables critical SPI flash functionality for Wildcat Lake hardware owners running stable kernels 3. **Minimal risk**: Single-line change to static table with no impact on existing hardware 4. **Well-established pattern**: PCI ID additions for hardware enablement are routinely accepted for stable backports as they "fix" missing hardware support 5. **Clean backport**: No dependencies or conflicts expected ### Target Stable Trees: - All currently maintained stable kernels (6.17.x, 6.16.x, 6.15.x, etc.) - The commit is from v6.18-rc3, so it would benefit users on any stable kernel before 6.18 drivers/spi/spi-intel-pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi-intel-pci.c b/drivers/spi/spi-intel-pci.c index 4b63cb98df9cc..4bb158a23349e 100644 --- a/drivers/spi/spi-intel-pci.c +++ b/drivers/spi/spi-intel-pci.c @@ -75,6 +75,7 @@ static const struct pci_device_id intel_spi_pci_ids[] = { { PCI_VDEVICE(INTEL, 0x38a4), (unsigned long)&bxt_info }, { PCI_VDEVICE(INTEL, 0x43a4), (unsigned long)&cnl_info }, { PCI_VDEVICE(INTEL, 0x4b24), (unsigned long)&bxt_info }, + { PCI_VDEVICE(INTEL, 0x4d23), (unsigned long)&cnl_info }, { PCI_VDEVICE(INTEL, 0x4da4), (unsigned long)&bxt_info }, { PCI_VDEVICE(INTEL, 0x51a4), (unsigned long)&cnl_info }, { PCI_VDEVICE(INTEL, 0x54a4), (unsigned long)&cnl_info }, -- 2.51.0

1 week, 5 days

1
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2025