- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] driver core: fix potential null-ptr-deref in device_add()
by Wang Wensheng 30 Jan '26

30 Jan '26

From: Yang Yingliang <yangyingliang(a)huawei.com> mainline inclusion from mainline-v6.3-rc1 commit f6837f34a34973ef6600c08195ed300e24e97317 category: bugfix bugzilla: CVE-2023-54321 CVE: https://atomgit.com/src-openeuler/kernel/issues/13118 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- I got the following null-ptr-deref report while doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482] This is how it happened: w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device. // error path bus_remove_device() // The dev->driver is not null, but driver is not bound. __device_release_driver() klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref. // normal path bus_probe_device() // It's not called yet. device_bind_driver() If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device(). Fixes: 57eee3d23e88 ("Driver core: Call device_pm_add() after bus_add_device() in device_add()") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20221205034904.2077765-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/base/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 81889d8ccbd1..7c4b4add4485 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -3052,6 +3052,7 @@ int device_add(struct device *dev) device_pm_remove(dev); dpm_sysfs_remove(dev); DPMError: + dev->driver = NULL; bus_remove_device(dev); BusError: device_remove_attrs(dev); -- 2.22.0

2 1

[PATCH OLK-5.10] arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
by Wang Wensheng 30 Jan '26

30 Jan '26

From: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> stable inclusion from stable-v5.10.246 commit 64da320252e43456cc9ec3055ff567f168467b37 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11599 CVE: CVE-2025-40346 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2eead19334516c8e9927c11b448fbe512b1f18a1 ] Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise." This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate(). Cc: stable <stable(a)kernel.org> Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com> Fixes: b8fe128dad8f ("arch_topology: Adjust initial CPU capacities with current freq") Link: https://patch.msgid.link/20250923174308.1771906-1-kaushlendra.kumar@intel.c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [ Adjust context ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/base/arch_topology.c [46db6d4797f18 has not merged] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/base/arch_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index ef77b53c2f3d..58359e7ac7e6 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -336,7 +336,7 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) * frequency (by keeping the initial capacity_freq_ref value). */ cpu_clk = of_clk_get(cpu_node, 0); - if (!PTR_ERR_OR_ZERO(cpu_clk)) { + if (!IS_ERR_OR_NULL(cpu_clk)) { per_cpu(capacity_freq_ref, cpu) = clk_get_rate(cpu_clk) / HZ_PER_KHZ; clk_put(cpu_clk); -- 2.22.0

2 1

[PATCH OLK-5.10] usb: early: xhci-dbc: Fix a potential out-of-bound memory access
by Wang Wensheng 30 Jan '26

30 Jan '26

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> mainline inclusion from mainline-v6.3-rc1 commit a4a97ab3db5c081eb6e7dba91306adefb461e0bd category: bugfix bugzilla: hhttps://atomgit.com/src-openeuler/kernel/issues/11438 CVE: CVE-2023-53840 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called. Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen. Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Link: https://lore.kernel.org/r/d6a7562c5e839a195cee85db6dc81817f9372cb1.16750161… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> --- drivers/usb/early/xhci-dbc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c index 6c0434100e38..b0c4071f0b16 100644 --- a/drivers/usb/early/xhci-dbc.c +++ b/drivers/usb/early/xhci-dbc.c @@ -871,7 +871,8 @@ static int xdbc_bulk_write(const char *bytes, int size) static void early_xdbc_write(struct console *con, const char *str, u32 n) { - static char buf[XDBC_MAX_PACKET]; + /* static variables are zeroed, so buf is always NULL terminated */ + static char buf[XDBC_MAX_PACKET + 1]; int chunk, ret; int use_cr = 0; -- 2.22.0

2 1

[PATCH OLK-5.10 0/5] use SYS_CNTVCTSS_EL0 for gettimeofday
by Xinyu Zheng 30 Jan '26

30 Jan '26

Jisheng Zhang (1): arm64: vdso: remove two .altinstructions related symbols Joey Gouly (3): arm64: module: move find_section to header arm64: alternative: patch alternatives in the vDSO arm64: vdso: use SYS_CNTVCTSS_EL0 for gettimeofday Yang Yingliang (1): vdso: do cntvct workaround in the VDSO arch/arm64/include/asm/module.h | 15 ++++++++ arch/arm64/include/asm/vdso.h | 3 ++ arch/arm64/include/asm/vdso/gettimeofday.h | 42 ++++++++++++++++++---- arch/arm64/kernel/alternative.c | 28 +++++++++++++++ arch/arm64/kernel/module.c | 15 -------- arch/arm64/kernel/vdso.c | 2 -- arch/arm64/kernel/vdso/vdso.lds.S | 5 +++ 7 files changed, 87 insertions(+), 23 deletions(-) -- 2.34.1

2 6

[PATCH OLK-5.10] drivers: base: Free devm resources when unregistering a device
by Wang Wensheng 30 Jan '26

30 Jan '26

From: David Gow <davidgow(a)google.com> mainline inclusion from mainline-v6.6-rc1 commit 699fb50d99039a50e7494de644f96c889279aca3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/8116 CVE: CVE-2023-53596 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da ("devres: release resources on device_del()") that got reverted by commit a525a3ddeaca ("driver core: free devres in device_release") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds. Fixes: a525a3ddeaca ("driver core: free devres in device_release") Signed-off-by: David Gow <davidgow(a)google.com> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://lore.kernel.org/r/20230720-kunit-devm-inconsistencies-test-v3-3-6aa… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/base/core.c drivers/base/test/platform-device-test.c drivers/base/test/root-device-test.c [context conflicts: platform-device-test.c and root-device-test.c do not exist. ed9f918174cb "driver core: bus: move bus notifier logic into bus.c" not merged] Signed-off-by: Chen Jun <chenjun102(a)huawei.com> --- drivers/base/core.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index eb82b43181be..81889d8ccbd1 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -3210,6 +3210,17 @@ void device_del(struct device *dev) device_remove_properties(dev); device_links_purge(dev); + /* + * If a device does not have a driver attached, we need to clean + * up any managed resources. We do this in device_release(), but + * it's never called (and we leak the device) if a managed + * resource holds a reference to the device. So release all + * managed resources here, like we do in driver_detach(). We + * still need to do so again in device_release() in case someone + * adds a new resource after this point, though. + */ + devres_release_all(dev); + if (dev->bus) blocking_notifier_call_chain(&dev->bus->p->bus_notifier, BUS_NOTIFY_REMOVED_DEVICE, dev); -- 2.22.0

2 1

[PATCH OLK-5.10] driver core: fix resource leak in device_add()
by Wang Wensheng 30 Jan '26

30 Jan '26

From: Zhengchao Shao <shaozhengchao(a)huawei.com> mainline inclusion from mainline-v6.3-rc1 commit 6977b1a5d67097eaa4d02b0c126c04cc6e8917c0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/8108 CVE: CVE-2023-53594 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When calling kobject_add() failed in device_add(), it will call cleanup_glue_dir() to free resource. But in kobject_add(), dev->kobj.parent has been set to NULL. This will cause resource leak. The process is as follows: device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put() The preceding problem may cause insmod mac80211_hwsim.ko to failed. sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim' Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x224/0x280 kobject_add_internal+0x2aa/0x880 kobject_add+0x135/0x1a0 get_device_parent+0x3d7/0x590 device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim] init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim] do_one_initcall+0x10f/0x630 do_init_module+0x19f/0x5e0 load_module+0x64b7/0x6eb0 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to register things with the same name in the same directory. Fixes: cebf8fd16900 ("driver core: fix race between creating/querying glue dir and its cleanup") Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> Link: https://lore.kernel.org/r/20221123012042.335252-1-shaozhengchao@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> --- drivers/base/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index cdd46fe88fc7..eb82b43181be 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2959,7 +2959,7 @@ int device_add(struct device *dev) /* we require the name to be set before, and pass NULL */ error = kobject_add(&dev->kobj, dev->kobj.parent, NULL); if (error) { - glue_dir = get_glue_dir(dev); + glue_dir = kobj; goto Error; } -- 2.22.0

2 1

[PATCH OLK-5.10 0/2] Fix CVE-2022-49309
by Wang Wensheng 30 Jan '26

30 Jan '26

The cve itself and its later fixes. Duoming Zhou (1): drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback() Hans de Goede (1): drivers: staging: rtl8723bs: Fix locking in rtw_scan_timeout_handler() drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.22.0

2 3

[PATCH OLK-5.10] kernel/resource: fix kfree() of bootmem memory again
by Wang Wensheng 30 Jan '26

30 Jan '26

From: Miaohe Lin <linmiaohe(a)huawei.com> mainline inclusion from mainline-v5.18-rc1 commit 0cbcc92917c5de80f15c24d033566539ad696892 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/486 CVE: CVE-2022-49190 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), we could get a resource allocated during boot via alloc_resource(). And it's required to release the resource using free_resource(). Howerver, many people use kfree directly which will result in kernel BUG. In order to fix this without fixing every call site, just leak a couple of bytes in such corner case. Link: https://lkml.kernel.org/r/20220217083619.19305-1-linmiaohe@huawei.com Fixes: ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Alistair Popple <apopple(a)nvidia.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: kernel/resource.c [Just contexts conflicts.] Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> --- kernel/resource.c | 41 ++++++++--------------------------------- 1 file changed, 8 insertions(+), 33 deletions(-) diff --git a/kernel/resource.c b/kernel/resource.c index 1087f33d70c4..ea4d7a02b8e8 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -53,14 +53,6 @@ struct resource_constraint { static DEFINE_RWLOCK(resource_lock); -/* - * For memory hotplug, there is no way to free resource entries allocated - * by boot mem after the system is up. So for reusing the resource entry - * we need to remember the resource. - */ -static struct resource *bootmem_resource_free; -static DEFINE_SPINLOCK(bootmem_resource_lock); - static struct resource *next_resource(struct resource *p, bool sibling_only) { /* Caller wants to traverse through siblings only */ @@ -149,36 +141,19 @@ __initcall(ioresources_init); static void free_resource(struct resource *res) { - if (!res) - return; - - if (!PageSlab(virt_to_head_page(res))) { - spin_lock(&bootmem_resource_lock); - res->sibling = bootmem_resource_free; - bootmem_resource_free = res; - spin_unlock(&bootmem_resource_lock); - } else { + /** + * If the resource was allocated using memblock early during boot + * we'll leak it here: we can only return full pages back to the + * buddy and trying to be smart and reusing them eventually in + * alloc_resource() overcomplicates resource handling. + */ + if (res && PageSlab(virt_to_head_page(res))) kfree(res); - } } static struct resource *alloc_resource(gfp_t flags) { - struct resource *res = NULL; - - spin_lock(&bootmem_resource_lock); - if (bootmem_resource_free) { - res = bootmem_resource_free; - bootmem_resource_free = res->sibling; - } - spin_unlock(&bootmem_resource_lock); - - if (res) - memset(res, 0, sizeof(struct resource)); - else - res = kzalloc(sizeof(struct resource), flags); - - return res; + return kzalloc(sizeof(struct resource), flags); } /* Return the conflict entry if you can't request it */ -- 2.22.0

2 1

[PATCH OLK-5.10] drm/amd/pm/powerplay/hwmgr/vega20_thermal: Prevent division by zero
by Wang Wensheng 30 Jan '26

30 Jan '26

From: Denis Arefev <arefev(a)swemel.ru> stable inclusion from stable-v5.10.237 commit ce773dd844ee19a605af27f11470887e0f2044a9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/10438 CVE: CVE-2025-37766 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4e3d9508c056d7e0a56b58d5c81253e2a0d22b6c upstream. The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 031db09017da ("drm/amd/powerplay/vega20: enable fan RPM and pwm settings V2") Signed-off-by: Denis Arefev <arefev(a)swemel.ru> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c index 364162ddaa9c..87b7baa9492b 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c @@ -189,7 +189,7 @@ int vega20_fan_ctrl_set_fan_speed_rpm(struct pp_hwmgr *hwmgr, uint32_t speed) uint32_t tach_period, crystal_clock_freq; int result = 0; - if (!speed) + if (!speed || speed > UINT_MAX/8) return -EINVAL; if (PP_CAP(PHM_PlatformCaps_MicrocodeFanControl)) { -- 2.22.0

2 1

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

30 Jan '26

From: Vaibhav Jain <vaibhav(a)linux.ibm.com> mainline inclusion from mainline-v6.0-rc1 commit cbf9c4b9617b6767886a913705ca14b7600c77db category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/9735 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