September 2025 - Linux-stable-mirror

[PATCH v2] nvmem: layouts: fix automatic module loading

by Michael Walle

To support loading of a layout module automatically the MODALIAS variable in the uevent is needed. Add it. Fixes: fc29fd821d9a ("nvmem: core: Rework layouts to become regular devices") Cc: stable(a)vger.kernel.org Signed-off-by: Michael Walle <mwalle(a)kernel.org> --- I'm still not sure if the sysfs modalias file is required or not. It seems to work without it. I could't find any documentation about it. v2: - add Cc: stable --- drivers/nvmem/layouts.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/nvmem/layouts.c b/drivers/nvmem/layouts.c index 65d39e19f6ec..f381ce1e84bd 100644 --- a/drivers/nvmem/layouts.c +++ b/drivers/nvmem/layouts.c @@ -45,11 +45,24 @@ static void nvmem_layout_bus_remove(struct device *dev) return drv->remove(layout); } +static int nvmem_layout_bus_uevent(const struct device *dev, + struct kobj_uevent_env *env) +{ + int ret; + + ret = of_device_uevent_modalias(dev, env); + if (ret != ENODEV) + return ret; + + return 0; +} + static const struct bus_type nvmem_layout_bus_type = { .name = "nvmem-layout", .match = nvmem_layout_bus_match, .probe = nvmem_layout_bus_probe, .remove = nvmem_layout_bus_remove, + .uevent = nvmem_layout_bus_uevent, }; int __nvmem_layout_driver_register(struct nvmem_layout_driver *drv, -- 2.39.5

2 weeks, 3 days

3
2
0 0

[PATCH 6.6 1/2] Revert "spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"

by jinfeng.wang.cn＠windriver.com

From: Jinfeng Wang <jinfeng.wang.cn(a)windriver.com> This reverts commit 1af6d1696ca40b2d22889b4b8bbea616f94aaa84. There is cadence-qspi ff8d2000.spi: Unbalanced pm_runtime_enable! error without this revert. After reverting commit cdfb20e4b34a ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 1af6d1696ca4 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"), Unbalanced pm_runtime_enable! error does not appear. These two commits are backported from upstream commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"). The commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths") fix commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance"). The commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") fix commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings"). The commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings") fix commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support"). 6.6.y only backport commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"), but does not backport commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") and commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings"). And the backport of commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") differs with the original patch. So there is Unbalanced pm_runtime_enable error. If revert the backport for commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"), there is no error. If backport commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") and commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings"), there is hang during booting. I didn't find the cause of the hang. Since commit 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") and commit 86401132d7bb ("spi: spi-cadence-quadspi: Fix missing unwind goto warnings") are not backported, commit b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 04a8ff1bc351 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths") are not needed. So revert commits commit cdfb20e4b34a ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") and commit 1af6d1696ca4 ("spi: cadence-quadspi: fix cleanup of rx_chan on failure paths"). Signed-off-by: Jinfeng Wang <jinfeng.wang.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Kernel builds successfully with patch. Test enviroment overview: Branch linux-6.6.y Tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Hardware: compiled on X86 machine GCC: gcc version 11.4.0 (Ubuntu~20.04) commands: make clean;make allyesconfig; no building error is seen gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.2) Hardware: compiled on socfpga stratix10 board verified by check the dmesg log and bind/unbind spi and no Unbalanced pm_runtime_enable! error is seen any more. cmds: dmesg | grep "Unbalanced pm_runtime_enable" echo ff8d2000.spi > /sys/bus/platform/drivers/cadence-qspi/unbind echo ff8d2000.spi > /sys/bus/platform/drivers/cadence-qspi/bind --- drivers/spi/spi-cadence-quadspi.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index 7c17b8c0425e..9285a683324f 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1870,6 +1870,11 @@ static int cqspi_probe(struct platform_device *pdev) pm_runtime_enable(dev); + if (cqspi->rx_chan) { + dma_release_channel(cqspi->rx_chan); + goto probe_setup_failed; + } + ret = spi_register_controller(host); if (ret) { dev_err(&pdev->dev, "failed to register SPI ctlr %d\n", ret); -- 2.25.1

2 weeks, 3 days

3
3
0 0

[PATCH] drivers/misc/amd-sbi/Kconfig: select REGMAP_I2C

by Max Kellermann

Without CONFIG_REGMAP, rmi-i2c.c fails to build because struct regmap_config is not defined: drivers/misc/amd-sbi/rmi-i2c.c: In function ‘sbrmi_i2c_probe’: drivers/misc/amd-sbi/rmi-i2c.c:57:16: error: variable ‘sbrmi_i2c_regmap_config’ has initializer but incomplete type 57 | struct regmap_config sbrmi_i2c_regmap_config = { | ^~~~~~~~~~~~~ Additionally, CONFIG_REGMAP_I2C is needed for devm_regmap_init_i2c(): ld: drivers/misc/amd-sbi/rmi-i2c.o: in function `sbrmi_i2c_probe': drivers/misc/amd-sbi/rmi-i2c.c:69:(.text+0x1c0): undefined reference to `__devm_regmap_init_i2c' Fixes: 013f7e7131bd ("misc: amd-sbi: Use regmap subsystem") Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> --- drivers/misc/amd-sbi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig index 4840831c84ca..4aae0733d0fc 100644 --- a/drivers/misc/amd-sbi/Kconfig +++ b/drivers/misc/amd-sbi/Kconfig @@ -2,6 +2,7 @@ config AMD_SBRMI_I2C tristate "AMD side band RMI support" depends on I2C + select REGMAP_I2C help Side band RMI over I2C support for AMD out of band management. -- 2.47.2

2 weeks, 3 days

2
1
0 0

[PATCH v2 RESEND] media: as102: fix to not free memory after the device is registered in as102_usb_probe()

by Jeongjun Park

In as102_usb driver, the following race condition occurs: ``` CPU0 CPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); open("/path/to/dev"); // open as102 dev .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed. Cc: <stable(a)vger.kernel.org> Reported-by: syzbot+47321e8fd5a4c84088db(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=47321e8fd5a4c84088db Fixes: cd19f7d3e39b ("[media] as102: fix leaks at failure paths in as102_usb_probe()") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- v2: Fix incorrect patch description style and CC stable mailing list - Link to v1: https://lore.kernel.org/all/20250822143539.1157329-1-aha310510@gmail.com/ --- drivers/media/usb/as102/as102_usb_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/usb/as102/as102_usb_drv.c b/drivers/media/usb/as102/as102_usb_drv.c index e0ef66a522e2..abde5666b2ee 100644 --- a/drivers/media/usb/as102/as102_usb_drv.c +++ b/drivers/media/usb/as102/as102_usb_drv.c @@ -404,6 +404,7 @@ static int as102_usb_probe(struct usb_interface *intf, as102_free_usb_stream_buffer(as102_dev); failed_stream: usb_deregister_dev(intf, &as102_usb_class_driver); + return ret; failed: usb_put_dev(as102_dev->bus_adap.usb_dev); usb_set_intfdata(intf, NULL); --

2 weeks, 3 days

1
0
0 0

[PATCH v2 RESEND] media: hackrf: fix to not free memory after the device is registered in hackrf_probe()

by Jeongjun Park

In hackrf driver, the following race condition occurs: ``` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... open("/path/to/dev"); // open hackrf dev .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly. Cc: <stable(a)vger.kernel.org> Reported-by: syzbot+6ffd76b5405c006a46b7(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6ffd76b5405c006a46b7 Reported-by: syzbot+f1b20958f93d2d250727(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1b20958f93d2d250727 Fixes: 8bc4a9ed8504 ("[media] hackrf: add support for transmitter") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- v2: Fix incorrect patch description style and CC stable mailing list - Link to v1: https://lore.kernel.org/all/20250822142729.1156816-1-aha310510@gmail.com/ --- drivers/media/usb/hackrf/hackrf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/hackrf/hackrf.c b/drivers/media/usb/hackrf/hackrf.c index 0b50de8775a3..d7a84422193d 100644 --- a/drivers/media/usb/hackrf/hackrf.c +++ b/drivers/media/usb/hackrf/hackrf.c @@ -1515,6 +1515,8 @@ static int hackrf_probe(struct usb_interface *intf, video_unregister_device(&dev->rx_vdev); err_v4l2_device_unregister: v4l2_device_unregister(&dev->v4l2_dev); + dev_dbg(&intf->dev, "failed=%d\n", ret); + return ret; err_v4l2_ctrl_handler_free_tx: v4l2_ctrl_handler_free(&dev->tx_ctrl_handler); err_v4l2_ctrl_handler_free_rx: --

2 weeks, 3 days

1
0
0 0

[PATCH] perf/x86/intel: Fix KASAN global-out-of-bounds warning

by Dapeng Mi

When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen. 196.273657] ================================================================== [ 196.273662] BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 [ 196.273669] Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 [ 196.273676] CPU: 126 UID: 0 PID: 9850 Comm: dtlb Kdump: loaded Not tainted 6.17.0-rc3-2025-08-29-intel-next-34160-g316938187eb0 #1 PREEMPT(none) [ 196.273680] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P83.2507110208 07/11/2025 [ 196.273682] Call Trace: [ 196.273683] <NMI> [ 196.273684] dump_stack_lvl+0x55/0x70 [ 196.273689] print_address_description.constprop.0+0x2c/0x3d0 [ 196.273694] ? cmt_latency_data+0x176/0x1b0 [ 196.273696] print_report+0xb4/0x270 [ 196.273699] ? kasan_addr_to_slab+0xd/0xa0 [ 196.273702] kasan_report+0xb8/0xf0 [ 196.273705] ? cmt_latency_data+0x176/0x1b0 [ 196.273707] cmt_latency_data+0x176/0x1b0 [ 196.273710] setup_arch_pebs_sample_data+0xf49/0x2560 [ 196.273713] intel_pmu_drain_arch_pebs+0x577/0xb00 [ 196.273716] ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10 [ 196.273719] ? perf_output_begin+0x3e4/0xa10 [ 196.273724] ? intel_pmu_drain_bts_buffer+0xc2/0x6a0 [ 196.273727] ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10 [ 196.273730] handle_pmi_common+0x6c4/0xc80 [ 196.273734] ? __pfx_handle_pmi_common+0x10/0x10 [ 196.273738] ? intel_bts_interrupt+0xd3/0x4d0 [ 196.273740] ? __pfx_intel_bts_interrupt+0x10/0x10 [ 196.273742] ? intel_pmu_lbr_enable_all+0x25/0x150 [ 196.273745] intel_pmu_handle_irq+0x388/0x700 [ 196.273748] perf_event_nmi_handler+0xff/0x150 [ 196.273751] nmi_handle.part.0+0xa8/0x2d0 [ 196.273755] ? perf_output_begin+0x3e9/0xa10 [ 196.273757] default_do_nmi+0x79/0x1a0 [ 196.273760] fred_exc_nmi+0x40/0x90 [ 196.273762] asm_fred_entrypoint_kernel+0x45/0x60 [ 196.273765] RIP: 0010:perf_output_begin+0x3e9/0xa10 [ 196.273768] Code: 54 24 1c 85 d2 0f 85 19 03 00 00 48 8b 44 24 18 48 c1 e8 03 42 0f b6 04 28 84 c0 74 08 3c 03 0f 8e 25 05 00 00 41 8b 44 24 18 <c1> e0 0c 48 98 48 83 e8 01 80 7c 24 2a 00 0f 85 f9 02 00 00 4c 29 [ 196.273770] RSP: 0018:ffffc9001cf575e8 EFLAGS: 00000246 [ 196.273774] RAX: 0000000000000080 RBX: ffff88c1a0f95028 RCX: 0000000000000004 [ 196.273775] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88c08c8f9408 [ 196.273777] RBP: 0000000000000028 R08: 0000000000000000 R09: ffffed18341f2a05 [ 196.273778] R10: ffff88c1a0f9502f R11: ffff88c1a0dbe1b8 R12: ffff88c1a0f95000 [ 196.273779] R13: dffffc0000000000 R14: 0000000000000000 R15: ffffc9001cf577e0 [ 196.273782] </NMI> The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big) So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue. Reported-by: Xudong Hao <xudong.hao(a)intel.com> Cc: stable(a)vger.kernel.org Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions") Signed-off-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> --- arch/x86/events/intel/ds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index c0b7ac1c7594..d1ac1f1ceee9 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -317,7 +317,7 @@ static u64 __grt_latency_data(struct perf_event *event, u64 status, { u64 val; - WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big); + WARN_ON_ONCE(is_hybrid() && hybrid_pmu(event->pmu)->pmu_type == hybrid_big); dse &= PERF_PEBS_DATA_SOURCE_GRT_MASK; val = hybrid_var(event->pmu, pebs_data_source)[dse]; base-commit: 16ed389227651330879e17bd83d43bd234006722 -- 2.34.1

2 weeks, 3 days

1
0
0 0

[merged mm-hotfixes-stable] mm-memory-failure-fix-redundant-updates-for-already-poisoned-pages.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/memory-failure: fix redundant updates for already poisoned pages has been removed from the -mm tree. Its filename was mm-memory-failure-fix-redundant-updates-for-already-poisoned-pages.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Kyle Meyer <kyle.meyer(a)hpe.com> Subject: mm/memory-failure: fix redundant updates for already poisoned pages Date: Thu, 28 Aug 2025 13:38:20 -0500 Duplicate memory errors can be reported by multiple sources. Passing an already poisoned page to action_result() causes issues: * The amount of hardware corrupted memory is incorrectly updated. * Per NUMA node MF stats are incorrectly updated. * Redundant "already poisoned" messages are printed. Avoid those issues by: * Skipping hardware corrupted memory updates for already poisoned pages. * Skipping per NUMA node MF stats updates for already poisoned pages. * Dropping redundant "already poisoned" messages. Make MF_MSG_ALREADY_POISONED consistent with other action_page_types and make calls to action_result() consistent for already poisoned normal pages and huge pages. Link: https://lkml.kernel.org/r/aLCiHMy12Ck3ouwC@hpe.com Fixes: b8b9488d50b7 ("mm/memory-failure: improve memory failure action_result messages") Signed-off-by: Kyle Meyer <kyle.meyer(a)hpe.com> Reviewed-by: Jiaqi Yan <jiaqiyan(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Jane Chu <jane.chu(a)oracle.com> Acked-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Kyle Meyer <kyle.meyer(a)hpe.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: "Luck, Tony" <tony.luck(a)intel.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Russ Anderson <russ.anderson(a)hpe.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-fix-redundant-updates-for-already-poisoned-pages +++ a/mm/memory-failure.c @@ -956,7 +956,7 @@ static const char * const action_page_ty [MF_MSG_BUDDY] = "free buddy page", [MF_MSG_DAX] = "dax page", [MF_MSG_UNSPLIT_THP] = "unsplit thp", - [MF_MSG_ALREADY_POISONED] = "already poisoned", + [MF_MSG_ALREADY_POISONED] = "already poisoned page", [MF_MSG_UNKNOWN] = "unknown page", }; @@ -1349,9 +1349,10 @@ static int action_result(unsigned long p { trace_memory_failure_event(pfn, type, result); - num_poisoned_pages_inc(pfn); - - update_per_node_mf_stats(pfn, result); + if (type != MF_MSG_ALREADY_POISONED) { + num_poisoned_pages_inc(pfn); + update_per_node_mf_stats(pfn, result); + } pr_err("%#lx: recovery action for %s: %s\n", pfn, action_page_types[type], action_name[result]); @@ -2094,12 +2095,11 @@ retry: *hugetlb = 0; return 0; } else if (res == -EHWPOISON) { - pr_err("%#lx: already hardware poisoned\n", pfn); if (flags & MF_ACTION_REQUIRED) { folio = page_folio(p); res = kill_accessing_process(current, folio_pfn(folio), flags); - action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); } + action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); return res; } else if (res == -EBUSY) { if (!(flags & MF_NO_RETRY)) { @@ -2285,7 +2285,6 @@ try_again: goto unlock_mutex; if (TestSetPageHWPoison(p)) { - pr_err("%#lx: already hardware poisoned\n", pfn); res = -EHWPOISON; if (flags & MF_ACTION_REQUIRED) res = kill_accessing_process(current, pfn, flags); _ Patches currently in -mm which might be from kyle.meyer(a)hpe.com are

2 weeks, 3 days

1
0
0 0

[merged mm-hotfixes-stable] s390-kexec-initialize-kexec_buf-struct.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: s390: kexec: initialize kexec_buf struct has been removed from the -mm tree. Its filename was s390-kexec-initialize-kexec_buf-struct.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: s390: kexec: initialize kexec_buf struct Date: Wed, 27 Aug 2025 03:42:23 -0700 The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-3-1df9882bb01a@debian.org Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao(a)debian.org> Cc: Albert Ou <aou(a)eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Alexandre Ghiti <alex(a)ghiti.fr> Cc: Baoquan He <bhe(a)redhat.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/s390/kernel/kexec_elf.c | 2 +- arch/s390/kernel/kexec_image.c | 2 +- arch/s390/kernel/machine_kexec_file.c | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) --- a/arch/s390/kernel/kexec_elf.c~s390-kexec-initialize-kexec_buf-struct +++ a/arch/s390/kernel/kexec_elf.c @@ -16,7 +16,7 @@ static int kexec_file_add_kernel_elf(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; const Elf_Ehdr *ehdr; const Elf_Phdr *phdr; Elf_Addr entry; --- a/arch/s390/kernel/kexec_image.c~s390-kexec-initialize-kexec_buf-struct +++ a/arch/s390/kernel/kexec_image.c @@ -16,7 +16,7 @@ static int kexec_file_add_kernel_image(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; buf.image = image; --- a/arch/s390/kernel/machine_kexec_file.c~s390-kexec-initialize-kexec_buf-struct +++ a/arch/s390/kernel/machine_kexec_file.c @@ -129,7 +129,7 @@ static int kexec_file_update_purgatory(s static int kexec_file_add_purgatory(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; int ret; buf.image = image; @@ -152,7 +152,7 @@ static int kexec_file_add_purgatory(stru static int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data) { - struct kexec_buf buf; + struct kexec_buf buf = {}; int ret; buf.image = image; @@ -184,7 +184,7 @@ static int kexec_file_add_ipl_report(str { __u32 *lc_ipl_parmblock_ptr; unsigned int len, ncerts; - struct kexec_buf buf; + struct kexec_buf buf = {}; unsigned long addr; void *ptr, *end; int ret; _ Patches currently in -mm which might be from leitao(a)debian.org are

2 weeks, 3 days

1
0
0 0

[merged mm-hotfixes-stable] riscv-kexec-initialize-kexec_buf-struct.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: riscv: kexec: initialize kexec_buf struct has been removed from the -mm tree. Its filename was riscv-kexec-initialize-kexec_buf-struct.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: riscv: kexec: initialize kexec_buf struct Date: Wed, 27 Aug 2025 03:42:22 -0700 The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-2-1df9882bb01a@debian.org Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao(a)debian.org> Cc: Albert Ou <aou(a)eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Alexandre Ghiti <alex(a)ghiti.fr> Cc: Baoquan He <bhe(a)redhat.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/riscv/kernel/kexec_elf.c | 4 ++-- arch/riscv/kernel/kexec_image.c | 2 +- arch/riscv/kernel/machine_kexec_file.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/riscv/kernel/kexec_elf.c~riscv-kexec-initialize-kexec_buf-struct +++ a/arch/riscv/kernel/kexec_elf.c @@ -28,7 +28,7 @@ static int riscv_kexec_elf_load(struct k int i; int ret = 0; size_t size; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; const struct elf_phdr *phdr; kbuf.image = image; @@ -66,7 +66,7 @@ static int elf_find_pbase(struct kimage { int i; int ret; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; const struct elf_phdr *phdr; unsigned long lowest_paddr = ULONG_MAX; unsigned long lowest_vaddr = ULONG_MAX; --- a/arch/riscv/kernel/kexec_image.c~riscv-kexec-initialize-kexec_buf-struct +++ a/arch/riscv/kernel/kexec_image.c @@ -41,7 +41,7 @@ static void *image_load(struct kimage *i struct riscv_image_header *h; u64 flags; bool be_image, be_kernel; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; int ret; /* Check Image header */ --- a/arch/riscv/kernel/machine_kexec_file.c~riscv-kexec-initialize-kexec_buf-struct +++ a/arch/riscv/kernel/machine_kexec_file.c @@ -261,7 +261,7 @@ int load_extra_segments(struct kimage *i int ret; void *fdt; unsigned long initrd_pbase = 0UL; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; char *modified_cmdline = NULL; kbuf.image = image; _ Patches currently in -mm which might be from leitao(a)debian.org are

2 weeks, 3 days

1
0
0 0

[merged mm-hotfixes-stable] arm64-kexec-initialize-kexec_buf-struct-in-load_other_segments.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: arm64: kexec: initialize kexec_buf struct in load_other_segments() has been removed from the -mm tree. Its filename was arm64-kexec-initialize-kexec_buf-struct-in-load_other_segments.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: arm64: kexec: initialize kexec_buf struct in load_other_segments() Date: Wed, 27 Aug 2025 03:42:21 -0700 Patch series "kexec: Fix invalid field access". The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. An initial fix was already landed for arm64[0], and this patchset fixes the problem on the remaining arm64 code and on riscv, as raised by Mark. Discussions about this problem could be found at[1][2]. This patch (of 3): The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-0-1df9882bb01a@debian.org Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-1-1df9882bb01a@debian.org Link: https://lore.kernel.org/all/20250826180742.f2471131255ec1c43683ea07@linux-f… [0] Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnz… [1] Link: https://lore.kernel.org/all/20250826-akpm-v1-1-3c831f0e3799@debian.org/ [2] Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao(a)debian.org> Acked-by: Baoquan He <bhe(a)redhat.com> Cc: Albert Ou <aou(a)eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Alexandre Ghiti <alex(a)ghiti.fr> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Palmer Dabbelt <palmer(a)dabbelt.com> Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm64/kernel/machine_kexec_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/kernel/machine_kexec_file.c~arm64-kexec-initialize-kexec_buf-struct-in-load_other_segments +++ a/arch/arm64/kernel/machine_kexec_file.c @@ -94,7 +94,7 @@ int load_other_segments(struct kimage *i char *initrd, unsigned long initrd_len, char *cmdline) { - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; void *dtb = NULL; unsigned long initrd_load_addr = 0, dtb_len, orig_segments = image->nr_segments; _ Patches currently in -mm which might be from leitao(a)debian.org are

2 weeks, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2025