• Mathy Vanhoef's avatar
    mac80211: Fix NULL ptr deref for injected rate info · bddc0c41
    Mathy Vanhoef authored
    The commit cb17ed29 ("mac80211: parse radiotap header when selecting Tx
    queue") moved the code to validate the radiotap header from
    ieee80211_monitor_start_xmit to ieee80211_parse_tx_radiotap. This made is
    possible to share more code with the new Tx queue selection code for
    injected frames. But at the same time, it now required the call of
    ieee80211_parse_tx_radiotap at the beginning of functions which wanted to
    handle the radiotap header. And this broke the rate parser for radiotap
    header parser.
    
    The radiotap parser for rates is operating most of the time only on the
    data in the actual radiotap header. But for the 802.11a/b/g rates, it must
    also know the selected band from the chandef information. But this
    information is only written to the ieee80211_tx_info at the end of the
    ieee80211_monitor_start_xmit - long after ieee80211_parse_tx_radiotap was
    already called. The info->band information was therefore always 0
    (NL80211_BAND_2GHZ) when the parser code tried to access it.
    
    For a 5GHz only device, injecting a frame with 802.11a rates would cause a
    NULL pointer dereference because local->hw.wiphy->bands[NL80211_BAND_2GHZ]
    would most likely have been NULL when the radiotap parser searched for the
    correct rate index of the driver.
    
    Cc: stable@vger.kernel.org
    Reported-by: default avatarBen Greear <greearb@candelatech.com>
    Fixes: cb17ed29 ("mac80211: parse radiotap header when selecting Tx queue")
    Signed-off-by: default avatarMathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
    [sven@narfation.org: added commit message]
    Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
    Link: https://lore.kernel.org/r/20210530133226.40587-1-sven@narfation.orgSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    bddc0c41
mac80211.h 264 KB