Don't allow using a zero MAC address as the station
MAC address. so validated the MAC address using
is_valid_ether_addr.
Signed-off-by: Karthikeyan Periyasamy <[email protected]>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 4f12d04..cf97b07 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1539,7 +1539,7 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (ether_addr_equal(mac, sdata->vif.addr))
return -EINVAL;
- if (is_multicast_ether_addr(mac))
+ if (!is_valid_ether_addr(mac))
return -EINVAL;
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
--
1.9.1
On Wed, 2019-07-24 at 14:46 +0530, Karthikeyan Periyasamy wrote:
> Don't allow using a zero MAC address as the station
> MAC address. so validated the MAC address using
> is_valid_ether_addr.
Theoretically, all zeroes might have been a valid address at some point.
I see no reason not to reject it, but I'd like to know why you ended up
with this now??
johannes
On Fri, 2019-07-26 at 19:36 +0530, Karthikeyan Periyasamy wrote:
> > > Don't allow using a zero MAC address as the station
> > > MAC address. so validated the MAC address using
> > > is_valid_ether_addr.
> >
> > Theoretically, all zeroes might have been a valid address at some
> > point.
> > I see no reason not to reject it, but I'd like to know why you ended up
> > with this now??
> >
>
> Its a Wireless fuzz testing tool (codenomicon) which sends out different
> types of frames to the AP. It actually tampers legitimate wireless
> frames (Probe, Auth, Assoc, Data etc..) and will send to the AP. I
> thought allowing a zero MAC address station is not a valid. so validated
> the given MAC address. Just for curious, which case all zero address is
> a valid MAC.
Well, it isn't really, but the OUI 00:00:00 *is* in fact assigned (or
was), and theoretically the vendor could assign it to a device.
We do assume basically everywhere that it's invalid though.
Was just wondering how you came across this really, I guess I'll add a
bit of text to the commit log and merge it.
johannes
>> Don't allow using a zero MAC address as the station
>> MAC address. so validated the MAC address using
>> is_valid_ether_addr.
>
> Theoretically, all zeroes might have been a valid address at some
> point.
> I see no reason not to reject it, but I'd like to know why you ended up
> with this now??
>
Its a Wireless fuzz testing tool (codenomicon) which sends out different
types of frames to the AP. It actually tampers legitimate wireless
frames (Probe, Auth, Assoc, Data etc..) and will send to the AP. I
thought allowing a zero MAC address station is not a valid. so validated
the given MAC address. Just for curious, which case all zero address is
a valid MAC.
Thanks,
Karthikeyan
Johannes Berg <[email protected]> writes:
> On Fri, 2019-07-26 at 19:36 +0530, Karthikeyan Periyasamy wrote:
>> > > Don't allow using a zero MAC address as the station
>> > > MAC address. so validated the MAC address using
>> > > is_valid_ether_addr.
>> >
>> > Theoretically, all zeroes might have been a valid address at some
>> > point.
>> > I see no reason not to reject it, but I'd like to know why you ended up
>> > with this now??
>> >
>>
>> Its a Wireless fuzz testing tool (codenomicon) which sends out different
>> types of frames to the AP. It actually tampers legitimate wireless
>> frames (Probe, Auth, Assoc, Data etc..) and will send to the AP. I
>> thought allowing a zero MAC address station is not a valid. so validated
>> the given MAC address. Just for curious, which case all zero address is
>> a valid MAC.
>
> Well, it isn't really, but the OUI 00:00:00 *is* in fact assigned (or
> was), and theoretically the vendor could assign it to a device.
Heh, now that we allow routing the 0.0.0.0/8 subnet, this means that the
following could be a perfectly sensible thing to do:
'ip neigh add 0.0.0.1/8 lladdr 00:00:00:00:00:01 dev wlan0'
One bit per address per network layer ought to be enough for everyone,
right? ;)
-Toke