Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14901632rwb; Mon, 28 Nov 2022 06:09:39 -0800 (PST) X-Google-Smtp-Source: AA0mqf4GMXTSvBH90i7o21P+LdGPpLnmK9LJBVCdlKGscyCCXq0r+KKnxQL59sknuT3dX6C4tBUO X-Received: by 2002:a05:6402:5307:b0:461:e3e1:bc3b with SMTP id eo7-20020a056402530700b00461e3e1bc3bmr33198606edb.145.1669644579067; Mon, 28 Nov 2022 06:09:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669644579; cv=none; d=google.com; s=arc-20160816; b=K2iAofNoAitua2Lq6xeVVIkFgAxYj6eIoK6FtV9Ed1DniYey+D2hDjFDfG1hXgnZz9 GPCP7ubkEfbTlTqxKdwvXvQf1U5MuSAc9mRNRf079FRP8WtMiu3c8pweu0w8YBuyJaLH 5Pl+5hZtayc8rwFj76EdEL+eU/2y28kFunkCmtOLXb3s0FR/Z+hvCvSYmDWxeaGz4FY8 DuiDIu6Y+Pihx3SBWMvy/BGTlp8gsdhtf+Zq7eJmRFBCyW9UXqhMdbtpbApePPxYgi57 T3UsoI47lcY7nL0vFXITeK5uysiyeTJyqNRYTULTRexNcRULtlYjR+2Q8sKe6DwfxzzS xf5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=Rifyc2FUrf/Id+mCExiQoqXcFUXL3EFodH8e3oz9cOY=; b=rH7MPqXeIDuGlS6iZLsQWDv0BtLLI11/y4G/Vo4SDU9O4ZAtZQkS8MU5XpULrlafsx yHXCbAmqJqYQUZewAupC5rrebYAeJaZ9ehlnh/yAiPQ/nXcricCS4M1Zu+vzw8BHp2dK I3e0aIvHLzSxs2XztNLyyI5a4lDp6J0qVNsAcBuucSGxpHsOEIdLGvnavpjlbxO2zZ/j 6jNreKSL1ip7kFcLn18F/Gr8Tn94EL0+s71zQVSzYnRs9UXuPBhmU2VKIXnPUu6Y/0zf oOboORfC02tHW2Gc6xupm9urVef9zfNkvAwxn+lWXJrOnyVcTnb8EEdeL7FN3Hl3WumL sKNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ez8-20020a056402450800b0046b13a74fa8si3373864edb.416.2022.11.28.06.09.19; Mon, 28 Nov 2022 06:09:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231897AbiK1OBp (ORCPT + 67 others); Mon, 28 Nov 2022 09:01:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231185AbiK1OBn (ORCPT ); Mon, 28 Nov 2022 09:01:43 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43CA5B7E; Mon, 28 Nov 2022 06:01:41 -0800 (PST) Received: from dggpeml500023.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NLRqk517qzqSfk; Mon, 28 Nov 2022 21:57:38 +0800 (CST) Received: from [10.174.176.83] (10.174.176.83) by dggpeml500023.china.huawei.com (7.185.36.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 28 Nov 2022 22:01:39 +0800 Message-ID: <736584e7-571d-13f9-eb3e-34ce49e71e6c@huawei.com> Date: Mon, 28 Nov 2022 22:01:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH wireless] wifi: wilc1000: Fix UAF in wilc_netdev_cleanup() when iterator the RCU list To: Kalle Valo CC: , , , , , , , References: <20221124151349.2386077-1-zhangxiaoxu5@huawei.com> <88650c25-5358-1f03-dc96-fb7fc550fb18@huawei.com> <871qpn72lw.fsf@kernel.org> From: "zhangxiaoxu (A)" In-Reply-To: <871qpn72lw.fsf@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.83] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpeml500023.china.huawei.com (7.185.36.114) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 2022/11/28 19:14, Kalle Valo wrote: > "zhangxiaoxu (A)" writes: > >> On 2022/11/26 0:17, Ajay.Kathat@microchip.com wrote: >>> >>> On 24/11/22 20:43, Zhang Xiaoxu wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> There is a UAF read when remove the wilc1000_spi module: >>>> >>>> BUG: KASAN: use-after-free in wilc_netdev_cleanup.cold+0xc4/0xe0 [wilc1000] >>>> Read of size 8 at addr ffff888116846900 by task rmmod/386 >>>> >>>> CPU: 2 PID: 386 Comm: rmmod Tainted: G N 6.1.0-rc6+ #8 >>>> Call Trace: >>>> dump_stack_lvl+0x68/0x85 >>>> print_report+0x16c/0x4a3 >>>> kasan_report+0x95/0x190 >>>> wilc_netdev_cleanup.cold+0xc4/0xe0 >>>> wilc_bus_remove+0x52/0x60 >>>> spi_remove+0x46/0x60 >>>> device_remove+0x73/0xc0 >>>> device_release_driver_internal+0x12d/0x210 >>>> driver_detach+0x84/0x100 >>>> bus_remove_driver+0x90/0x120 >>>> driver_unregister+0x4f/0x80 >>>> __x64_sys_delete_module+0x2fc/0x440 >>>> do_syscall_64+0x38/0x90 >>>> entry_SYSCALL_64_after_hwframe+0x63/0xcd >>>> >>>> Since set 'needs_free_netdev=true' when initialize the net device, the >>>> net device will be freed when unregister, then use the freed 'vif' to >>>> find the next will UAF read. >>> >>> >>> Did you test this behaviour on the real device. I am seeing a kernel >>> crash when the module is unloaded after the connection with an AP. >> >> Thanks Ajay, I have no real device, what kind of crash about your >> scenario? > > If you don't have a real device to test on, please state that clearly in > the commit log. For example, "Compile tested only" or something like > that. Thanks Kalle, I found this problem with a bpf mock device, and test this patch use the same way. > > We get way too much untested patches where there's no indication that > they have had no testing. I'm really concerned about this trend, I'm > even considering should I just start dropping these kind of untested > cleanup patches? >