Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2690133pxj; Mon, 31 May 2021 08:19:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkjTNa9gH1nJmWJ/jWO7+UFrXrviOQl6zwVvrPT2Gt9Yyzdff1QIm/MmjP8gOSgUp0K1PG X-Received: by 2002:a17:906:bfc8:: with SMTP id us8mr11153889ejb.217.1622474387378; Mon, 31 May 2021 08:19:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622474387; cv=none; d=google.com; s=arc-20160816; b=RsfK5gtQ4H7QwiskVrjn74SedGZiApqnP0pQzT9eqcBSttjnB+CajvvmGLup7TbpDt wsZr0WayVp37eGjAK5qbzVOkLPY67lKSYZkehi6lITzN1Q8txsSjPYvpWQMV2LJcVKnI hEpROxl2PLOhzURn/O/2T7fY/c/teYzi8HeRwNUrLhbv+p3/GRfWsxp4hXOu56fxuLQs ldVI4V1dqG8RSfsrsnJSVQVxGatJMhNhV7z3uUe0sOZyGDRvbFbGZNM3NHp27heQ48Rl veQDHWRbKXiWLUXFhV622lbye6Xz4/yjrVDTN7L78MPmM9e38VNY1LoKvXGdSQV7sJW5 XYug== 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=IpV1Pa0Fue1J2gPThGdA3SoG8OlbhkL8vS+AzUg9ARc=; b=dMRD5YhZemV+fXucEcyOkKhTWSwKUIHIEjl3FN3A79Wwp2FHDv0CnE60I5gpvneqfW KXh1iHrc3GWAPUHRAXr9FTjKSu7msWmLSzCbb3gr967DqrmNkUlS8apc4JomrqJ7Sh9U YSX4AtuwlpdWwrD+9Pk7UKxFASqTfSCTdTCG/Y/pkl+EnSpGYD1pJ/JPzGa0NN4pINT2 rrelByTpd0TI3V+JcCAhpCnik26stZdTmsIlUe5Ter4w3Xd8m+vVzKQJf6bQ2P2/xso6 EZr936UUsINd6YNSrVXxsEsvkj9OWn1flsDLcmPO+RKp5svNDO1ZxQhqoR93MJEAo1F/ KfZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=WFTy4gsm; 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 y14si11375947edc.428.2021.05.31.08.19.24; Mon, 31 May 2021 08:19:47 -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=WFTy4gsm; 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 S232837AbhEaPRc (ORCPT + 99 others); Mon, 31 May 2021 11:17:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:43304 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232860AbhEaONi (ORCPT ); Mon, 31 May 2021 10:13:38 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5A98061469; Mon, 31 May 2021 13:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622468523; bh=gsXOuKmnPq6FsTcw5IbiriUv48/9mznqgUojDMFrieI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WFTy4gsmaE7ccvI4JXjFsPCuV3urQSkUTTLnJv2A7LULCKCA9vLG1HQZJeADkCt+0 LEyx/Ofj9wQHb72qPdG+9IHDlTqI2/FHwlDjKBem0SUu8DIQabiFFSmfFkLV+No/cT WH6V88HIq1JbghtNHqCMx0AqYDueeEC5qHG4Xbpw= 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.4 022/177] mac80211: do not accept/forward invalid EAPOL frames Date: Mon, 31 May 2021 15:12:59 +0200 Message-Id: <20210531130648.690917403@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130647.887605866@linuxfoundation.org> References: <20210531130647.887605866@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 @@ -2484,13 +2484,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)) @@ -2514,8 +2514,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->napi) napi_gro_receive(rx->napi, skb); @@ -2555,6 +2575,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) {