linux-kernel - Re: BUG: Bad page map in process udevd (anon

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]

Message-ID: <AANLkTi=xnbcs5BKj3cNE_aLtBO7W5m+2uaUacu7M8g_S@mail.gmail.com>
Date:	Wed, 16 Feb 2011 12:09:35 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: BUG: Bad page map in process udevd (anon_vma: (null)) in 2.6.38-rc4

On Wed, Feb 16, 2011 at 11:50 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Yup, goodie. It does look like it might be exactly the same thing,
> except now the offset seems to be 0x1e68 instead of 0x1768.

It was 0x1748 in Eric's case. Background for Michal:

  http://lkml.org/lkml/2011/2/14/223

Michal - if you can re-create this, it would be wonderful if you can
enable CONFIG_DEBUG_PAGEALLOC. I didn't find any obvious candidates
yet.

Also, what is a bit surprising is that the x86-32 offset is bigger
than the x86-64 one. Normally the x86-64 structures are much bigger
due to the obvious 64-bit fields.

I wonder if it's something counting backwards from the top. IOW, it
could be a "list_init()" on the kernel stack (which is 8kB - see
THREAD_ORDER) after the stack has been released. That would explain
why the offset is bigger on x86-32, because it's simply closer to the
top-of-stack.

The other possibility is that the offset is much smaller on x86, and
is just 0xe68 (with just one pte error, it's hard to tell how many
significant bits there are - there's no pattern as in Eric's case).

That said, neither 0x1e68 nor 0xe68 seems to be in the main vmlinux
file. But I haven't checked modules yet.

                        Linus
--
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/