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:	Mon, 23 Feb 2009 18:15:51 +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 Nick Kossifidis <mickflemm@...il.com>:
> 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 ?
>

Typo alert...
rs->rs_more = !!(rx_status->rx_status_0 & AR5K_5212_RX_DESC_STATUS0_MORE);


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