linux-kernel - Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb

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:	Sun, 22 Feb 2009 20:18:22 +0000
From:	Sitsofe Wheeler <sitsofe@...oo.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Jiri Slaby <jirislaby@...il.com>, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org, ath5k-devel@...ema.h4ckr.net,
	Nick Kossifidis <mickflemm@...il.com>,
	"Luis R. Rodriguez" <lrodriguez@...eros.com>,
	Bob Copeland <me@...copeland.com>
Subject: Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)

On Sun, Feb 22, 2009 at 08:42:37PM +0100, Frederic Weisbecker wrote:
> On Sun, Feb 22, 2009 at 08:27:38PM +0100, Jiri Slaby wrote:
> > On 22.2.2009 18:10, Frederic Weisbecker wrote:
> >> I have some troubles with kmemcheck, so I give up for now.
> >> Well, by reading the kmemcheck documentation, it tells that there can be some false
> >> positives so...
> >
> > This has nothing to do with kmemcheck.
> >
> >> Since we are not sure this is a real bug, I'm not sure it would be interesting.
> >
> > There is no false positive possibility with these checkers, so this is  
> > pretty much interesting, because it is a bug.
> 
> 
> If so, Documentation/kmemcheck.txt really needs an update.

kmemcheck is different to the slab object lifetime debugger (which is
what reported this error). kmemcheck may have turned up in the trace
because it was compiled in (and it ties into slab/slub) but wasn't
turned on (it can be dynamically toggled via sysfs).

kmemcheck keeps a shadow of the memory and via the shadow memory it
records whether the memory has been written to yet. I believe
kmemcheck's problem is that it can't know when allocated but
uninitialised memory is being used on purpose/not really being used
(e.g. when gcc does a 32 bit read when only 16 bits have been used but
throws the upper 16 bits away). There may be other cases such as when a
previously uninitialised buffer is used but the buffer is actually used
by an mmaped device...

My understanding is that the slab debugger writes poison about the place
(e.g. to memory that has been freed and at the start/end of allocations)
and then checks to see if someone has scribbled on it. This case is more
coarse as it only deals with allocation rather than initialisation (and
if you scribble the same value as the poison pattern you go undetected)
but I believe this is what Jiri is referring to as a "no false positive
possibility" case - it's never right to write to unallocated memory.

(fixed up Bob's email address on the cc)

-- 
Sitsofe | http://sucs.org/~sits/
--
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/