linux-toradex.git/net/mac80211, branch v3.18

mac80211: minstrel_ht: fix a crash in rate sorting

2014-11-18T21:39:16+00:00

The commit 5935839ad73583781b8bbe8d91412f6826e218a4
"mac80211: improve minstrel_ht rate sorting by throughput & probability"

introduced a crash on rate sorting that occurs when the rate added to
the sorting array is faster than all the previous rates. Due to an
off-by-one error, it reads the rate index from tp_list[-1], which
contains uninitialized stack garbage, and then uses the resulting index
for accessing the group rate stats, leading to a crash if the garbage
value is big enough.

Cc: Thomas Huehn 
Reported-by: Jouni Malinen 
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg

mac80211: Fix regression that triggers a kernel BUG with CCMP

2014-11-06T11:42:22+00:00

Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
cryptoapi's CCM driver) introduced a regression when decrypting empty
packets (data_len == 0). This will lead to backtraces like:

(scatterwalk_start) from [] (scatterwalk_map_and_copy+0x2c/0xa8)
(scatterwalk_map_and_copy) from [] (crypto_ccm_decrypt+0x7c/0x25c)
(crypto_ccm_decrypt) from [] (ieee80211_aes_ccm_decrypt+0x160/0x170)
(ieee80211_aes_ccm_decrypt) from [] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
(ieee80211_crypto_ccmp_decrypt) from [] (ieee80211_rx_handlers+0x870/0x1d24)
(ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
(ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx+0x568/0x730)
(ieee80211_rx) from [] (__carl9170_rx+0x94c/0xa20)
(__carl9170_rx) from [] (carl9170_rx_stream+0x1fc/0x320)
(carl9170_rx_stream) from [] (carl9170_usb_tasklet+0x80/0xc8)
(carl9170_usb_tasklet) from [] (tasklet_hi_action+0x88/0xcc)
(tasklet_hi_action) from [] (__do_softirq+0xcc/0x200)
(__do_softirq) from [] (irq_exit+0x80/0xe0)
(irq_exit) from [] (handle_IRQ+0x64/0x80)
(handle_IRQ) from [] (__irq_svc+0x40/0x4c)
(__irq_svc) from [] (arch_cpu_idle+0x2c/0x34)

Such packets can appear for example when using the carl9170 wireless driver
because hardware sometimes generates garbage when the internal FIFO overruns.

This patch adds an additional length check.

Cc: stable@vger.kernel.org
Fixes: 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver")
Acked-by: Ard Biesheuvel 
Signed-off-by: Ronald Wahl 
Signed-off-by: Johannes Berg

mac80211: fix use-after-free in defragmentation

2014-11-03T13:28:50+00:00

Upon receiving the last fragment, all but the first fragment
are freed, but the multicast check for statistics at the end
of the function refers to the current skb (the last fragment)
causing a use-after-free bug.

Since multicast frames cannot be fragmented and we check for
this early in the function, just modify that check to also
do the accounting to fix the issue.

Cc: stable@vger.kernel.org
Reported-by: Yosef Khyal 
Signed-off-by: Johannes Berg

mac80211: properly flush delayed scan work on interface removal

2014-10-30T14:48:32+00:00

When an interface is deleted, an ongoing hardware scan is canceled and
the driver must abort the scan, at the very least reporting completion
while the interface is removed.

However, if it scheduled the work that might only run after everything
is said and done, which leads to cfg80211 warning that the scan isn't
reported as finished yet; this is no fault of the driver, it already
did, but mac80211 hasn't processed it.

To fix this situation, flush the delayed work when the interface being
removed is the one that was executing the scan.

Cc: stable@vger.kernel.org
Reported-by: Sujith Manoharan 
Tested-by: Sujith Manoharan 
Signed-off-by: Johannes Berg

mac80211: schedule the actual switch of the station before CSA count 0

2014-10-29T15:37:54+00:00

Due to the time it takes to process the beacon that started the CSA
process, we may be late for the switch if we try to reach exactly
beacon 0.  To avoid that, use count - 1 when calculating the switch time.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen 
Signed-off-by: Luciano Coelho 
Signed-off-by: Johannes Berg

mac80211: use secondary channel offset IE also beacons during CSA

2014-10-29T15:37:45+00:00

If we are switching from an HT40+ to an HT40- channel (or vice-versa),
we need the secondary channel offset IE to specify what is the
post-CSA offset to be used.  This applies both to beacons and to probe
responses.

In ieee80211_parse_ch_switch_ie() we were ignoring this IE from
beacons and using the *current* HT information IE instead.  This was
causing us to use the same offset as before the switch.

Fix that by using the secondary channel offset IE also for beacons and
don't ever use the pre-switch offset.  Additionally, remove the
"beacon" argument from ieee80211_parse_ch_switch_ie(), since it's not
needed anymore.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen 
Signed-off-by: Luciano Coelho 
Signed-off-by: Johannes Berg

mac80211: flush keys for AP mode on ieee80211_do_stop

2014-10-29T15:33:37+00:00

Userspace can add keys to an AP mode interface before start_ap has been
called. If there have been no calls to start_ap/stop_ap in the mean
time, the keys will still be around when the interface is brought down.

Signed-off-by: Felix Fietkau 
[adjust comments, fix AP_VLAN case]
Signed-off-by: Johannes Berg

mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats

2014-10-20T14:37:01+00:00

ATM an HT rc_stats line is 106 chars.
Times 8(MCS_GROUP_RATES)*3(SS)*2(GI)*2(BW) + CCK(4), i.e. x100, this is
well above the current 8192 - sizeof(*ms) currently allocated.

Fix this by squeezing the output as follows (not that we're short on
memory but this also improves readability and range, the new format adds
one more digit to *ok/*cum and ok/cum):

- Before (HT) (106 ch):
type           rate     throughput  ewma prob   this prob  retry   this succ/attempt   success    attempts
CCK/LP          5.5M           0.0        0.0         0.0      0              0(  0)         0           0
HT20/LGI ABCDP MCS0            0.0        0.0         0.0      1              0(  0)         0           0
- After (75 ch):
type           rate     tpt eprob *prob ret  *ok(*cum)        ok(      cum)
CCK/LP          5.5M    0.0   0.0   0.0   0    0(   0)         0(        0)
HT20/LGI ABCDP MCS0     0.0   0.0   0.0   1    0(   0)         0(        0)

- Align non-HT format Before (non-HT) (83 ch):
rate      throughput  ewma prob  this prob  this succ/attempt   success    attempts
ABCDP  6         0.0        0.0        0.0             0(  0)         0           0
      54         0.0        0.0        0.0             0(  0)         0           0
- After (61 ch):
rate          tpt eprob *prob  *ok(*cum)        ok(      cum)
ABCDP  1      0.0   0.0   0.0    0(   0)         0(        0)
      54      0.0   0.0   0.0    0(   0)         0(        0)

*This also adds dynamic checks for overflow, lowers the size of the
non-HT request (allowing > 30 entries) and replaces the buddy-rounded
allocations (s/sizeof(*ms) + 8192/8192).

Signed-off-by: Karl Beldan 
Acked-by: Felix Fietkau 
Signed-off-by: Johannes Berg

mac80211: fix typo in starting baserate for rts_cts_rate_idx

2014-10-14T09:16:16+00:00

It affects non-(V)HT rates and can lead to selecting an rts_cts rate
that is not a basic rate or way superior to the reference rate (ATM
rates[0] used for the 1st attempt of the protected frame data).

E.g, assuming drivers register growing (bitrate) sorted tables of
ieee80211_rate-s, having :
- rates[0].idx == d'2 and basic_rates == b'10100
will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
- rates[0].idx == d'2 and basic_rates == b'10001
will select rts_cts idx b'10000
The first is not a basic rate and the second is > rates[0].

Also, wrt severity of the addressed misbehavior, ATM we only have one
rts_cts_rate_idx rather than one per rate table entry, so this idx might
still point to bitrates > rates[1..MAX_RATES].

Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates")
Cc: stable@vger.kernel.org
Signed-off-by: Karl Beldan 
Signed-off-by: Johannes Berg

mac80211: return the vif's chandef in ieee80211_cfg_get_channel()

2014-10-09T09:01:58+00:00

The chandef of the channel context a vif is using may be different
than the chandef of the vif itself.  For instance, the bandwidth used
by the vif may be narrower than the one configured in the channel
context.  To avoid confusion, return the vif's chandef in
ieee80211_cfg_get_channel() instead of the chandef of the channel
context.

Signed-off-by: Luciano Coelho 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg