All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm/cma: fix reserved page leak on activation failure
@ 2026-05-22  6:26 Muchun Song
  2026-05-25 17:29 ` Oscar Salvador (SUSE)
  2026-05-26 11:30 ` Usama Arif
  0 siblings, 2 replies; 6+ messages in thread
From: Muchun Song @ 2026-05-22  6:26 UTC (permalink / raw)
  To: Andrew Morton, David Hildenbrand
  Cc: Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Frank van der Linden, linux-mm,
	linux-kernel, stable, Muchun Song, muchun.song

If cma_activate_area() fails after allocating only part of the range
bitmaps, its cleanup path frees the bitmaps for the ranges below
allocrange and then releases reserved pages using the same bound.

That bound is only correct for bitmap freeing. Pages in ranges that did
not reach bitmap allocation are still reserved and should also be
returned to the buddy when CMA_RESERVE_PAGES_ON_ERROR is clear. As a
result, a partial bitmap allocation failure can permanently leak the
reserved pages from the failed range and all later ranges.

Fix this by releasing reserved pages for all ranges. For ranges whose
bitmap allocation succeeded, use the early_pfn[] snapshot saved before
the bitmap pointer overwrote the union field. For later ranges, continue
to use cmr->early_pfn directly.

Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested")
Cc: stable@vger.kernel.org
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
---
 mm/cma.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/cma.c b/mm/cma.c
index c7ca567f4c5c..a30075507d41 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -188,10 +188,13 @@ static void __init cma_activate_area(struct cma *cma)
 
 	/* Expose all pages to the buddy, they are useless for CMA. */
 	if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) {
-		for (r = 0; r < allocrange; r++) {
+		for (r = 0; r < cma->nranges; r++) {
+			unsigned long start_pfn;
+
 			cmr = &cma->ranges[r];
+			start_pfn = r < allocrange ? early_pfn[r] : cmr->early_pfn;
 			end_pfn = cmr->base_pfn + cmr->count;
-			for (pfn = early_pfn[r]; pfn < end_pfn; pfn++)
+			for (pfn = start_pfn; pfn < end_pfn; pfn++)
 				free_reserved_page(pfn_to_page(pfn));
 		}
 	}

base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm/cma: fix reserved page leak on activation failure
  2026-05-22  6:26 [PATCH] mm/cma: fix reserved page leak on activation failure Muchun Song
@ 2026-05-25 17:29 ` Oscar Salvador (SUSE)
  2026-05-26 11:30 ` Usama Arif
  1 sibling, 0 replies; 6+ messages in thread
From: Oscar Salvador (SUSE) @ 2026-05-25 17:29 UTC (permalink / raw)
  To: Muchun Song
  Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
	Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Frank van der Linden, linux-mm,
	linux-kernel, stable, muchun.song

On Fri, May 22, 2026 at 02:26:58PM +0800, Muchun Song wrote:
> If cma_activate_area() fails after allocating only part of the range
> bitmaps, its cleanup path frees the bitmaps for the ranges below
> allocrange and then releases reserved pages using the same bound.
> 
> That bound is only correct for bitmap freeing. Pages in ranges that did
> not reach bitmap allocation are still reserved and should also be
> returned to the buddy when CMA_RESERVE_PAGES_ON_ERROR is clear. As a
> result, a partial bitmap allocation failure can permanently leak the
> reserved pages from the failed range and all later ranges.
> 
> Fix this by releasing reserved pages for all ranges. For ranges whose
> bitmap allocation succeeded, use the early_pfn[] snapshot saved before
> the bitmap pointer overwrote the union field. For later ranges, continue
> to use cmr->early_pfn directly.
> 
> Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>

Reviewed-by: Oscar Salvador (SUSE) <osalvador@kernel.org>


-- 
Oscar Salvador
SUSE Labs

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm/cma: fix reserved page leak on activation failure
  2026-05-22  6:26 [PATCH] mm/cma: fix reserved page leak on activation failure Muchun Song
  2026-05-25 17:29 ` Oscar Salvador (SUSE)
@ 2026-05-26 11:30 ` Usama Arif
  2026-05-26 11:51   ` Oscar Salvador (SUSE)
  1 sibling, 1 reply; 6+ messages in thread
From: Usama Arif @ 2026-05-26 11:30 UTC (permalink / raw)
  To: Muchun Song
  Cc: Usama Arif, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
	Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Frank van der Linden, linux-mm,
	linux-kernel, stable, muchun.song

On Fri, 22 May 2026 14:26:58 +0800 Muchun Song <songmuchun@bytedance.com> wrote:

> If cma_activate_area() fails after allocating only part of the range
> bitmaps, its cleanup path frees the bitmaps for the ranges below
> allocrange and then releases reserved pages using the same bound.
> 
> That bound is only correct for bitmap freeing. Pages in ranges that did
> not reach bitmap allocation are still reserved and should also be
> returned to the buddy when CMA_RESERVE_PAGES_ON_ERROR is clear. As a
> result, a partial bitmap allocation failure can permanently leak the
> reserved pages from the failed range and all later ranges.
> 
> Fix this by releasing reserved pages for all ranges. For ranges whose
> bitmap allocation succeeded, use the early_pfn[] snapshot saved before
> the bitmap pointer overwrote the union field. For later ranges, continue
> to use cmr->early_pfn directly.
> 
> Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> ---
>  mm/cma.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/cma.c b/mm/cma.c
> index c7ca567f4c5c..a30075507d41 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -188,10 +188,13 @@ static void __init cma_activate_area(struct cma *cma)
>  
>  	/* Expose all pages to the buddy, they are useless for CMA. */
>  	if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) {
> -		for (r = 0; r < allocrange; r++) {
> +		for (r = 0; r < cma->nranges; r++) {
> +			unsigned long start_pfn;
> +
>  			cmr = &cma->ranges[r];
> +			start_pfn = r < allocrange ? early_pfn[r] : cmr->early_pfn;

Should this be r <= allocrange?


For the failing range, the loop above did:

		early_pfn[allocrange] = cmr->early_pfn;
		cmr->bitmap = bitmap_zalloc(cma_bitmap_maxno(cma, cmr),
					    GFP_KERNEL);
		if (!cmr->bitmap)
			goto cleanup;


Since cmr->bitmap and cmr->early_pfn share a union, that NULL store
clobbers cmr->early_pfn to 0 for index allocrange.  With r < allocrange
the failing range reads cmr->early_pfn (now 0) and free_reserved_page()
gets called starting from pfn 0

>  			end_pfn = cmr->base_pfn + cmr->count;
> -			for (pfn = early_pfn[r]; pfn < end_pfn; pfn++)
> +			for (pfn = start_pfn; pfn < end_pfn; pfn++)
>  				free_reserved_page(pfn_to_page(pfn));
>  		}
>  	}
> 
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> -- 
> 2.54.0
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm/cma: fix reserved page leak on activation failure
  2026-05-26 11:30 ` Usama Arif
@ 2026-05-26 11:51   ` Oscar Salvador (SUSE)
  2026-05-26 12:44     ` Muchun Song
  0 siblings, 1 reply; 6+ messages in thread
From: Oscar Salvador (SUSE) @ 2026-05-26 11:51 UTC (permalink / raw)
  To: Usama Arif
  Cc: Muchun Song, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
	Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Frank van der Linden, linux-mm,
	linux-kernel, stable, muchun.song

On Tue, May 26, 2026 at 04:30:03AM -0700, Usama Arif wrote:
> On Fri, 22 May 2026 14:26:58 +0800 Muchun Song <songmuchun@bytedance.com> wrote:
...
> > diff --git a/mm/cma.c b/mm/cma.c
> > index c7ca567f4c5c..a30075507d41 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -188,10 +188,13 @@ static void __init cma_activate_area(struct cma *cma)
> >  
> >  	/* Expose all pages to the buddy, they are useless for CMA. */
> >  	if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) {
> > -		for (r = 0; r < allocrange; r++) {
> > +		for (r = 0; r < cma->nranges; r++) {
> > +			unsigned long start_pfn;
> > +
> >  			cmr = &cma->ranges[r];
> > +			start_pfn = r < allocrange ? early_pfn[r] : cmr->early_pfn;
> 
> Should this be r <= allocrange?

Yes, I think you are right. I missed that.

early_pfn[alloc_range] holds the last assignment, so we should start
from the next one reading cmr->early_pfn.

 

-- 
Oscar Salvador
SUSE Labs


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm/cma: fix reserved page leak on activation failure
  2026-05-26 11:51   ` Oscar Salvador (SUSE)
@ 2026-05-26 12:44     ` Muchun Song
  2026-05-26 12:59       ` Usama Arif
  0 siblings, 1 reply; 6+ messages in thread
From: Muchun Song @ 2026-05-26 12:44 UTC (permalink / raw)
  To: Oscar Salvador, Usama Arif
  Cc: Muchun Song, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
	Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Frank van der Linden, linux-mm,
	linux-kernel, stable



> On May 26, 2026, at 19:51, Oscar Salvador (SUSE) <osalvador@kernel.org> wrote:
> 
> On Tue, May 26, 2026 at 04:30:03AM -0700, Usama Arif wrote:
>> On Fri, 22 May 2026 14:26:58 +0800 Muchun Song <songmuchun@bytedance.com> wrote:
> ...
>>> diff --git a/mm/cma.c b/mm/cma.c
>>> index c7ca567f4c5c..a30075507d41 100644
>>> --- a/mm/cma.c
>>> +++ b/mm/cma.c
>>> @@ -188,10 +188,13 @@ static void __init cma_activate_area(struct cma *cma)
>>> 
>>>    /* Expose all pages to the buddy, they are useless for CMA. */
>>>    if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) {
>>> -        for (r = 0; r < allocrange; r++) {
>>> +        for (r = 0; r < cma->nranges; r++) {
>>> +            unsigned long start_pfn;
>>> +
>>>            cmr = &cma->ranges[r];
>>> +            start_pfn = r < allocrange ? early_pfn[r] : cmr->early_pfn;
>> 
>> Should this be r <= allocrange?

Yes. So I sent a v2 to fix it last Saturday.

https://lore.kernel.org/linux-mm/20260523060123.2207992-1-songmuchun@bytedance.com/

Thanks.

> 
> Yes, I think you are right. I missed that.
> 
> early_pfn[alloc_range] holds the last assignment, so we should start
> from the next one reading cmr->early_pfn.
> 
> 
> 
> --
> Oscar Salvador
> SUSE Labs

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm/cma: fix reserved page leak on activation failure
  2026-05-26 12:44     ` Muchun Song
@ 2026-05-26 12:59       ` Usama Arif
  0 siblings, 0 replies; 6+ messages in thread
From: Usama Arif @ 2026-05-26 12:59 UTC (permalink / raw)
  To: Muchun Song, Oscar Salvador
  Cc: Muchun Song, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
	Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Frank van der Linden, linux-mm,
	linux-kernel, stable



On 26/05/2026 13:44, Muchun Song wrote:
> 
> 
>> On May 26, 2026, at 19:51, Oscar Salvador (SUSE) <osalvador@kernel.org> wrote:
>>
>> On Tue, May 26, 2026 at 04:30:03AM -0700, Usama Arif wrote:
>>> On Fri, 22 May 2026 14:26:58 +0800 Muchun Song <songmuchun@bytedance.com> wrote:
>> ...
>>>> diff --git a/mm/cma.c b/mm/cma.c
>>>> index c7ca567f4c5c..a30075507d41 100644
>>>> --- a/mm/cma.c
>>>> +++ b/mm/cma.c
>>>> @@ -188,10 +188,13 @@ static void __init cma_activate_area(struct cma *cma)
>>>>
>>>>    /* Expose all pages to the buddy, they are useless for CMA. */
>>>>    if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) {
>>>> -        for (r = 0; r < allocrange; r++) {
>>>> +        for (r = 0; r < cma->nranges; r++) {
>>>> +            unsigned long start_pfn;
>>>> +
>>>>            cmr = &cma->ranges[r];
>>>> +            start_pfn = r < allocrange ? early_pfn[r] : cmr->early_pfn;
>>>
>>> Should this be r <= allocrange?
> 
> Yes. So I sent a v2 to fix it last Saturday.
> 
> https://lore.kernel.org/linux-mm/20260523060123.2207992-1-songmuchun@bytedance.com/
> 
> Thanks.

Ah still catching up on the mailing list. Thanks!

> 
>>
>> Yes, I think you are right. I missed that.
>>
>> early_pfn[alloc_range] holds the last assignment, so we should start
>> from the next one reading cmr->early_pfn.
>>
>>
>>
>> --
>> Oscar Salvador
>> SUSE Labs



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-05-26 12:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-22  6:26 [PATCH] mm/cma: fix reserved page leak on activation failure Muchun Song
2026-05-25 17:29 ` Oscar Salvador (SUSE)
2026-05-26 11:30 ` Usama Arif
2026-05-26 11:51   ` Oscar Salvador (SUSE)
2026-05-26 12:44     ` Muchun Song
2026-05-26 12:59       ` Usama Arif

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.