On Thu, 2007-06-14 at 11:02 +0100, Andy Green wrote: > Looking at the code, I think this can be okay unless I didn't understand > your point. At the time that the skb length is modified, I have this: > > if (skb->len < (iterator.max_length + FCS_LEN)) > return TXRX_DROP; > > skb_trim(skb, skb->len - FCS_LEN); > > iterator.max_length is the claimed radiotap header total length, which > was verified to be within the original skb length already. So at skb > length modification time, we take care beforehand that we have skb data > after the radiotap area to trim, otherwise we bail. Trimming into the > radiotap header region would be a bug in the code calling the parser, so > we trust that if the radiotap header length fitted in the skb at the > start it does so during the parsing. Ah, I missed that, I was under the impression that the iterator_next call was responsible for this error handling, but yeah, this is just fine. > I'm sorry I wasn't able to understand this. FCS presence is a feature > of the IEEE80211_RADIOTAP_FLAGS radiotap entry which does have an entry > in rt_sizes? Yeah, my mistake, sorry. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
