linux-kernel - Re: [slab corruption] BUG key

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: <19f34abd0901171337p31b85393ifbc563a84e56d7e9@mail.gmail.com>
Date:	Sat, 17 Jan 2009 22:37:30 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"David Howells" <dhowells@...hat.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Michael LeMay" <mdlemay@...ch.ncsc.mil>,
	"James Morris" <jmorris@...ei.org>,
	"Stephen Smalley" <sds@...ho.nsa.gov>,
	"Paul Moore" <paul.moore@...com>, "Eric Paris" <eparis@...hat.com>
Subject: Re: [slab corruption] BUG key_jar: Poison overwritten

On Sat, Jan 17, 2009 at 9:33 PM, David Howells <dhowells@...hat.com> wrote:
> Ingo Molnar <mingo@...e.hu> wrote:
>
>> The problem was not reproducible - i tried the same config once more and
>> it didnt produce the bug. (this system has no known hardware flukes)
>
> Having thought about it some more, we can't necessarily pin the blame on the
> key management code.  I think it more likely due to the previous owner of the
> page as it's the guard poisoning that got corrupted, not the allocated key
> struct.  The problem is we don't know who that was.  I wonder if it's
> practical to store a recent history of page allocs and releases in a circular
> buffer.

This is what I think:

[   44.482064] INFO: 0xf5f320c0-0xf5f320c0. First byte 0x6a instead of 0x6b
...
[   44.482064]   Object 0xf5f320c0:  6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk

Only the first byte has been changed. It changed from 0x6b to 0x6a.
Smells like a decrement. And yes, this particular cache allocates
'struct key's, which has an 'atomic_t usage' as its first member. So a
refcounting bug, most likely (key_put() was called too many times). Or
a missing key_get() somewhere?

It also seems noteworthy that no other data has been changed since the
last key_put() (i.e. since the refcount hit zero).

[   44.482064] Bytes b4 0xf5f320b0:  7c 05 ff ff 5a 5a 5a 5a 5a 5a 5a
5a 5a 5a 5a 5a |.��ZZZZZZZZZZZZ

...I guess "bytes b4" means "bytes before"?


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