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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251009055401.94174-1-ioworker0@gmail.com>
Date: Thu,  9 Oct 2025 13:54:01 +0800
From: Lance Yang <ioworker0@...il.com>
To: akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	urezki@...il.com,
	yadong.qi@...ux.alibaba.com,
	ying.huang@...ux.alibaba.com
Subject: Re: [PATCH] mm: vmalloc: BUG_ON if mapping size is not PAGE_SIZE aligned

>> In mm/vmalloc.c, the function vmap_pte_range() assumes that the
>> mapping size is aligned to PAGE_SIZE. If this assumption is
>> violated, the loop will become infinite because the termination
>> condition (`addr != end`) will never be met. This can lead to
>> overwriting other VA ranges and/or random pages physically follow
>> the page table.
>> 
>> It's the caller's responsibility to ensure that the mapping size
>> is aligned to PAGE_SIZE. However, the memory corruption is hard
>> to root cause. To identify the programming error in the caller
>> easier, check whether the mapping size is PAGE_SIZE aligned with
>> BUG_ON().
>> 
>> ..
>>
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -100,6 +100,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>>  	struct page *page;
>>  	unsigned long size = PAGE_SIZE;
>>  
>> +	BUG_ON(!PAGE_ALIGNED(end - addr));
>> +
>>  	pfn = phys_addr >> PAGE_SHIFT;
>>  	pte = pte_alloc_kernel_track(pmd, addr, mask);
>>  	if (!pte)
>
>We try to avoid adding BUG()s - deliberately crashing the kernel is
>pretty cruel to the user.  It's far better to WARN and to continue in
>some fashion so the user can at least gather logs, etc.
>
>How about
>
>	if (WARN_ON(!PAGE_ALIGNED(end - addr)))
>		return -ENOMEM;
>
>?
>
>(Or VM_WARN_ON)

I agree with Andrew. Using WARN_ON/VM_WARN_ON and returning an error is
the way to go.

AFAIK, we are moving away from BUG_ON() in MM whenever an error can be
handled gracefully.

Cheers,
Lance

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ