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:	Fri, 6 Mar 2009 09:42:49 +0000
From:	Sitsofe Wheeler <sitsofe@...oo.com>
To:	Bob Copeland <me@...copeland.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 Wed, Mar 04, 2009 at 07:07:59AM -0500, Bob Copeland wrote:
> On Tue, Mar 03, 2009 at 08:03:52PM +0000, Sitsofe Wheeler wrote:
> 
> None.  Perhaps it's wishful thinking but a function trace for the few
> minutes prior to the poison would be useful.  A good replicator might
> be to run a sequence of automatic suspend/resume with pm_test, in 
> 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.

Forcing the scans and pings didn't seem to make the issue occur.
Unfortunately I can't quite provide you what you were asking for...  I
started the function_tracer feature in /sys/kernel/debug/tracing and put
the buffer size to 153600kb (previously I had set it higher and
successfully OOMd my box : ). Unfortunately I had no filter so this was
not enough for all that long of a log (maybe about 6 seconds). I had a
small script that did the following:

watch -n1 'if `tail -1000 /var/log/kern.log | grep -q Poison`; then echo
0 > /sys/kernel/debug/tracing/tracing_on; cat
/sys/kernel/debug/tracing/trace | gzip > /tmp/trace.txt.gz ; fi'

(the script is obviously flawed but it did the job)

I've put up results on http://sucs.org/~sits/test/eeepc-debug/20090306/
and I think the type that kmalloc notices is 4154504125.579778 . There
is also a pre grepped log of (ieee|ath5k) in that directory.

I'll try and act on your filtering suggestions next time but I didn't
have too much time to get this going...

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