From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C96DFC7618B for ; Fri, 26 Jul 2019 14:23:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FE6D21743 for ; Fri, 26 Jul 2019 14:23:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727604AbfGZOXI (ORCPT ); Fri, 26 Jul 2019 10:23:08 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:45419 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfGZOXI (ORCPT ); Fri, 26 Jul 2019 10:23:08 -0400 Received: by mail-ed1-f66.google.com with SMTP id x19so47523394eda.12 for ; Fri, 26 Jul 2019 07:23:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=4tlpTADdY2fSxbXVBrVqoDJcw+VkjOYmmKX60sK+wlM=; b=KZuiMxVvu63gEskXS3jVd9ZUMB5LyFQuNV0IiTEN16rpvhTQWiStTHEIv9DamzmJ7W /Jw9GMmQhN+1LzXMvID3Y7uIFJIbNkEWi1Tp0NW6dIIg16i/xFfSl9ZE80cFcz3VL8K+ gHszDPCDo2VaUm/xeCv0Db6vbs7X3RWIhVVqMPkgTxWFI54knuHfxeOxbxUtq84tefE3 Bi4pVzDXLFduLcCfFqaY/ER/1MXqCHowQrcQveC+m8MNboRb5aa+aKZN4xglGSpOmym7 GW/MBk6+6ju1atyPV9AP6Da1x43/H7Ei4ZzpGyez8HseX2uKnjK7lLZnmOOq/Jds128G 9bzQ== X-Gm-Message-State: APjAAAVj9yOaGkhVzZjWnKATZeFdL1F/ty4VMW1PWwJQpJuUlAyncqrp 6TwBVSCDxlltcuV6x+Dlc2TrzMRRzn0= X-Google-Smtp-Source: APXvYqzZQaPbH8vp59RwX7yJdsGdpkV2yMt2qvDfhJ+2PXjF+A0XoMWgJUg4zLygFYg+8/KiRBWGbA== X-Received: by 2002:a17:906:2557:: with SMTP id j23mr72164151ejb.228.1564150986404; Fri, 26 Jul 2019 07:23:06 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id t2sm14370497eda.95.2019.07.26.07.23.05 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 26 Jul 2019 07:23:05 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 900991800C5; Fri, 26 Jul 2019 16:23:04 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Johannes Berg , Karthikeyan Periyasamy Cc: linux-wireless@vger.kernel.org Subject: Re: [PATCH] mac80211: reject zero MAC address in add station In-Reply-To: <218afd33eda4410472c2a99624f81908cf535cb4.camel@sipsolutions.net> References: <1563959770-21570-1-git-send-email-periyasa@codeaurora.org> <0cc7d0c578b60730e77ecd03e2df240dd1b393a0.camel@sipsolutions.net> <218afd33eda4410472c2a99624f81908cf535cb4.camel@sipsolutions.net> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 26 Jul 2019 16:23:04 +0200 Message-ID: <87imroyiwn.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Johannes Berg 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