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

On 8.3.2009 04:09, Bob Copeland wrote:
> At this point, I guess the best way forward is to have a special debug
> patch for when we pass an skb up the stack, when it gets allocated, and
> what is in the descriptors.

Yes, I have been thinking about some (ring buffer) array which would 
store address-desc_status pairs (even few megs in a vmalloc area) and 
pointer (not modulo-ed counter) to this array (index would be modulo-ed, 
indeed). From poison output we know the address, so we can then instruct 
ath5k to dump the buffer and see what happens :), what was in the status 
when we freed the skb.

Maybe some additional info may be needed, as you suggest.

> Jiri, I really think we should implement that better check for the
> self linked descriptor using the rxdp register.

As I stated a while ago, definitely!

> bf_last is no longer a
> valid marker for the self-linked descriptor at the end of the loop since
> we re-add the just-processed descriptor every time through the loop
> (or am I missing something?)...

Why? bf_last is snapshotted before the loop. And when we see this bf 
while processing, we stop. In the next round we check if bf->next is 
done. If yes, we move on.

> If you want I'll cook up a patch for that too.

If you like, feel free to kick it off. Remember to remove bf->flags 
completely, so that we save another bunch of memory ;).
--
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/