linux-kernel - Re: 3.10.0 i386 uniprocessor 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 19 Jul 2013 15:25:13 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	George Spelvin <linux@...izon.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: 3.10.0 i386 uniprocessor panic

On 07/19/2013 02:00 PM, George Spelvin wrote:
>>> EIP is at 0xc143a091
>>> EAX: c143a090 EBX: 00000100 ECX: f3150000 EDX: c143a090
>>> ESI: c143a090 EDI: c143a090 EBP: c143a090 ESP: f3151eec
>>>  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>>> CR0: 80050033 CR2: a090c143 CR3: 331c6000 CR4: 000007d0
>>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>>> DR6: ffff0ff0 DR7: 00000400
> 
>>> (The CR2 value looks particularly odd.)
> 
>> Indeed it does; it is a user space value, but it doesn't look like
>> either a normal user space value nor really as a trivially buggered-up
>> kernel pointer value, unless the 0xc143... at the bottom is the upper
>> half of a kernel pointer, in which case we probably obtained this value
>> from a corrupt, misaligned pointer.
> 
> Er... I assumed you'd see instantly that it was the 0xc143a090 value
> that's in 5 registers (EAX/EDX/ESI/EDI/EBP), and IP-1, but with the
> halves swapped.

That would have requiring me to actually pay attention.  I claim
undercaffeination.

> How the heck the halves got swapped is confusing me...

Disassembling the "code" (which is really data) makes it kind of obvious:

C143A090  90                nop
C143A091  A043C190A0        mov al,[0xa090c143]	 ; fault here

We jumped into data which contained a series of self-pointers
(presumably empty double-linked lists), and the first two bytes became
opcodes...

Unfortunately the disassembly of call_timer_fn.isra.37 doesn't really
tell us anything other than that the passed-in value of %eax was bogus.
 It is *very* interesting, though, that that value is present in so many
registers (in fact, the ONLY GPRs which didn't have that value are %ebx
and %ecx, which are set by that function itself.)

A disassembly of the calling function, i.e.:

 [<c1024524>] ? run_timer_softirq+0x150/0x165

... would be a good idea, at least.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/