linux-kernel - Re: 2.6.25-git2: BUG: unable to handle kernel paging request at ffffffffffffffff

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:	Wed, 23 Apr 2008 19:58:50 +0300
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Zdenek Kabelac" <zdenek.kabelac@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>, "Jiri Slaby" <jirislaby@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, paulmck@...ux.vnet.ibm.com,
	"David Miller" <davem@...emloft.net>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
	"Christoph Lameter" <clameter@....com>
Subject: Re: 2.6.25-git2: BUG: unable to handle kernel paging request at ffffffffffffffff

On Wed, Apr 23, 2008 at 6:53 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>    Padding 0xffff8100201a0000:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>    ....
>    Padding 0xffff8100201a71a0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkkҐ
>    Padding 0xffff8100201a71b0:  cc cc cc cc cc cc cc cc 00 00 1a 20 00 81 ff ff ММММММММ......яя
>    Padding 0xffff8100201a71c0:  cd 70 17 a0 ff ff ff ff 00 00 00 00 73 05 00 00 Нp..яяяя....s...
>    Padding 0xffff8100201a71d0:  b6 54 58 00 01 00 00 00 d5 71 26 81 ff ff ff ff ¶TX.....Хq&.яяяя
>
>    Padding 0xffff8100201a71e0:  00 00 00 00 7c 05 00 00 97 54 58 00 01 00 00 00 ....|....TX.....
>
>    which in turn is interesting because it very much looks like SLUB
>    re-used a page for something else (the values that things got
>    overwritten by are largely SLUB's own poison bytes: 6b is POISON_FREE,
>    the a5 at the end of the list of 6b's is POISON_END, while cc is
>    SLUB_RED_ACTIVE).
>
>  To me, that pattern looks like an order-3 allocation (correct: that's what
>  kmalloc-4096 is supposed to be using!) got released, and the stuff at the
>  end (with slub debugging, there's only room for 7 4096-byte allocations
>  there, so 71b0 is past the end) in that SLUB debug info.
>
>  The first word of that busy allocation is ffff8100201a0000, which is also
>  the base pointer to the whole order-3 page ("Free pointer"), followed by
>  the SLAB tracking data.

Is the POISON_FREE ("6b") region really contiguous Zdenek? The problem
here is that the object looks to be 29104 bytes that is subject to
kmalloc_large() which by-passes SLUB poisoning completely.

                        Pekka