sdata may be used uninitialized in ieee80211_tx_status() when adding the
radiotap header. It was added as parameter in "mac80211: select and
adjust bitrates according to channel mode" to find the current control
channel width (5/10/20+ MHz) and is used to report the bitrate
correctly. Fix this by identifing the required shift when cycling
through the interfaces.
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Simon Wunderlich <[email protected]>
Cc: Mathias Kretschmer <[email protected]>
---
You might want to squash this into the offending patch before sending it
further upstream.
---
net/mac80211/status.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 690138a..6ad4c14 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -253,10 +253,9 @@ static int ieee80211_tx_radiotap_len(struct ieee80211_tx_info *info)
}
static void
-ieee80211_add_tx_radiotap_header(struct ieee80211_sub_if_data *sdata,
- struct ieee80211_supported_band *sband,
+ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band *sband,
struct sk_buff *skb, int retry_count,
- int rtap_len)
+ int rtap_len, int shift)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
@@ -282,7 +281,6 @@ ieee80211_add_tx_radiotap_header(struct ieee80211_sub_if_data *sdata,
/* IEEE80211_RADIOTAP_RATE */
if (info->status.rates[0].idx >= 0 &&
!(info->status.rates[0].flags & IEEE80211_TX_RC_MCS)) {
- int shift = ieee80211_vif_get_shift(&sdata->vif);
u16 rate;
rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_RATE);
@@ -430,6 +428,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
bool acked;
struct ieee80211_bar *bar;
int rtap_len;
+ int shift = 0;
for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
if ((info->flags & IEEE80211_TX_CTL_AMPDU) &&
@@ -464,6 +463,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
if (!ether_addr_equal(hdr->addr2, sta->sdata->vif.addr))
continue;
+ shift = ieee80211_vif_get_shift(&sta->sdata->vif);
+
if (info->flags & IEEE80211_TX_STATUS_EOSP)
clear_sta_flag(sta, WLAN_STA_SP);
@@ -630,8 +631,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
dev_kfree_skb(skb);
return;
}
- ieee80211_add_tx_radiotap_header(sdata, sband, skb, retry_count,
- rtap_len);
+ ieee80211_add_tx_radiotap_header(sband, skb, retry_count, rtap_len,
+ shift);
/* XXX: is this sufficient for BPF? */
skb_set_mac_header(skb, 0);
--
1.7.10.4
On Tue, Jul 09, 2013 at 09:15:46PM +0200, Johannes Berg wrote:
> On Tue, 2013-07-09 at 21:13 +0200, Simon Wunderlich wrote:
> > sdata may be used uninitialized in ieee80211_tx_status() when adding the
> > radiotap header. It was added as parameter in "mac80211: select and
> > adjust bitrates according to channel mode" to find the current control
> > channel width (5/10/20+ MHz) and is used to report the bitrate
> > correctly. Fix this by identifing the required shift when cycling
> > through the interfaces.
> >
> > Reported-by: kbuild test robot <[email protected]>
> > Signed-off-by: Simon Wunderlich <[email protected]>
> > Cc: Mathias Kretschmer <[email protected]>
> > ---
> > You might want to squash this into the offending patch before sending it
> > further upstream.
>
> I was about to drop most of your patches again, but OK :)
Yeah I can imagine, and I would like to avoid that. :P
Thanks,
Simon
On Tue, 2013-07-09 at 21:13 +0200, Simon Wunderlich wrote:
> sdata may be used uninitialized in ieee80211_tx_status() when adding the
> radiotap header. It was added as parameter in "mac80211: select and
> adjust bitrates according to channel mode" to find the current control
> channel width (5/10/20+ MHz) and is used to report the bitrate
> correctly. Fix this by identifing the required shift when cycling
> through the interfaces.
>
> Reported-by: kbuild test robot <[email protected]>
> Signed-off-by: Simon Wunderlich <[email protected]>
> Cc: Mathias Kretschmer <[email protected]>
> ---
> You might want to squash this into the offending patch before sending it
> further upstream.
I was about to drop most of your patches again, but OK :)
johannes