Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2675284pxj; Mon, 17 May 2021 07:16:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwf8rk9c3AEBzuSrJ+q/O8rgiZDI2tN3RwoWha/2I0cfIFJT5UaJmm9M5Jf7ahwKdImwSBT X-Received: by 2002:a17:907:1b19:: with SMTP id mp25mr152334ejc.154.1621260990404; Mon, 17 May 2021 07:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621260990; cv=none; d=google.com; s=arc-20160816; b=qpo44KG0hkRCIh1PyumDrrlllGHv+58TiCFimWL/KfwKYjv+jv/Q4McVMg03CYSL3r kp5VjasFc3wn/X6ZfGCBYHMTFHyE87raGywvz/AxfCm4iqL3kQazHt1npjgXHlLajnSf Pd2GIwe1meVCiuuxZ3KMdkxFO9O2a+JLKeE9bpSDT6GkgdhvAGMU3qujcv6t29j0H/R2 V3MS2ICBE/PHbdV0i6OcVUAjEHlSw6NHOGEGGh7pKNRKDQhvunDiCeP2A2RvJRssvyMk XzEq2UBM/UYmgpDy7Co2spLrX1WhTB5yBoO7YH3rTbJ5axNmMO9hldJB16YCQkvW26jo z7jQ== 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:date:to:from:subject:message-id; bh=4vrzoi1fDP7WLhKNqSBE4HYnX8B/Q3/+yXefyCJWwsY=; b=zQk4VZCseHpx9d/vLzpZ/4o2zkuvTOnCnzuE1J/CxsU6bO2uZ/a3urpQX57ekVQMrB VBv8wb4O+FsZvGl/6pzXjlG6Ufq0rftz/U1Get3TbsnQVYQzcA/ak2heck4nOpcIR35n SVlqyWuoQNX21ft6nbkr4/gAigdxViT7PBf4tDjgAN4P/144zBhPZbnuv/ALzo9PMBkS 77Ce/2asV4YoBEnVm3GR9LeETI0BZjE7qEzDWhULGxQ2ANV3/1f+QWtM6pHtBDVD2XuW y4MWAde1M8n2Det+CVsNix8YvM6gMZOugFPtD86uJrh2/7HT2KHngP1n2bGTvjoHmcyX YhIg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v26si2915088ejq.623.2021.05.17.07.16.05; Mon, 17 May 2021 07:16:30 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235570AbhEQNRo (ORCPT + 99 others); Mon, 17 May 2021 09:17:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235470AbhEQNRn (ORCPT ); Mon, 17 May 2021 09:17:43 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8CADC061573; Mon, 17 May 2021 06:16:27 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1lid6Y-00ALU5-VK; Mon, 17 May 2021 15:16:19 +0200 Message-ID: <048c4fb6c91931e9fcd240df7a5586633893c31a.camel@sipsolutions.net> Subject: Re: [syzbot] divide error in mac80211_hwsim_bss_info_changed From: Johannes Berg To: syzbot , davem@davemloft.net, kuba@kernel.org, kvalo@codeaurora.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com Date: Mon, 17 May 2021 15:16:17 +0200 In-Reply-To: <000000000000fb328005c2844acc@google.com> (sfid-20210517_124535_257596_E84F0A94) References: <000000000000fb328005c2844acc@google.com> (sfid-20210517_124535_257596_E84F0A94) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 2021-05-17 at 03:45 -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: eebe426d Merge tag 'fixes-for-5.12-rc7' of git://git.kerne.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15e73ceed00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9c3d8981d2bdb103 > dashboard link: https://syzkaller.appspot.com/bug?extid=26727b5e00947e02242c > compiler: Debian clang version 11.0.1-2 > > Unfortunately, I don't have any reproducer for this issue yet. > That's not very surprising ... > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+26727b5e00947e02242c@syzkaller.appspotmail.com > > divide error: 0000 [#1] PREEMPT SMP KASAN > CPU: 1 PID: 13049 Comm: kworker/u4:16 Not tainted 5.12.0-rc7-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Workqueue: phy10 ieee80211_roc_work > RIP: 0010:mac80211_hwsim_bss_info_changed+0x514/0xf90 drivers/net/wireless/mac80211_hwsim.c:2024 The issue here is that we have the following code in offchannel.c: mutex_lock(&local->iflist_mtx); list_for_each_entry(sdata, &local->interfaces, list) { ... if (test_and_clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state)) { sdata->vif.bss_conf.enable_beacon = true; ieee80211_bss_info_change_notify( sdata, BSS_CHANGED_BEACON_ENABLED); } However, we have the following code in ibss.c ieee80211_ibss_disconnect(): sdata->vif.bss_conf.ibss_joined = false; sdata->vif.bss_conf.ibss_creator = false; sdata->vif.bss_conf.enable_beacon = false; sdata->vif.bss_conf.ssid_len = 0; /* remove beacon */ presp = rcu_dereference_protected(ifibss->presp, lockdep_is_held(&sdata->wdev.mtx)); RCU_INIT_POINTER(sdata->u.ibss.presp, NULL); if (presp) kfree_rcu(presp, rcu_head); clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state); ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED | BSS_CHANGED_IBSS); There's no common locking here, so it's simply racy. Normally, all of the ieee80211_ibss_disconnect() happens together, but if ieee80211_offchannel_return() happens to hit here before SDATA_STATE_OFFCHANNEL_BEACON_STOPPED is cleared, we might inadvertently enable beaconing while the interface is actually stopping. I'm not really sure what happens next, but perhaps the interface is going down and the beacon_int is reset to 0, or such, leading to the problem at hand. Off the top of my head, I don't really have a good idea about how to fix this - we'd want to add some more consistent locking everywhere. I assume that with the rtnl-weaning having happened, that might simply consist in aligning mac80211 to the cfg80211 wiphy mutex everywhere. johannes