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=SHY9gF49zyoECNV3favjS8Q6-9eWnQwNKX2EM@mail.gmail.com>
Date:	Thu, 17 Feb 2011 12:18:04 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Michal Hocko <mhocko@...e.cz>, Ingo Molnar <mingo@...e.hu>,
	linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
	Octavian Purdila <opurdila@...acom.com>,
	David Miller <davem@...emloft.net>
Subject: Re: BUG: Bad page map in process udevd (anon_vma: (null)) in 2.6.38-rc4

On Thu, Feb 17, 2011 at 9:07 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> [ Btw, that also shows another problem: "list_move()" doesn't trigger
> the debugging checks when it does the __list_del(). So
> CONFIG_DEBUG_LIST would never have caught the fact that the
> "list_move()" was done on a list-entry that didn't have valid list
> pointers any more. ]

Ok, so does this patch change things? IOW, if you enable
CONFIG_DEBUG_LIST, this patch should hopefully make the error case of
using "list_move()" on a stale and re-used entry trigger an error
printout.

NOTE! Even if the list is some stale entry on the stack, if nothing
has overwritten that stack entry, no amount of list debugging will
notice this. So you still need to hit the problem. But now the kernel
should print stuff out even if the page got re-allocated to something
else than a page table, so _if_ the problem is a list_move() or
similar, we don't need to hit quite the same very special case. If it
corrupts user space pages or some other random memory, it will still
complain (instead of just resulting in a SIGSEGV or whatever)

Of course, there is absolutely no guarantee that it's actually
"list_move()" at all.

And as usual, the patch is TOTALLY UNTESTED.

                                 Linus

View attachment "patch.diff" of type "text/x-patch" (3431 bytes)