[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190902093534.GB9605@zn.tnic>
Date: Mon, 2 Sep 2019 11:35:34 +0200
From: Borislav Petkov <bp@...en8.de>
To: Zhenzhong Duan <zhenzhong.duan@...cle.com>
Cc: linux-kernel@...r.kernel.org,
"Kirill A. Shutemov" <kirill@...temov.name>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86-ml <x86@...nel.org>
Subject: Re: [PATCH] x86/boot/compressed/64: Fix 'may be used uninitialized'
issue
On Mon, Sep 02, 2019 at 05:30:24PM +0800, Zhenzhong Duan wrote:
> Builds kernel with "make bzImage EXTRA_CFLAGS=-Wall", gcc complains:
>
> arch/x86/boot/compressed/pgtable_64.c: In function 'paging_prepare':
> arch/x86/boot/compressed/pgtable_64.c:92:7: warning: 'new' may be used uninitialized in this function [-Wmaybe-uninitialized]
> new = round_down(new, PAGE_SIZE);
>
> In theory a random value of variable new may pass all the check and be
> assigned to bios_start, fixing it by assigning it an initial value.
>
> Fixes: 0a46fff2f910 ("x86/boot/compressed/64: Fix boot on machines with broken E820 table")
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@...cle.com>
> Cc: Kirill A. Shutemov <kirill@...temov.name>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: x86-ml <x86@...nel.org>
> ---
> arch/x86/boot/compressed/pgtable_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/boot/compressed/pgtable_64.c b/arch/x86/boot/compressed/pgtable_64.c
> index 2faddeb..c886269 100644
> --- a/arch/x86/boot/compressed/pgtable_64.c
> +++ b/arch/x86/boot/compressed/pgtable_64.c
> @@ -72,7 +72,7 @@ static unsigned long find_trampoline_placement(void)
>
> /* Find the first usable memory region under bios_start. */
> for (i = boot_params->e820_entries - 1; i >= 0; i--) {
> - unsigned long new;
> + unsigned long new = bios_start;
>
> entry = &boot_params->e820_table[i];
>
> --
https://git.kernel.org/tip/c96e8483cb2da6695c8b8d0896fe7ae272a07b54
In the future, use tip/master when preparing fixes because it has the
latest state of the x86 tree and you won't have to duplicate effort,
like in this case.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists