linux-kernel - Re: kmemcheck: Caught 32-bit read from uninitialized memory (f6038ec0)

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: <19f34abd0810050542k607221acs526b38aaba36b501@mail.gmail.com>
Date:	Sun, 5 Oct 2008 14:42:35 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Pekka Enberg" <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: kmemcheck: Caught 32-bit read from uninitialized memory (f6038ec0)

On Mon, Sep 29, 2008 at 3:14 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> another crash is below - config attached.
>
>        Ingo
>
> ----------------->
> initcall 0xc08eabf0 returned 0 after 7 msecs
> calling  0xc08eae70 @ 1
> PnPBIOS: Scanning system for PnP BIOS support...
> PnPBIOS: Found PnP BIOS installation structure at 0xc00fc550
> PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc580, dseg 0xf0000
> BUG: unable to handle kernel paging request at 0000c6ef

Thanks, I can reproduce it. And that's very interesting. Look at the
faulting address and the line just above:

    PnP BIOS version 1.0, entry 0xf0000:0xc580

When I run it, I get something similar:

    PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x67ba, dseg 0xf0000
    BUG: unable to handle kernel paging request at 000068ac

Enabling debug information also gives me the location of the crash. It
happens in kmemcheck's opcode decoder, when we dereference regs->eip.
Is it possible that PnPBIOS is executing some code which is located at
these weird addresses (like 16-bit code) and requires a different
segment register?

Maybe we should just check regs->flags to make sure that we are not in
VM86 mode or similar. Will experiment a bit with it. Thanks.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/