linux-stable.git/net/mac80211, branch linux-3.16.y

mac80211: Do not send Layer 2 Update frame before authorization

2020-04-28T18:02:17+00:00

commit 3e493173b7841259a08c5c8e5cbe90adb349da7e upstream.

The Layer 2 Update frame is used to update bridges when a station roams
to another AP even if that STA does not transmit any frames after the
reassociation. This behavior was described in IEEE Std 802.11F-2003 as
something that would happen based on MLME-ASSOCIATE.indication, i.e.,
before completing 4-way handshake. However, this IEEE trial-use
recommended practice document was published before RSN (IEEE Std
802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
maintained amd should not be used anymore.

Sending out the Layer 2 Update frame immediately after association is
fine for open networks (and also when using SAE, FT protocol, or FILS
authentication when the station is actually authenticated by the time
association completes). However, it is not appropriate for cases where
RSN is used with PSK or EAP authentication since the station is actually
fully authenticated only once the 4-way handshake completes after
authentication and attackers might be able to use the unauthenticated
triggering of Layer 2 Update frame transmission to disrupt bridge
behavior.

Fix this by postponing transmission of the Layer 2 Update frame from
station entry addition to the point when the station entry is marked
authorized. Similarly, send out the VLAN binding update only if the STA
entry has already been authorized.

Signed-off-by: Jouni Malinen 
Reviewed-by: Johannes Berg 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

cfg80211/mac80211: make ieee80211_send_layer2_update a public function

2020-04-28T18:02:17+00:00

commit 30ca1aa536211f5ac3de0173513a7a99a98a97f3 upstream.

Make ieee80211_send_layer2_update() a common function so other drivers
can re-use it.

Signed-off-by: Dedy Lansky 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16 as dependency of commit 3e493173b784
 "mac80211: Do not send Layer 2 Update frame before authorization":
 - Retain type-casting of skb_put() return value
 - Adjust context]
Signed-off-by: Ben Hutchings

mac80211: Reject malformed SSID elements

2019-12-19T15:58:03+00:00

commit 4152561f5da3fca92af7179dd538ea89e248f9d0 upstream.

Although this shouldn't occur in practice, it's a good idea to bounds
check the length field of the SSID element prior to using it for things
like allocations or memcpy operations.

Cc: Kees Cook 
Reported-by: Nicolas Waisman 
Signed-off-by: Will Deacon 
Link: https://lore.kernel.org/r/20191004095132.15777-1-will@kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: handle deauthentication/disassociation from TDLS peer

2019-09-23T20:12:10+00:00

commit 79c92ca42b5a3e0ea172ea2ce8df8e125af237da upstream.

When receiving a deauthentication/disassociation frame from a TDLS
peer, a station should not disconnect the current AP, but only
disable the current TDLS link if it's enabled.

Without this change, a TDLS issue can be reproduced by following the
steps as below:

1. STA-1 and STA-2 are connected to AP, bidirection traffic is running
   between STA-1 and STA-2.
2. Set up TDLS link between STA-1 and STA-2, stay for a while, then
   teardown TDLS link.
3. Repeat step #2 and monitor the connection between STA and AP.

During the test, one STA may send a deauthentication/disassociation
frame to another, after TDLS teardown, with reason code 6/7, which
means: Class 2/3 frame received from nonassociated STA.

On receive this frame, the receiver STA will disconnect the current
AP and then reconnect. It's not a expected behavior, purpose of this
frame should be disabling the TDLS link, not the link with AP.

Signed-off-by: Yu Wang 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16:
 - Initialise reason_code earlier in ieee80211_rx_mgmt_deauth()
 - Adjust context]
Signed-off-by: Ben Hutchings

mac80211: drop robust management frames from unknown TA

2019-09-23T20:12:09+00:00

commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream.

When receiving a robust management frame, drop it if we don't have
rx->sta since then we don't have a security association and thus
couldn't possibly validate the frame.

Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mac80211: add API to request TDLS operation from userspace

2019-09-23T20:12:09+00:00

commit c887f0d3a03283cb6fe2c32aae62229bebd3fa32 upstream.

Write a mac80211 to the cfg80211 API for requesting a userspace TDLS
operation. Define TDLS specific reason codes that can be used here.

Signed-off-by: Arik Nemtsov 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: don't attempt to rename ERR_PTR() debugfs dirs

2019-08-13T11:39:13+00:00

commit 517879147493a5e1df6b89a50f708f1133fcaddb upstream.

We need to dereference the directory to get its parent to
be able to rename it, so it's clearly not safe to try to
do this with ERR_PTR() pointers. Skip in this case.

It seems that this is most likely what was causing the
report by syzbot, but I'm not entirely sure as it didn't
come with a reproducer this time.

Reported-by: syzbot+4ece1a28b8f4730547c9@syzkaller.appspotmail.com
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: ensure that mgmt tx skbs have tailroom for encryption

2019-05-02T20:41:33+00:00

commit 9d0f50b80222dc273e67e4e14410fcfa4130a90c upstream.

Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
frames need to be software encrypted. Since normal data packets are still
encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
which don't have the necessary tailroom for software encryption.

Change the code to add tailroom for encrypted management packets, even if
crypto_tx_tailroom_needed_cnt is 0.

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16: we always expand cloned skbs here; don't change that]
Signed-off-by: Ben Hutchings

mac80211: ignore NullFunc frames in the duplicate detection

2019-02-11T17:54:20+00:00

commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream.

NullFunc packets should never be duplicate just like
QoS-NullFunc packets.

We saw a client that enters / exits power save with
NullFunc frames (and not with QoS-NullFunc) despite the
fact that the association supports HT.
This specific client also re-uses a non-zero sequence number
for different NullFunc frames.
At some point, the client had to send a retransmission of
the NullFunc frame and we dropped it, leading to a
misalignment in the power save state.
Fix this by never consider a NullFunc frame as duplicate,
just like we do for QoS NullFunc frames.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16: The condition for "should we check for duplication"
 is in ieee80211_rx_h_check() and is not inverted]
Signed-off-by: Ben Hutchings

mac80211: fix reordering of buffered broadcast packets

2019-02-11T17:54:20+00:00

commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream.

If the buffered broadcast queue contains packets, letting new packets bypass
that queue can lead to heavy reordering, since the driver is probably throttling
transmission of buffered multicast packets after beacons.

Keep buffering packets until the buffer has been cleared (and no client
is in powersave mode).

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings