[PATCH] mac80211: reject zero MAC address in add station

[PATCH] mac80211: reject zero MAC address in add station

[Karthikeyan Periyasamy]

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 <periyasa@codeaurora.org>
---
 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

Re: [PATCH] mac80211: reject zero MAC address in add station

[Johannes Berg]

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

Re: [PATCH] mac80211: reject zero MAC address in add station

[Karthikeyan Periyasamy]

>> 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

Re: [PATCH] mac80211: reject zero MAC address in add station

[Johannes Berg]

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

Re: [PATCH] mac80211: reject zero MAC address in add station

[Toke Høiland-Jørgensen]

Johannes Berg <johannes@sipsolutions.net> 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