Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4016685pxj; Tue, 11 May 2021 17:55:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVBRbxQCcJ6QFMqRnhxV9r8TRWdu5HZbRRCMDfSkYKkEUlblRdGHxtbEHa/4S5NBtVzPVc X-Received: by 2002:a17:906:1fd1:: with SMTP id e17mr35520560ejt.419.1620780956982; Tue, 11 May 2021 17:55:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620780956; cv=none; d=google.com; s=arc-20160816; b=vmq2yMiGsamy5gZizZvTj8BHE3UTxP/7BA7pZYdKnNSPSkU87Nw8f5Gfar8k09cEck o3ib17ht28xqCk2GnSilBuJFTZfnjsbqP8geLzvi5EsH0EQnK8NNm25dOHAke+kJNats t5zto1fZrStPCl3lTE9q0DYOAfg0sdM8UwSRaXe4qWms06jLWVCvkVVlbgW11KZXSf8y 3wTtCoskMrpe58QZVSthYYXxeE2yF7B1qDjdxWZkA1RPmo9AR+aiVax3Didy/IJnyhpZ Pi+qm+0yS2fjefdAl17M+qgmJHGtiHAQ3ZW1Zr33LONX7n5uj5WtZYvhc6Cr9SZorXwL vTng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=11LIPUj+/FEY28zLXi+or8MFIxpwei/42kdufWNvYWI=; b=P9fBqVwpB01qnj2ERLyVI4z0dHNVH/SM70DsAWx6E9kvGHBWpOevtLd7X6h92+4VpI 7t7VyyirFS6SpSublGuIGzkDWqGMkJl5yuLIoylqbjF9tdmC3AnNhKQvkYvPAw53iiT7 NT/U66Zm9/hYG0Tj56IZPrQBfhyMsQSu69gYLN1Xt9D0tKV2dcY1FBmPdHQ5z8XKeqb8 2ld+OnV5T0PHXsFmR805ao/ypo44FCl9AT4z/HMsyWt7Wmcdtzo3xUYRyGAL0Op0kyTh Oh5vvwuT3YNR4rABgAgywVKdL9HVJ7FwcvW1Z4YzWRMLnYpnfDM21TpRG8pxtGncPCsR DfOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fNGeBskj; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z16si11042521edd.136.2021.05.11.17.55.27; Tue, 11 May 2021 17:55:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-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=@gmail.com header.s=20161025 header.b=fNGeBskj; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229784AbhELA4Y (ORCPT + 99 others); Tue, 11 May 2021 20:56:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229637AbhELA4X (ORCPT ); Tue, 11 May 2021 20:56:23 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92907C061574 for ; Tue, 11 May 2021 17:55:15 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id b21so10229686pft.10 for ; Tue, 11 May 2021 17:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=11LIPUj+/FEY28zLXi+or8MFIxpwei/42kdufWNvYWI=; b=fNGeBskj3yNXA0Iu9yGMpYr5sfvf7vr/TGi4pZnNRWYOLRtPlh7RIBNT7ylTk+IlaA rYl0SDo/sqaY3BL9ZIFOm/m9DzB6Q9QvzOd7B3ZbaW5OFX4tyxUiMtw0BCdUeBLaGG7D iSIPK3p4b607i5/dzrEpNDH1Dlyt4DnmDaH03iwSXzHR2JNoQKpec3gUmiAEuvjERNFd NMgE3xBjSrTqTZ6tn9y6rj1eu8MgusTyMns+jSmo8xC1O9tNcfDzwgwo3++DwyVNicAR imKLFef1LqIB/c4y/iM2ia5qZ6BYeNw6LalyAiqnW7Z9YeLsDvgI9Q6EtTPdj8eJ2a7+ Bi6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=11LIPUj+/FEY28zLXi+or8MFIxpwei/42kdufWNvYWI=; b=PlhJLWA3J3HrJqkhTqnQv6kyFf0mh9cjpduSa6TIhxQx7R+Rza07F7tv0nroD6qeIG oMJy8OjHLyNloM4pSFSDR9rOhgEgf/jvv7AsuiDGa2kM7y110/UffRG0DmB3DIGeBf+2 DJM+mSElf76bwtjfTjHJe5NEyxICI6KiSlm3kqq1qDARSY/oPMK0VlvoqXqB7K4HG+f1 zoC+AzxpN5NPNU4cfDYMITjXFQvQTf1nPny3YDNOkmWeU7BzP29rfWw2tfUZoYJ4SG5v XPACd0kcYxXwwaWfUE96zwYSdvjnLLcXEZRJxBkDMoeIwnQphpviD3AJwAVb0U0S/gpF 255g== X-Gm-Message-State: AOAM5339YDKev8KJkpNPYqAzQ45Ho3XNckWHNxuX5MEtRlPa2dFENjLX b7Vd+jPB/ujzRgEyd6TgxRk= X-Received: by 2002:aa7:87d6:0:b029:28e:5d2d:4590 with SMTP id i22-20020aa787d60000b029028e5d2d4590mr32241950pfo.13.1620780914975; Tue, 11 May 2021 17:55:14 -0700 (PDT) Received: from nuc ([202.133.196.154]) by smtp.gmail.com with ESMTPSA id s6sm14627922pgv.48.2021.05.11.17.55.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 17:55:14 -0700 (PDT) Date: Wed, 12 May 2021 08:55:10 +0800 From: Du Cheng To: Shuah Khan Cc: Thomas Pedersen , Johannes Berg , linux-wireless@vger.kernel.org, Greg Kroah-Hartman , syzbot+405843667e93b9790fc1@syzkaller.appspotmail.com Subject: Re: [PATCH] net: mac80211: fix hard-coding of length check on skb->len in ieee80211_scan_rx() Message-ID: References: <20210510041649.589754-1-ducheng2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Le Tue, May 11, 2021 at 04:29:07PM -0600, Shuah Khan a écrit : > On 5/9/21 10:16 PM, Du Cheng wrote: > > Replace hard-coding with compile-time constants for header length > > check on skb->len. This skb->len will be checked again further down the > > callstack in cfg80211_inform_bss_frame_data() in net/wireless/scan.c > > (which has a proper length check with WARN_ON()). If the kernel is > > configure to panic_on_warn(), the insuffient check of skb->len in > > ieee80211_scan_rx() causes kernel crash in > > cfg80211_inform_bss_frame_data(). > > > > Where is this WARN_ON? I didn't see it cfg80211_inform_bss_frame_data() > > Please add more information on why the values of min_hdr_len in this > patch make sense for each of these cases. Hi Shuah, The WARN_ON() is located here: linux/net/wireless/scan.c: 2331 ``` if (ieee80211_is_s1g_beacon(mgmt->frame_control)) { ext = (void *) mgmt; min_hdr_len = offsetof(struct ieee80211_ext, u.s1g_beacon); if (ieee80211_is_s1g_short_beacon(mgmt->frame_control)) min_hdr_len = offsetof(struct ieee80211_ext, u.s1g_short_beacon.variable); } if (WARN_ON(len < min_hdr_len)) // <- warn_on line return NULL; ``` the min_hdr_len that I added in was following the setup of min_hdr_len before that WARN_ON(len < min_hdr_len) > > > Bug reported by syzbot: > > https://syzkaller.appspot.com/bug?id=183869c2f25b1c8692e381d8fcd69771a99221cc > > > > Reported-by: syzbot+405843667e93b9790fc1@syzkaller.appspotmail.com > > Signed-off-by: Du Cheng > > --- > > > > This patch has passed syzbot testing. > > > > net/mac80211/scan.c | 18 +++++++++++++----- > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c > > index d4cc9ac2d703..562eda13e802 100644 > > --- a/net/mac80211/scan.c > > +++ b/net/mac80211/scan.c > > @@ -251,13 +251,21 @@ void ieee80211_scan_rx(struct ieee80211_local *local, struct sk_buff *skb) > > struct ieee80211_mgmt *mgmt = (void *)skb->data; > > struct ieee80211_bss *bss; > > struct ieee80211_channel *channel; > > + size_t min_hdr_len = offsetof(struct ieee80211_mgmt, u.probe_resp.variable); > > + > > + if (!ieee80211_is_probe_resp(mgmt->frame_control) && > > + !ieee80211_is_beacon(mgmt->frame_control) && > > + !ieee80211_is_s1g_beacon(mgmt->frame_control)) > > + return; > > Is the above check necessary? This doesn't look right. This skips > the ieee80211_is_s1g_beacon() all together. the original check only has the first two conditions (ieee80211_is_probe_resp() and ieee80211_is_beacon()), but they were placed after condition of ieee80211_is_s1g_beacon() not being met. Since I moved these checks at the above, _before_ the if(ieee80211_is_s1g_beacon()), hence I joined ieee80211_is_s1g_beacon() with the two orginal conditions. > > > if (ieee80211_is_s1g_beacon(mgmt->frame_control)) { > > - if (skb->len < 15) > > - return; > > Why not compare the header offset you expect here instead of 15 and > return? In fact, I do not understand where 15 (and the 24 shortly after) comes from. They were there more than 10 years ago, but the more recent guard code in cfg80211_inform_single_bss_frame_data() on the same header length seems more correct, therefore I followed examples and copied the calculation from there, for consistency. > > > - } else if (skb->len < 24 || > > Can you explain why it makes sense to remove < 24 check? I replaced 24 with `size_t min_hdr_len = offsetof(struct ieee80211_mgmt, u.probe_resp.variable);` which was found in cfg80211_inform_single_bss_frame_data(), for conditions: ieee80211_is_probe_resp(mgmt->frame_control) or ieee80211_is_beacon(mgmt->frame_control) > > > - (!ieee80211_is_probe_resp(mgmt->frame_control) && > > - !ieee80211_is_beacon(mgmt->frame_control))) > > + if (ieee80211_is_s1g_short_beacon(mgmt->frame_control)) > > + min_hdr_len = offsetof(struct ieee80211_ext, u.s1g_short_beacon.variable); > > + else > > + min_hdr_len = offsetof(struct ieee80211_ext, u.s1g_beacon); > > + } > > + > > + if (skb->len < min_hdr_len) > > return; > > sdata1 = rcu_dereference(local->scan_sdata); > > > > thanks, > -- Shuah Best regards, Du Cheng