- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] cifs: Fix memory and information leak in smb3_reconfigure()
by Yongjian Sun 26 Jan '26

26 Jan '26

From: Zilin Guan <zilin(a)seu.edu.cn> mainline inclusion from mainline-v6.19-rc3 commit cb6d5aa9c0f10074f1ad056c3e2278ad2cc7ec8d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13475 CVE: CVE-2025-71151 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak. Fix this by calling kfree_sensitive() on both password buffers before returning in this error case. Fixes: 0f0e357902957 ("cifs: during remount, make sure passwords are in sync") Signed-off-by: Zilin Guan <zilin(a)seu.edu.cn> Reviewed-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/smb/client/fs_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c index 137d03781d52..2344d7150a7b 100644 --- a/fs/smb/client/fs_context.c +++ b/fs/smb/client/fs_context.c @@ -979,6 +979,8 @@ static int smb3_reconfigure(struct fs_context *fc) rc = smb3_sync_session_ctx_passwords(cifs_sb, ses); if (rc) { mutex_unlock(&ses->session_mutex); + kfree_sensitive(new_password); + kfree_sensitive(new_password2); return rc; } -- 2.39.2

2 1

[PATCH] riscv: kexec: Add support for crashkernel CMA reservation
by Jinjie Ruan 26 Jan '26

26 Jan '26

Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the crashkernel= command line option") and commit ab475510e042 ("kdump: implement reserve_crashkernel_cma") added CMA support for kdump crashkernel reservation. This allows the kernel to dynamically allocate contiguous memory for crash dumping when needed, rather than permanently reserving a fixed region at boot time. So extend crashkernel CMA reservation support to riscv. The following changes are made to enable CMA reservation: - Parse and obtain the CMA reservation size along with other crashkernel parameters. - Call reserve_crashkernel_cma() to allocate the CMA region for kdump. - Include the CMA-reserved ranges for kdump kernel to use. - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore. Update kernel-parameters.txt to document CMA support for crashkernel on riscv architecture. Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- Documentation/admin-guide/kernel-parameters.txt | 2 +- arch/riscv/kernel/machine_kexec_file.c | 17 +++++++++++++++-- arch/riscv/mm/init.c | 5 +++-- 3 files changed, 19 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 36bb642a7edd..84e0e6f5d551 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1119,7 +1119,7 @@ Kernel parameters It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. crashkernel=size[KMG],cma - [KNL, X86, ARM64, ppc] Reserve additional crash kernel memory from + [KNL, X86, ARM64, RISCV, ppc] Reserve additional crash kernel memory from CMA. This reservation is usable by the first system's userspace memory and kernel movable allocations (memory balloon, zswap). Pages allocated from this memory range diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c index dd9d92a96517..5c8f3cccbc83 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -59,9 +59,9 @@ static int prepare_elf_headers(void **addr, unsigned long *sz) { struct crash_mem *cmem; unsigned int nr_ranges; - int ret; + int ret, i; - nr_ranges = 1; /* For exclusion of crashkernel region */ + nr_ranges = 1 + crashk_cma_cnt; /* For exclusion of crashkernel region */ walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); cmem = kmalloc(struct_size(cmem, ranges, nr_ranges), GFP_KERNEL); @@ -74,11 +74,24 @@ static int prepare_elf_headers(void **addr, unsigned long *sz) if (ret) goto out; + for (i = 0; i < crashk_cma_cnt; i++) { + cmem->ranges[cmem->nr_ranges].start = crashk_cma_ranges[i].start; + cmem->ranges[cmem->nr_ranges].end = crashk_cma_ranges[i].end; + cmem->nr_ranges++; + } + /* Exclude crashkernel region */ ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); if (!ret) ret = crash_prepare_elf64_headers(cmem, true, addr, sz); + for (i = 0; i < crashk_cma_cnt; ++i) { + ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start, + crashk_cma_ranges[i].end); + if (ret) + goto out; + } + out: kfree(cmem); return ret; diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index addb8a9305be..074d2d5f79ee 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -1404,7 +1404,7 @@ static inline void setup_vm_final(void) */ static void __init arch_reserve_crashkernel(void) { - unsigned long long low_size = 0; + unsigned long long low_size = 0, cma_size = 0; unsigned long long crash_base, crash_size; bool high = false; int ret; @@ -1414,11 +1414,12 @@ static void __init arch_reserve_crashkernel(void) ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(), &crash_size, &crash_base, - &low_size, NULL, &high); + &low_size, &cma_size, &high); if (ret) return; reserve_crashkernel_generic(crash_size, crash_base, low_size, high); + reserve_crashkernel_cma(cma_size); } void __init paging_init(void) -- 2.34.1

1 0

[PATCH OLK-5.10] jfs: add sanity check for agwidth in dbMount
by Zhang Yuwei 26 Jan '26

26 Jan '26

From: Edward Adam Davis <eadavis(a)qq.com> stable inclusion from stable-v6.6.88 commit cc0bc4cb62ce5fa0c383e3bf0765d01f46bd49ac category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC8J7I Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ddf2846f22e8575d6b4b6a66f2100f168b8cd73d ] The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG. To avoid this issue, add a check for agwidth in dbAllocAG. Reported-and-tested-by: syzbot+7c808908291a569281a9(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7c808908291a569281a9 Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- fs/jfs/jfs_dmap.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index 07b81097b84f..d6a9aecf64cb 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -204,6 +204,10 @@ int dbMount(struct inode *ipbmap) bmp->db_aglevel = le32_to_cpu(dbmp_le->dn_aglevel); bmp->db_agheight = le32_to_cpu(dbmp_le->dn_agheight); bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth); + if (!bmp->db_agwidth) { + err = -EINVAL; + goto err_release_metapage; + } bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart); bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size); if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG || -- 2.22.0

2 1

[PATCH OLK-6.6 0/2] CVE-2025-68296
by Xia Fukun 26 Jan '26

26 Jan '26

CVE-2025-68296 Thomas Zimmermann (2): drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup drivers/gpu/drm/drm_fb_helper.c | 12 ++---------- drivers/video/fbdev/core/fbcon.c | 9 +++++++++ 2 files changed, 11 insertions(+), 10 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] support mempool and NUMA.remote for 64KB page
by Jinjiang Tu 26 Jan '26

26 Jan '26

Support mempool and NUMA.remote for 64KB page. Jinjiang Tu (2): mm/pfn_range_alloc: add support for CONFIG_ARM64_64K_PAGES mm/numa_remote: remove depends on ARM64_4K_PAGES arch/arm64/mm/Kconfig | 1 + arch/arm64/mm/pfn_range_alloc.c | 29 ++++++++++++++++++++++------- drivers/base/Kconfig | 2 +- 3 files changed, 24 insertions(+), 8 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6] memcg: avoid dead loop when setting memory.max
by Chen Ridong 26 Jan '26

26 Jan '26

mainline inclusion from mainline-v6.14-rc4 commit 99333229dee41b992f3b0493f6aa2e3528138384 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/78 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A softlockup issue was found with stress test: watchdog: BUG: soft lockup - CPU#27 stuck for 26s! [migration/27:181] CPU: 27 UID: 0 PID: 181 Comm: migration/27 6.14.0-rc2-next-20250210 #1 Stopper: multi_cpu_stop <- stop_machine_from_inactive_cpu RIP: 0010:stop_machine_yield+0x2/0x10 RSP: 0000:ff4a0dcecd19be48 EFLAGS: 00000246 RAX: ffffffff89c0108f RBX: ff4a0dcec03afe44 RCX: 0000000000000000 RDX: ff1cdaaf6eba5808 RSI: 0000000000000282 RDI: ff1cda80c1775a40 RBP: 0000000000000001 R08: 00000011620096c6 R09: 7fffffffffffffff R10: 0000000000000001 R11: 0000000000000100 R12: ff1cda80c1775a40 R13: 0000000000000000 R14: 0000000000000001 R15: ff4a0dcec03afe20 FS: 0000000000000000(0000) GS:ff1cdaaf6eb80000(0000) CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000025e2c2a001 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: multi_cpu_stop+0x8f/0x100 cpu_stopper_thread+0x90/0x140 smpboot_thread_fn+0xad/0x150 kthread+0xc2/0x100 ret_from_fork+0x2d/0x50 The stress test involves CPU hotplug operations and memory control group (memcg) operations. The scenario can be described as follows: echo xx > memory.max cache_ap_online oom_reaper (CPU23) (CPU50) xx < usage stop_machine_from_inactive_cpu for(;;) // all active cpus trigger OOM queue_stop_cpus_work // waiting oom_reaper multi_cpu_stop(migration/xx) // sync all active cpus ack // waiting cpu23 ack // CPU50 loops in multi_cpu_stop waiting cpu50 Detailed explanation: 1. When the usage is larger than xx, an OOM may be triggered. If the process does not handle with ths kill signal immediately, it will loop in the memory_max_write. 2. When cache_ap_online is triggered, the multi_cpu_stop is queued to the active cpus. Within the multi_cpu_stop function, it attempts to synchronize the CPU states. However, the CPU23 didn't acknowledge because it is stuck in a loop within the for(;;). 3. The oom_reaper process is blocked because CPU50 is in a loop, waiting for CPU23 to acknowledge the synchronization request. 4. Finally, it formed cyclic dependency and lead to softlockup and dead loop. To fix this issue, add cond_resched() in the memory_max_write, so that it will not block migration task. Link: https://lkml.kernel.org/r/20250211081819.33307-1-chenridong@huaweicloud.com Fixes: b6e6edcfa405 ("mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage") Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Wang Weiyang <wangweiyang2(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- mm/memcontrol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7a8795130546d..067a3dde6f87f 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -8030,6 +8030,7 @@ static ssize_t memory_max_write(struct kernfs_open_file *of, memcg_memory_event(memcg, MEMCG_OOM); if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0)) break; + cond_resched(); } memcg_wb_domain_size_changed(memcg); -- 2.34.1

2 1

[PATCH OLK-5.10] iommu/amd: Avoid stack buffer overflow from kernel cmdline
by Wang Wensheng 26 Jan '26

26 Jan '26

From: Kees Cook <kees(a)kernel.org> stable inclusion from stable-v5.10.241 commit a732502bf3bbe859613b6d7b2b0313b11f0474ac category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICUXQR CVE: CVE-2025-38676 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8503d0fcb1086a7cfe26df67ca4bd9bd9e99bdec ] While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length. Reported-by: Simcha Kosman <simcha.kosman(a)cyberark.com> Closes: https://lore.kernel.org/all/AS8P193MB2271C4B24BCEDA31830F37AE84A52@AS8P193M… Fixes: b6b26d86c61c ("iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameter") Signed-off-by: Kees Cook <kees(a)kernel.org> Reviewed-by: Ankit Soni <Ankit.Soni(a)amd.com> Link: https://lore.kernel.org/r/20250804154023.work.970-kees@kernel.org Signed-off-by: Joerg Roedel <joerg.roedel(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> --- drivers/iommu/amd/init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index d0a4ec42fd12..8e3570b77798 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -3223,7 +3223,7 @@ static int __init parse_ivrs_acpihid(char *str) { u32 seg = 0, bus, dev, fn; char *hid, *uid, *p, *addr; - char acpiid[ACPIID_LEN] = {0}; + char acpiid[ACPIID_LEN + 1] = { }; /* size with NULL terminator */ int i; addr = strchr(str, '@'); @@ -3249,7 +3249,7 @@ static int __init parse_ivrs_acpihid(char *str) /* We have the '@', make it the terminator to get just the acpiid */ *addr++ = 0; - if (strlen(str) > ACPIID_LEN + 1) + if (strlen(str) > ACPIID_LEN) goto not_found; if (sscanf(str, "=%s", acpiid) != 1) -- 2.22.0

2 1

[PATCH OLK-5.10] HID: core: Harden s32ton() against conversion to 0 bits
by Wang Wensheng 26 Jan '26

26 Jan '26

From: Alan Stern <stern(a)rowland.harvard.edu> mainline inclusion from mainline-v6.17-rc1 commit a6b87bfc2ab5bccb7ad953693c85d9062aef3fdd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICU7B0 CVE: CVE-2025-38556 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: syzbot+b63d677d63bcac06cf90(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.… Tested-by: syzbot+b63d677d63bcac06cf90(a)syzkaller.appspotmail.com Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/613a66cd-4309-4bce-a4f7-2905f9bce0c9@rowland.harva… Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> Conflicts: drivers/hid/hid-core.c [Only context conflict because of commit c653ffc283404 is not applied] Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> --- drivers/hid/hid-core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 3094c33bb8f9..a602f572d458 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1347,7 +1347,12 @@ EXPORT_SYMBOL_GPL(hid_snto32); static u32 s32ton(__s32 value, unsigned n) { - s32 a = value >> (n - 1); + s32 a; + + if (!value || !n) + return 0; + + a = value >> (n - 1); if (a && a != -1) return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1; return value & ((1 << n) - 1); -- 2.22.0

2 1

[PATCH OLK-5.10] hwmon: (ibmpex) fix use-after-free in high/low store
by Zhang Yuwei 26 Jan '26

26 Jan '26

From: Junrui Luo <moonafterrain(a)outlook.com> mainline inclusion from mainline-v6.19-rc2 commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13342 CVE: CVE-2025-68789 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The ibmpex_high_low_store() function retrieves driver data using dev_get_drvdata() and uses it without validation. This creates a race condition where the sysfs callback can be invoked after the data structure is freed, leading to use-after-free. Fix by adding a NULL check after dev_get_drvdata(), and reordering operations in the deletion path to prevent TOCTOU. Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> Reported-by: Junrui Luo <moonafterrain(a)outlook.com> Closes: https://lore.kernel.org/r/MEYPR01MB7886BE2F51BFE41875B74B60AFA0A@MEYPR01MB7… Fixes: 57c7c3a0fdea ("hwmon: IBM power meter driver") Signed-off-by: Junrui Luo <moonafterrain(a)outlook.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Conflicts: drivers/hwmon/ibmpex.c [commit aa1fd9cdabaae not merged] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/hwmon/ibmpex.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c index fe90f0536d76..235d56e96879 100644 --- a/drivers/hwmon/ibmpex.c +++ b/drivers/hwmon/ibmpex.c @@ -282,6 +282,9 @@ static ssize_t ibmpex_high_low_store(struct device *dev, { struct ibmpex_bmc_data *data = dev_get_drvdata(dev); + if (!data) + return -ENODEV; + ibmpex_reset_high_low_data(data); return count; @@ -514,6 +517,9 @@ static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data) { int i, j; + hwmon_device_unregister(data->hwmon_dev); + dev_set_drvdata(data->bmc_device, NULL); + device_remove_file(data->bmc_device, &sensor_dev_attr_reset_high_low.dev_attr); device_remove_file(data->bmc_device, &sensor_dev_attr_name.dev_attr); @@ -527,8 +533,7 @@ static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data) } list_del(&data->list); - dev_set_drvdata(data->bmc_device, NULL); - hwmon_device_unregister(data->hwmon_dev); + ipmi_destroy_user(data->user); kfree(data->sensors); kfree(data); -- 2.22.0

2 1

[PATCH OLK-5.10] of: check previous kernel's ima-kexec-buffer against memory bounds
by Wang Wensheng 26 Jan '26

26 Jan '26

From: Vaibhav Jain <vaibhav(a)linux.ibm.com> mainline inclusion from mainline-v6.0-rc1 commit cbf9c4b9617b6767886a913705ca14b7600c77db category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICGAML CVE: CVE-2022-50159 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below: $ sudo kexec --initrd initrd vmlinux --append='mem=16G' <snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]--- Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with page_is_ram() to ensure correct memory bounds. Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous kernel") Cc: Frank Rowand <frowand.list(a)gmail.com> Cc: Prakhar Srivastava <prsriva(a)linux.microsoft.com> Cc: Lakshmi Ramasubramanian <nramas(a)linux.microsoft.com> Cc: Thiago Jung Bauermann <bauerman(a)linux.ibm.com> Cc: Rob Herring <robh(a)kernel.org> Cc: Ritesh Harjani <ritesh.list(a)gmail.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com> Signed-off-by: Rob Herring <robh(a)kernel.org> Link: https://lore.kernel.org/r/20220531041446.3334259-1-vaibhav@linux.ibm.com Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> --- drivers/of/kexec.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c index d8231c34e873..f0e6495d0536 100644 --- a/drivers/of/kexec.c +++ b/drivers/of/kexec.c @@ -133,6 +133,7 @@ int ima_get_kexec_buffer(void **addr, size_t *size) { int ret, len; unsigned long tmp_addr; + unsigned long start_pfn, end_pfn; size_t tmp_size; const void *prop; @@ -147,6 +148,22 @@ int ima_get_kexec_buffer(void **addr, size_t *size) if (ret) return ret; + /* Do some sanity on the returned size for the ima-kexec buffer */ + if (!tmp_size) + return -ENOENT; + + /* + * Calculate the PFNs for the buffer and ensure + * they are with in addressable memory. + */ + start_pfn = PHYS_PFN(tmp_addr); + end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1); + if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) { + pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n", + tmp_addr, tmp_size); + return -EINVAL; + } + *addr = __va(tmp_addr); *size = tmp_size; -- 2.22.0

2 1