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 21:30:39 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Sitsofe Wheeler <sitsofe@...oo.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:18:22PM +0000, Sitsofe Wheeler wrote:
> 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).


Ah sorry, I thought it was a kmemcheck warning. That's why I didn't understand
what Jiri said to me.

 
> 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...


Ok.

> 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)


Well I understand better now. Thanks for the explanations.
 
> -- 
> 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/