lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <mafs05xb43ch3.fsf@kernel.org>
Date: Thu, 20 Nov 2025 17:17:28 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: ranxiaokai627@....com
Cc: catalin.marinas@....com,  akpm@...ux-foundation.org,  graf@...zon.com,
  rppt@...nel.org,  pasha.tatashin@...een.com,  pratyush@...nel.org,
  changyuanl@...gle.com,  linux-kernel@...r.kernel.org,
  linux-mm@...ck.org,  kexec@...ts.infradead.org,  ran.xiaokai@....com.cn
Subject: Re: [PATCH 2/2] liveupdate: Fix boot failure due to kmemleak access
 to unmapped pages

On Thu, Nov 20 2025, ranxiaokai627@....com wrote:

> From: Ran Xiaokai <ran.xiaokai@....com.cn>
>
> When booting with debug_pagealloc=on while having:
> CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y
> CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=n
> the system fails to boot due to page faults during kmemleak scanning.
>
> This occurs because:
> With debug_pagealloc enabled, __free_pages() invokes
> debug_pagealloc_unmap_pages(), clearing the _PAGE_PRESENT bit for
> freed pages in the direct mapping.
> Commit 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
> releases the KHO scratch region via init_cma_reserved_pageblock(),
> unmapping its physical pages. Subsequent kmemleak scanning accesses
> these unmapped pages, triggering fatal page faults.

I don't know how kmemleak works. Why does kmemleak access the unmapped
pages? If pages are not mapped, it should learn to not access them,
right?

>
> Call kmemleak_no_scan_phys() from kho_reserve_scratch() to
> exclude the reserved region from scanning before
> it is released to the buddy allocator.

kho_reserve_scratch() is called on the first boot. It allocates the
scratch areas for subsequent boots. On every KHO boot after this,
kho_reserve_scratch() is not called and kho_release_scratch() is called
instead since the scratch areas already exist from previous boot.

Eventually both paths converge to kho_init() and call
init_cma_reserved_pageblock().

So shouldn't you call kmemleak_no_scan_phys() from kho_init() instead?
This would reduce code duplication and cover both paths.

>
> Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
> Signed-off-by: Ran Xiaokai <ran.xiaokai@....com.cn>
> ---
>  kernel/liveupdate/kexec_handover.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 224bdf5becb6..dd4942d1d76c 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -11,6 +11,7 @@
>  
>  #include <linux/cleanup.h>
>  #include <linux/cma.h>
> +#include <linux/kmemleak.h>
>  #include <linux/count_zeros.h>
>  #include <linux/kexec.h>
>  #include <linux/kexec_handover.h>
> @@ -654,6 +655,7 @@ static void __init kho_reserve_scratch(void)
>  	if (!addr)
>  		goto err_free_scratch_desc;
>  
> +	kmemleak_no_scan_phys(addr);
>  	kho_scratch[i].addr = addr;
>  	kho_scratch[i].size = size;
>  	i++;
> @@ -664,6 +666,7 @@ static void __init kho_reserve_scratch(void)
>  	if (!addr)
>  		goto err_free_scratch_areas;
>  
> +	kmemleak_no_scan_phys(addr);
>  	kho_scratch[i].addr = addr;
>  	kho_scratch[i].size = size;
>  	i++;
> @@ -676,6 +679,7 @@ static void __init kho_reserve_scratch(void)
>  		if (!addr)
>  			goto err_free_scratch_areas;
>  
> +		kmemleak_no_scan_phys(addr);
>  		kho_scratch[i].addr = addr;
>  		kho_scratch[i].size = size;
>  		i++;

-- 
Regards,
Pratyush Yadav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ