Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2722269pxj; Mon, 31 May 2021 09:06:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJhhqszuFY5w8eOWIUysjo20YeQ6kZvhSa2e8KCdVbWSbzXBhsWZuXtM8G2cKTZKWjAbRP X-Received: by 2002:a17:906:ff01:: with SMTP id zn1mr24219907ejb.119.1622477187646; Mon, 31 May 2021 09:06:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622477187; cv=none; d=google.com; s=arc-20160816; b=0GhHQBL8gQ1TcF5KViSploC1tBfmul5FCrgsVTpwc/Dszu9h3c3rSSKrKJTAtLxWlb kbPPUMtICSwxGKAHQXk11ncI0QJls9w2XMn+gEQjsoGRtOTvbKu99p8w36C5DXGyWMBx 0Qp8v8zfFajO0vGf5xGJTemiQXvfx1mSd6BN4gKfM/fvE4XIdQONIGxQJwjAfWsw+weA Q1MGJZdNDDd45FKMwIwsBpNTtColPGyJcEb2qUSCxYbLOxunue3t2L1ORJhnmlBuiulY Hr4O5IXwiXKRIjlrA/QTsroG/YqjDleXN/RW38OG+0I3UqTbuo9PMXrYJzlehILMsQkX mfdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=zEgSHAHvfg1oWEt90n86iT/Q1qSmwehihrBqrQsYKic=; b=dgZ8BCZUGdJSNloepwMBZngrX7suRusQH/PqRw6fTh4ZuMYXqdx9DzWuVTTaXNwe98 5ymWBWxVR3ofCc2jKL6dMZKpzDUMOvu/eT9IGKM+rJyXbBg4J4qGKoWn08i5MH6Tbu5Z yMTtlXIMQvvhXwK8MjHYEqE26Zj+7dA1SWJdzz0TWZjK9UWdawOVyJktd5m2FQnGpIwH ZmBu1RUaZO1Ml01EeFD3upnQSOjr5V4hSsxfEVsr2f9bMPL2jZYY92CtP0so28tLG081 VhrFrdN9j1jNkcvj5bAiwuQegOohB2ZiNlQugrYhj85+SFOU0fOmDC4cJXJk1WnqEx+H EThQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lbFSCKhq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d6si14574280ejz.127.2021.05.31.09.06.05; Mon, 31 May 2021 09:06:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lbFSCKhq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234566AbhEaQEf (ORCPT + 99 others); Mon, 31 May 2021 12:04:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:60316 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234113AbhEaOeU (ORCPT ); Mon, 31 May 2021 10:34:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4A44E61423; Mon, 31 May 2021 13:50:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622469031; bh=WJOoif5h4cUqEFlsrpmCMdIooQCY5qPCJRqgK2enOko=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lbFSCKhqpst879je3deouVNyDk+3GcqlB8g2omTyqNjgQQYtIXB9lhrojaXy+iTz4 dkm+i8+ubDBTd0RbE2E4PfIj6qflggV7MGtPU40oUFx5qgmgQKL0sIHWhjS2IqEyiQ 4ajXFooMlSIMc2Xp0SYvyg0zp8ViqYQnLvHqWiPU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jouni Malinen , Johannes Berg Subject: [PATCH 5.12 043/296] mac80211: do not accept/forward invalid EAPOL frames Date: Mon, 31 May 2021 15:11:38 +0200 Message-Id: <20210531130705.282715166@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130703.762129381@linuxfoundation.org> References: <20210531130703.762129381@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Johannes Berg commit a8c4d76a8dd4fb9666fc8919a703d85fb8f44ed8 upstream. EAPOL frames are used for authentication and key management between the AP and each individual STA associated in the BSS. Those frames are not supposed to be sent by one associated STA to another associated STA (either unicast for broadcast/multicast). Similarly, in 802.11 they're supposed to be sent to the authenticator (AP) address. Since it is possible for unexpected EAPOL frames to result in misbehavior in supplicant implementations, it is better for the AP to not allow such cases to be forwarded to other clients either directly, or indirectly if the AP interface is part of a bridge. Accept EAPOL (control port) frames only if they're transmitted to the own address, or, due to interoperability concerns, to the PAE group address. Disable forwarding of EAPOL (or well, the configured control port protocol) frames back to wireless medium in all cases. Previously, these frames were accepted from fully authenticated and authorized stations and also from unauthenticated stations for one of the cases. Additionally, to avoid forwarding by the bridge, rewrite the PAE group address case to the local MAC address. Cc: stable@vger.kernel.org Co-developed-by: Jouni Malinen Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- net/mac80211/rx.c | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -2530,13 +2530,13 @@ static bool ieee80211_frame_allowed(stru struct ethhdr *ehdr = (struct ethhdr *) rx->skb->data; /* - * Allow EAPOL frames to us/the PAE group address regardless - * of whether the frame was encrypted or not. + * Allow EAPOL frames to us/the PAE group address regardless of + * whether the frame was encrypted or not, and always disallow + * all other destination addresses for them. */ - if (ehdr->h_proto == rx->sdata->control_port_protocol && - (ether_addr_equal(ehdr->h_dest, rx->sdata->vif.addr) || - ether_addr_equal(ehdr->h_dest, pae_group_addr))) - return true; + if (unlikely(ehdr->h_proto == rx->sdata->control_port_protocol)) + return ether_addr_equal(ehdr->h_dest, rx->sdata->vif.addr) || + ether_addr_equal(ehdr->h_dest, pae_group_addr); if (ieee80211_802_1x_port_control(rx) || ieee80211_drop_unencrypted(rx, fc)) @@ -2561,8 +2561,28 @@ static void ieee80211_deliver_skb_to_loc cfg80211_rx_control_port(dev, skb, noencrypt); dev_kfree_skb(skb); } else { + struct ethhdr *ehdr = (void *)skb_mac_header(skb); + memset(skb->cb, 0, sizeof(skb->cb)); + /* + * 802.1X over 802.11 requires that the authenticator address + * be used for EAPOL frames. However, 802.1X allows the use of + * the PAE group address instead. If the interface is part of + * a bridge and we pass the frame with the PAE group address, + * then the bridge will forward it to the network (even if the + * client was not associated yet), which isn't supposed to + * happen. + * To avoid that, rewrite the destination address to our own + * address, so that the authenticator (e.g. hostapd) will see + * the frame, but bridge won't forward it anywhere else. Note + * that due to earlier filtering, the only other address can + * be the PAE group address. + */ + if (unlikely(skb->protocol == sdata->control_port_protocol && + !ether_addr_equal(ehdr->h_dest, sdata->vif.addr))) + ether_addr_copy(ehdr->h_dest, sdata->vif.addr); + /* deliver to local stack */ if (rx->list) list_add_tail(&skb->list, rx->list); @@ -2602,6 +2622,7 @@ ieee80211_deliver_skb(struct ieee80211_r if ((sdata->vif.type == NL80211_IFTYPE_AP || sdata->vif.type == NL80211_IFTYPE_AP_VLAN) && !(sdata->flags & IEEE80211_SDATA_DONT_BRIDGE_PACKETS) && + ehdr->h_proto != rx->sdata->control_port_protocol && (sdata->vif.type != NL80211_IFTYPE_AP_VLAN || !sdata->u.vlan.sta)) { if (is_multicast_ether_addr(ehdr->h_dest) && ieee80211_vif_get_num_mcast_if(sdata) != 0) {