linux-toradex.git/net/mac80211, branch v2.6.30.2

mac80211: fix minstrel single-rate memory corruption

2009-07-02T23:50:07+00:00

commit 5ee58d7e6ad019675b4090582aec4fa1180d8703 upstream.

The minstrel rate controller periodically looks up rate indexes in
a sampling table.  When accessing a specific row and column, minstrel
correctly does a bounds check which, on the surface, appears to handle
the case where mi->n_rates < 2.  However, mi->sample_idx is actually
defined as an unsigned, so the right hand side is taken to be a huge
positive number when negative, and the check will always fail.

Consequently, the RC will overrun the array and cause random memory
corruption when communicating with a peer that has only a single rate.
The max value of mi->sample_idx is around 25 so casting to int should
have no ill effects.

Without the change, uptime is a few minutes under load with an AP
that has a single hard-coded rate, and both the AP and STA could
potentially crash.  With the change, both lasted 12 hours with a
steady load.

Thanks to Ognjen Maric for providing the single-rate clue so I could
reproduce this.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=12490 on the
regression list (also http://bugzilla.kernel.org/show_bug.cgi?id=13000).

Reported-by: Sergey S. Kostyliov 
Reported-by: Ognjen Maric 
Signed-off-by: Bob Copeland 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: avoid NULL ptr deref when finding max_rates in PID and minstrel

2009-05-11T19:07:01+00:00

"There is another problem with this piece of code. The sband will be NULL
after second iteration on single band device and cause null pointer
dereference. Everything is working with dual band card. Sorry, but i
don't know how to explain this clearly in English. I have looked on the
second patch for pid algorithm and found similar bug."

Reported-by: Karol Szuster 
Signed-off-by: John W. Linville

mac80211: pid, fix memory corruption

2009-05-04T20:22:16+00:00

pid doesn't count with some band having more bitrates than the one
associated the first time.
Fix that by counting the maximal available bitrate count and allocate
big enough space.

Secondly, fix touching uninitialized memory which causes panics.
Index sucked from this random memory points to the hell.
The fix is to sort the rates on each band change.

Signed-off-by: Jiri Slaby 
Signed-off-by: John W. Linville

mac80211: minstrel, fix memory corruption

2009-05-04T20:22:15+00:00

minstrel doesn't count max rate count in fact, since it doesn't use
a loop variable `i' and hence allocs space only for bitrates found in
the first band.

Fix it by involving the `i' as an index so that it traverses all the
bands now and finds the real max bitrate count.

Signed-off-by: Jiri Slaby 
Cc: Felix Fietkau 
Signed-off-by: John W. Linville

mac80211: correct fragmentation threshold check

2009-05-04T20:22:08+00:00

The fragmentation threshold is defined to be including the
FCS, and the code that sets the TX_FRAGMENTED flag correctly
accounts for those four bytes. The code that verifies this
doesn't though, which could lead to spurious warnings and
frames being dropped although everything is ok. Correct the
code by accounting for the FCS.

(JWL -- The problem is described here:
 http://article.gmane.org/gmane.linux.kernel.wireless.general/32205 )

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: default to automatic power control

2009-04-29T20:48:33+00:00

In "mac80211: correct wext transmit power handler"
I fixed the wext handler, but forgot to make the default of the
user_power_level -1 (aka "auto"), so that now the transmit power
is always set to 0, causing associations to time out and similar
problems since we're transmitting with very little power. Correct
this by correcting the default user_power_level to -1.

Signed-off-by: Johannes Berg 
Bisected-by: Niel Lambrechts 
Signed-off-by: John W. Linville

mac80211: fix modprobe deadlock by not calling wep_init under rtnl_lock

2009-04-29T20:48:33+00:00

- ieee80211_wep_init(), which is called with rtnl_lock held, blocks in
   request_module() [waiting for modprobe to load a crypto module].

 - modprobe blocks in a call to flush_workqueue(), when it closes a TTY
   [presumably when it exits].

 - The workqueue item linkwatch_event() blocks on rtnl_lock.

There's no reason for wep_init() to be called with rtnl_lock held, so
just move it outside the critical section.

Signed-off-by: Alan Jenkins 
Signed-off-by: John W. Linville

mac80211: fix alignment calculation bug

2009-04-21T20:43:33+00:00

When checking whether or not a given frame needs to be
moved to be properly aligned to a 4-byte boundary, we
use & 4 which wasn't intended, this code should check
the lowest two bits.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: do not print WARN if config interface

2009-04-21T20:43:32+00:00

It is expected that config interface will always succeed as mac80211
will only request what driver supports. The exception here is when a
device has rfkill enabled. At this time the rfkill state is unknown to
mac80211 and config interface can fail. When this happens we deal with
this error instead of printing a WARN.

Signed-off-by: Reinette Chatre 
Signed-off-by: John W. Linville

mac80211: fix basic rate bitmap calculation

2009-04-20T20:36:26+00:00

"mac80211: fix basic rates setting from association response"
introduced a copy/paste error.

Unfortunately, this not just leads to wrong data being passed
to the driver but is remotely exploitable for some hardware or
driver combinations.

Signed-off-by: Johannes Berg 
Cc: stable@kernel.org [2.6.29]
Signed-off-by: John W. Linville