Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Egorenkov <egorenar@linux.ibm.com>
To: kexec@lists.infradead.org
Subject: [PATCH v2 1/1] check that order of free pages falls within valid range
Date: Fri, 08 Apr 2022 15:32:20 +0200	[thread overview]
Message-ID: <87bkxbg0pn.fsf@oc8242746057.ibm.com> (raw)
In-Reply-To: <20220408085259.184465-1-egorenar@linux.ibm.com>

Alexander Egorenkov <egorenar@linux.ibm.com> writes:

> This change makes __exclude_unnecessary_pages() more robust by
> verifying that the order of a free page is valid before computing the size
> of its memory block in the buddy system.
>
> The order of a free page cannot be larger than (MAX_ORDER - 1) because
> the array 'zone.free_area' is of size MAX_ORDER.
>
> This situation is reproducible with some s390x dumps:
>
> __exclude_unnecessary_pages: Invalid free page order: pfn=2690c0, order=52, max order=8
>
> References:
> - https://listman.redhat.com/archives/crash-utility/2021-September/009204.html
> - https://www.kernel.org/doc/gorman/html/understand/understand009.html
>
> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
> ---
>  makedumpfile.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/makedumpfile.c b/makedumpfile.c
> index 2ef345879524..56aa026e7b34 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -6457,6 +6457,12 @@ __exclude_unnecessary_pages(unsigned long mem_map,
>  		else if ((info->dump_level & DL_EXCLUDE_FREE)
>  		    && info->page_is_buddy
>  		    && info->page_is_buddy(flags, _mapcount, private, _count)) {
> +			if (private >= ARRAY_LENGTH(zone.free_area)) {
> +				ERRMSG("Invalid free page order: pfn=%llx, order=%lu, max order=%lu\n",
> +				       pfn, private, ARRAY_LENGTH(zone.free_area) - 1);
> +				free(page_cache);
> +				return FALSE;
> +			}
>  			nr_pages = 1 << private;
>  			pfn_counter = &pfn_free;
>  		}
> -- 
> 2.34.1
>
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

I found out when this can happen.

If e.g. a driver calls free_pages() and gives an order > max page order,
then __free_one_page() stores the given invalid page order in the
'private' member of struct page and gives it back to the buddy
allocator.

This is what actually happened in the dump i used to reproduce this issue
with makedumpfile.

Regards
Alex
 


  reply	other threads:[~2022-04-08 13:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08  8:52 [PATCH v2 1/1] check that order of free pages falls within valid range Alexander Egorenkov
2022-04-08 13:32 ` Alexander Egorenkov [this message]
2022-04-11  1:53   ` HAGIO KAZUHITO =?unknown-8bit?b?6JCp5bC+IOS4gOS7gQ==?=
2022-04-11  5:33     ` Alexander Egorenkov
2022-04-11  6:11       ` HAGIO KAZUHITO =?unknown-8bit?b?6JCp5bC+IOS4gOS7gQ==?=

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkxbg0pn.fsf@oc8242746057.ibm.com \
    --to=egorenar@linux.ibm.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox