netdev - Re: [RFC] mac80211: clean up frame receive handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1197812974.16079.64.camel@johannes.berg>
Date:	Sun, 16 Dec 2007 14:49:34 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Ron Rindjunsky <rindjon@...glemail.com>
Cc:	linux-wireless <linux-wireless@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Michael Wu <flamingice@...rmilk.net>,
	Tomas Winkler <tomasw@...il.com>, Jouni Malinen <j@...fi>
Subject: Re: [RFC] mac80211: clean up frame receive handling

> > +       if (local->bridge_packets && (sdata->type == IEEE80211_IF_TYPE_AP ||
> > +                                     sdata->type == IEEE80211_IF_TYPE_VLAN) &&
> 
> i may miss something, but wouldn't you prefer to use eth_type_trans
> here and just add compare_ether_addr check after it?

Yes, I think I would, but I also think it's wrong to call
eth_type_trans. We always remove the rfc2042 header and replace it with
a regular ethernet header; but in the case there was no rfc2042 header
we just stick in the length. But the length of a wireless packet can be
bigger than the 1536 below which eth_type_trans assumes it's a length,
so when we stick in a length>1536 it'll assume it's not a length but
rather an ethertype, which will be wrong.

The thing is, I couldn't so far even find the case where we receive a
frame *without* rfc2042 header.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)