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: <40f31dec0902230803qcbd4c20kc66a50e6e2e8eef2@mail.gmail.com>
Date:	Mon, 23 Feb 2009 18:03:16 +0200
From:	Nick Kossifidis <mickflemm@...il.com>
To:	Bob Copeland <me@...copeland.com>
Cc:	Jiri Slaby <jirislaby@...il.com>,
	Sitsofe Wheeler <sitsofe@...oo.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)

2009/2/23 Bob Copeland <me@...copeland.com>:
> 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.
>

Hmm can someone test ath5k against an Atheros AP using fast frames ?
Maybe they are jumbo frames but they don't have any header etc so that
they look like one frame after un-fragmentation, documentation says
that the current frame is continued in the next descriptor if more is
set to 1 so i guess next buffer might not have the header. If more = 0
then it's our last descriptor and only then other fields such as done,
frame receive ok, rssi etc are valid.

The fact that they are not reported as PHY error packets makes me
wonder why would we have garbage data on our rx buffer. How about the
FRAME_RECEIVE_OK or CRC_ERROR flags (also valid for the last
descriptor) ? Are they set or not ?

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
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/