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: <20090223152724.M82409@bobcopeland.com>
Date:	Mon, 23 Feb 2009 10:35:02 -0500
From:	"Bob Copeland" <me@...copeland.com>
To:	Jiri Slaby <jirislaby@...il.com>,
	Sitsofe Wheeler <sitsofe@...oo.com>
Cc:	Frederic Weisbecker <fweisbec@...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>
Subject: Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)

On Mon, 23 Feb 2009 00:20:50 +0100, Jiri Slaby wrote
> On 22.2.2009 22:56, Jiri Slaby wrote:
> > Well, maybe we should try to reproduce with jumbo packets sent to the
> > ath5k receiver, since I think it (1) is not very much test-covered code
> > (2) appears to be related.
> 
> According to the spec I have for older chip, there is not `done' flag 
> set for descriptors which have `more' flag set. We handle this wrongly. 
> Am I looking correctly, Nick, Luis, Bob?
> 
> I still don't see what could have caused this though.

As I understand it, yes, we don't do the right thing when the more flag
is set.  We're supposed to keep processing packets until we get one with
the done flag, and then all of that is supposed to be merged into a single
packet.  Other flags such as the rx rate are only valid on the final
packet.

However, I did some debugging of this a while ago and concluded that the
'jumbo' frames were largely garbage data.  The dma buffer size is certainly
large enough for a standard 802.11 frame and the 'more' flag is only
supposed to be set if the dma buffer size is too small for a packet.  In
all cases the dma buffer size was 2500+ bytes and the actual contents of
the packets looked like random values (I did have encryption turned on,
but there were no 802.11 headers I could see.)

So I am not sure if the jumbo packets are causing bad things to happen,
or if they are an indication that something bad has already happened.

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