mm/vmalloc.c | 3 +++ 1 file changed, 3 insertions(+)
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
WARN_ON().
Signed-off-by: Yadong Qi <yadong.qi@linux.alibaba.com>
Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com>
---
v1 -> v2:
* Use WARN_ON instead of BUG_ON
---
mm/vmalloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5edd536ba9d2..2cad593e4677 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -100,6 +100,9 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
struct page *page;
unsigned long size = PAGE_SIZE;
+ if (WARN_ON(!PAGE_ALIGNED(end - addr)))
+ return -ENOMEM;
+
pfn = phys_addr >> PAGE_SHIFT;
pte = pte_alloc_kernel_track(pmd, addr, mask);
if (!pte)
--
2.43.5
Yadong Qi <yadong.qi@linux.alibaba.com> writes: > 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 > WARN_ON(). > > Signed-off-by: Yadong Qi <yadong.qi@linux.alibaba.com> > Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com> > --- > v1 -> v2: > * Use WARN_ON instead of BUG_ON > --- > mm/vmalloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 5edd536ba9d2..2cad593e4677 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -100,6 +100,9 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, > struct page *page; > unsigned long size = PAGE_SIZE; > > + if (WARN_ON(!PAGE_ALIGNED(end - addr))) > + return -ENOMEM; > + EINVAL? > pfn = phys_addr >> PAGE_SHIFT; > pte = pte_alloc_kernel_track(pmd, addr, mask); > if (!pte) --- Best Regards, Huang, Ying
On Thu, 09 Oct 2025 14:38:27 +0800 "Huang, Ying" <ying.huang@linux.alibaba.com> wrote: > Yadong Qi <yadong.qi@linux.alibaba.com> writes: > > > 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 > > WARN_ON(). > > > > Signed-off-by: Yadong Qi <yadong.qi@linux.alibaba.com> > > Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com> > > --- > > v1 -> v2: > > * Use WARN_ON instead of BUG_ON > > --- > > mm/vmalloc.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 5edd536ba9d2..2cad593e4677 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -100,6 +100,9 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, > > struct page *page; > > unsigned long size = PAGE_SIZE; > > > > + if (WARN_ON(!PAGE_ALIGNED(end - addr))) > > + return -ENOMEM; > > + > > EINVAL? > If this errno gets returned to userspace somehow, programmer is going to wonder what was invalid about the arguments which the program passed to the kernel. But either way, the callers of vmap_pte_range() should be audited, to verify that they take appropriate action when this happens.
> -----Original Message----- > From: Andrew Morton <akpm@linux-foundation.org> > Sent: 2025年10月9日 15:04 > To: Huang, Ying <ying.huang@linux.alibaba.com> > Cc: Yadong Qi <yadong.qi@linux.alibaba.com>; urezki@gmail.com; > linux-mm@kvack.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2] mm: vmalloc: WARN_ON if mapping size is not PAGE_SIZE > aligned > > On Thu, 09 Oct 2025 14:38:27 +0800 "Huang, Ying" > <ying.huang@linux.alibaba.com> wrote: > > > Yadong Qi <yadong.qi@linux.alibaba.com> writes: > > > > > 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 > > > WARN_ON(). > > > > > > Signed-off-by: Yadong Qi <yadong.qi@linux.alibaba.com> > > > Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com> > > > --- > > > v1 -> v2: > > > * Use WARN_ON instead of BUG_ON > > > --- > > > mm/vmalloc.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index 5edd536ba9d2..2cad593e4677 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -100,6 +100,9 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long > addr, unsigned long end, > > > struct page *page; > > > unsigned long size = PAGE_SIZE; > > > > > > + if (WARN_ON(!PAGE_ALIGNED(end - addr))) > > > + return -ENOMEM; > > > + > > > > EINVAL? > > > > If this errno gets returned to userspace somehow, programmer is going > to wonder what was invalid about the arguments which the program passed > to the kernel. > > But either way, the callers of vmap_pte_range() should be audited, to > verify that they take appropriate action when this happens. I believe we should modify vmap_pmd_range(), vmap_pud_range(), and vmap_p4d_range() to accept an error code from the callee instead of simply returning -ENOMEM. If there are no other suggestions, I will create a new patch.
© 2016 - 2025 Red Hat, Inc.