linux-kernel - Re: [PATCH 1/3] mm/page_alloc: correct start page when guard page debug is enabled

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: <35c924a8-1232-a460-6a25-43827c6d6ef8@huaweicloud.com>
Date:   Fri, 11 Aug 2023 11:13:16 +0800
From:   Kemeng Shi <shikemeng@...weicloud.com>
To:     David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        baolin.wang@...ux.alibaba.com, mgorman@...hsingularity.net,
        willy@...radead.org
Subject: Re: [PATCH 1/3] mm/page_alloc: correct start page when guard page
 debug is enabled



on 8/10/2023 5:10 PM, David Hildenbrand wrote:
> On 10.08.23 11:53, Kemeng Shi wrote:
>> When guard page debug is enabled and set_page_guard returns success, we miss
>> to forward page to point to start of next split range and we will do split
>> unexpectedly in page range without target page. Move start page update
>> before set_page_guard to fix this.
>>
>> Signed-off-by: Kemeng Shi <shikemeng@...weicloud.com>
>> ---
>>   mm/page_alloc.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 96b7c1a7d1f2..fd93d1396ccd 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -6557,6 +6557,7 @@ static void break_down_buddy_pages(struct zone *zone, struct page *page,
>>               next_page = page;
>>               current_buddy = page + size;
>>           }
>> +        page = next_page;
>>             if (set_page_guard(zone, current_buddy, high, migratetype))
>>               continue;
>> @@ -6564,7 +6565,6 @@ static void break_down_buddy_pages(struct zone *zone, struct page *page,
>>           if (current_buddy != target) {
>>               add_to_free_list(current_buddy, zone, high, migratetype);
>>               set_buddy_order(current_buddy, high);
>> -            page = next_page;
>>           }
>>       }
>>   }
> 
> Is this worth a Fixes: tag?
> 
Sure, I will add this in next version.
> What is the user-visible result?
> 
As we split to wrong target page, then splited pages are not able to merge
back to originial order when target page is put back and splited pages except
target page is not usable. To be specific:

Consider target page is the third page in buddy page with order 2.
| buddy-2 | Page | Target | Page |

After break down to target page, we will only set first page to Guard
because of bug.
| Guard   | Page | Target | Page |

When we try put_page_back_buddy with target page, the buddy page of target
if neither guard nor buddy, Then it's not able to construct original page
with order 2
| Guard | Page | buddy-0 | Page |

All pages except target page is not in free list and is not usable.