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]

Message-ID: <20090308030928.GB14966@hash.localnet>
Date:	Sat, 7 Mar 2009 22:09:28 -0500
From:	Bob Copeland <me@...copeland.com>
To:	Sitsofe Wheeler <sitsofe@...oo.com>
Cc:	Jiri Slaby <jirislaby@...il.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 Fri, Mar 06, 2009 at 09:42:49AM +0000, Sitsofe Wheeler wrote:
> > parallel with iwlist wlan0 scan (as root, so scans are actually 
> > performed), in parallel with iperf or ping.  I didn't personally have
> > luck with that workload, though.

So I looked through this log for a few hours today.  Sorry to say
that I don't have any answers, but here's a summary of what I saw:

- it didn't seem like there were any obvious race conditions at play;
  that is, I didn't see other ath5k_XXX functions being pre-empted
  by ath5k_intr, followed by the softirq.

- there were a few errors prior to catching the poison.  I don't think
  the trace contains enough info to say whether they were phy errors,
  unsupported jumbo type errors, or whatever.  Anyway there didn't seem
  to be any obvious causal pattern, nothing like an error on the
  40th previous buffer or a cascading series of errors.  Of course, 
  the error could have happened much earlier compared to when the skbuff
  in the freelist got reused.

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.

Jiri, I really think we should implement that better check for the
self linked descriptor using the rxdp register.  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?)...  If you want I'll cook up a patch for 
that too.

-- 
Bob Copeland %% www.bobcopeland.com

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