summaryrefslogtreecommitdiff
path: root/security
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2017-05-27 00:27:25 +0200
committerJohannes Berg <johannes.berg@intel.com>2017-05-30 09:08:40 +0200
commit7a7c0a6438b8e7636d5a22e572892cc234f68297 (patch)
tree5af401a86137d6e3ec642bc86cd5ab6b3e418428 /security
parent029c58178b9aa0a293a86ee0da3355611ac99d07 (diff)
mac80211: fix TX aggregation start/stop callback race
When starting or stopping an aggregation session, one of the steps is that the driver calls back to mac80211 that the start/stop can proceed. This is handled by queueing up a fake SKB and processing it from the normal iface/sdata work. Since this isn't flushed when disassociating, the following race is possible: * associate * start aggregation session * driver callback * disassociate * associate again to the same AP * callback processing runs, leading to a WARN_ON() that the TID hadn't requested aggregation If the second association isn't to the same AP, there would only be a message printed ("Could not find station: <addr>"), but the same race could happen. Fix this by not going the whole detour with a fake SKB etc. but simply looking up the aggregation session in the driver callback, marking it with a START_CB/STOP_CB bit and then scheduling the regular aggregation work that will now process these bits as well. This also simplifies the code and gets rid of the whole problem with allocation failures of said skb, which could have left the session in limbo. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions