linux-kernel - Re: [PATCH 2/4] x86/platform/UV: Fix problem with bad UV4 EFI System Table causing panic

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e15604ce-ba48-d589-19f3-ef5380282aca@sgi.com>
Date:	Fri, 29 Jul 2016 09:31:52 -0700
From:	Mike Travis <travis@....com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dimitri Sivanich <sivanich@....com>,
	Russ Anderson <rja@....com>,
	John Estabrook <estabrook@....com>,
	Andrew Banman <abanman@....com>,
	Nathan Zimmer <nzimmer@....com>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>,
	Alex Thorlton <athorlton@....com>
Subject: Re: [PATCH 2/4] x86/platform/UV: Fix problem with bad UV4 EFI System
 Table causing panic



On 7/29/2016 4:17 AM, Thomas Gleixner wrote:
> On Wed, 27 Jul 2016, Mike Travis wrote:
> 
>> Fix a problem that occurs if for some reason the UV4 EFI System Table
>> is not available, the check inadvertently can cause a panic.
>>
>> Reviewed-by: Dimitri Sivanich <sivanich@....com>
>> Reviewed-by: Nathan Zimmer <nzimmer@....com>
>> Tested-by: Frank Ramsay <framsay@....com>
>> Tested-by: John Estabrook <estabrook@....com>
>> Signed-off-by: Mike Travis <travis@....com>
>> ---
>>  arch/x86/platform/uv/bios_uv.c |    7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> --- linux-3.12.orig/arch/x86/platform/uv/bios_uv.c
>> +++ linux-3.12/arch/x86/platform/uv/bios_uv.c
>> @@ -201,11 +201,12 @@ void uv_bios_init(void)
>>  	}
>>  
>>  	if (uv_systab->revision >= UV_SYSTAB_VERSION_UV4) {
>> +		int size = uv_systab->size;
>> +
>>  		iounmap(uv_systab);
>> -		uv_systab = ioremap(efi.uv_systab, uv_systab->size);
> 
> I think the changelog is bogus. What's happening here is a classic use after
> unmap, which you avoid by this change.
> 
>> +		uv_systab = ioremap(efi.uv_systab, size);
> 
> Hmm?
> 
> 	tglx
> 

You might be right, I'm not very familiar with the EFI transitions
between physical and virtual addresses.  I do know that it worked
until the later kernels and the EFI changes that have occurred.
Another engineer here (athorlton) is working that problem and he
is the one that discovered this snafu.

But yes, the original code was incorrect in any case.

Thanks,
Mike