kernel/git/stable/linux.git/net/mac80211/tx.c, branch linux-5.9.y

mac80211: fix use of skb payload instead of header

2020-11-18T18:22:11+00:00

[ Upstream commit 14f46c1e5108696ec1e5a129e838ecedf108c7bf ] When ieee80211_skb_resize() is called from ieee80211_build_hdr() the skb has no 802.11 header yet, in fact it consist only of the payload as the ethernet frame is removed. As such, we're using the payload data for ieee80211_is_mgmt(), which is of course completely wrong. This didn't really hurt us because these are always data frames, so we could only have added more tailroom than we needed if we determined it was a management frame and sdata->crypto_tx_tailroom_needed_cnt was false. However, syzbot found that of course there need not be any payload, so we're using at best uninitialized memory for the check. Fix this to pass explicitly the kind of frame that we have instead of checking there, by replacing the "bool may_encrypt" argument with an argument that can carry the three possible states - it's not going to be encrypted, it's a management frame, or it's a data frame (and then we check sdata->crypto_tx_tailroom_needed_cnt). Reported-by: syzbot+32fd1a1bfe355e93f1e2@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20201009132538.e1fd7f802947.I799b288466ea2815f9d4c84349fae697dca2f189@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

mac80211: fix regression where EAPOL frames were sent in plaintext

2020-11-10T11:39:10+00:00

commit 804fc6a2931e692f50e8e317fcb0c8887331b405 upstream. When sending EAPOL frames via NL80211 they are treated as injected frames in mac80211. Due to commit 1df2bdba528b ("mac80211: never drop injected frames even if normally not allowed") these injected frames were not assigned a sta context in the function ieee80211_tx_dequeue, causing certain wireless network cards to always send EAPOL frames in plaintext. This may cause compatibility issues with some clients or APs, which for instance can cause the group key handshake to fail and in turn would cause the station to get disconnected. This commit fixes this regression by assigning a sta context in ieee80211_tx_dequeue to injected frames as well. Note that sending EAPOL frames in plaintext is not a security issue since they contain their own encryption and authentication protection. Cc: stable@vger.kernel.org Fixes: 1df2bdba528b ("mac80211: never drop injected frames even if normally not allowed") Reported-by: Thomas Deutschmann Tested-by: Christian Hesse Tested-by: Thomas Deutschmann Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20201019160113.350912-1-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: add missing queue/hash initialization to 802.3 xmit

2020-11-05T10:51:22+00:00

[ Upstream commit 5f8d69eaab1915df97f4f2aca89ea16abdd092d5 ] Fixes AQL for encap-offloaded tx Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20200908123702.88454-2-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-08-02T08:02:12+00:00

Resolved kernel/bpf/btf.c using instructions from merge commit 69138b34a7248d2396ab85c8652e20c0c39beaba Signed-off-by: David S. Miller

mac80211: parse radiotap header when selecting Tx queue

2020-07-31T07:27:01+00:00

Already parse the radiotap header in ieee80211_monitor_select_queue. In a subsequent commit this will allow us to add a radiotap flag that influences the queue on which injected packets will be sent. This also fixes the incomplete validation of the injected frame in ieee80211_monitor_select_queue: currently an out of bounds memory access may occur in in the called function ieee80211_select_queue_80211 if the 802.11 header is too small. Note that in ieee80211_monitor_start_xmit the radiotap header is parsed again, which is necessairy because ieee80211_monitor_select_queue is not always called beforehand. Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20200723100153.31631-6-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg

mac80211: remove unused flags argument in transmit functions

2020-07-31T07:27:01+00:00

The flags argument in transmit functions is no longer being used and can be removed. Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20200723100153.31631-5-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg

mac80211: use same flag everywhere to avoid sequence number overwrite

2020-07-31T07:27:01+00:00

Use the IEEE80211_TX_CTRL_NO_SEQNO flag in ieee80211_tx_info to mark probe requests whose sequence number must not be overwritten. This provides consistency with the radiotap flag that can be set to indicate that the sequence number of an injected frame should not be overwritten. Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20200723100153.31631-4-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg

mac80211: do not overwrite the sequence number if requested

2020-07-31T07:27:01+00:00

Check if the Tx control flag is set to prevent sequence number overwrites, and if so, do not assign a new sequence number to the transmitted frame. Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20200723100153.31631-3-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg

mac80211: add radiotap flag to prevent sequence number overwrite

2020-07-31T07:27:00+00:00

The radiotap specification contains a flag to indicate that the sequence number of an injected frame should not be overwritten. Parse this flag and define and set a corresponding Tx control flag. Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20200723100153.31631-2-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg

mac80211: never drop injected frames even if normally not allowed

2020-07-31T07:27:00+00:00

In ieee80211_tx_dequeue there is a check to see if the dequeued frame is allowed in the current state. Injected frames that are normally not allowed are being be dropped here. Fix this by checking if a frame was injected and if so always allowing it. Signed-off-by: Mathy Vanhoef Link: https://lore.kernel.org/r/20200723100153.31631-1-Mathy.Vanhoef@kuleuven.be Signed-off-by: Johannes Berg