Hello!
I've been testing mac80211 with kmemcheck. By injecting specially
crafted packets, I could trigger a warning in ieee80211_tx_status() on
this line:
frag = le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG;
It turns out hdr->seq_ctrl is beyond the end of the skb. Adding printk
confirms it:
hdr=0xffff88012aa04868, &hdr->seq_ctrl=0xffff88012aa0487e,
skb->data=0xffff88012aa04868, skb->data + skb->len=0xffff88012aa0487c
The packets that produce the warning have the radiotap header length
increased by 10.
Here's the annotated dump of the packet:
/* Original radiotap header, but the length should be 0e, not 18 */
00 00 18 00 03 00 00 00 00 02 6c 09 a0 00
/* mac80211 treats this as part of the radiotap header */
08 03 00 00 01 0c cc 00 00 00
/* frame control */
00 11
/* duration */
6b 39
/* addr1 */
40 19 11 04 28 00
/* addr2 */
00 00 10 00 00 00
/* addr3 - incomplete */
00 00 00 00
/* sequence control - beyond the skb end */
I'm using rt73usb to inject. ieee80211_tx_status() is scheduled by
ieee80211_tx_status_irqsafe(), which is called in rt2x00dev.c.
If we allow to inject malformed packets, we shouldn't assume them to be
valid 802.11 packets unless we can verify it. And even then, maybe it's
better to bypass ieee80211_tx_status() for injected packets, as it can
influence statistics and rate control algorithms in unpredictable ways.
--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
