Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14539217rwb; Mon, 28 Nov 2022 02:12:01 -0800 (PST) X-Google-Smtp-Source: AA0mqf7MTN1FjiyxVdNJowV2dCnCkpAwsAoW2EJcrdTsSNeUr5yKJ00mWu/4Jf8JlklYSFmB3GPZ X-Received: by 2002:a17:906:3982:b0:7ad:8bc6:46e7 with SMTP id h2-20020a170906398200b007ad8bc646e7mr44919105eje.28.1669630321313; Mon, 28 Nov 2022 02:12:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669630321; cv=none; d=google.com; s=arc-20160816; b=EaOiD6UOawtpDzlfHexxNMBqOXY0WjWhljHNSeam7QmYV9+SVWMSTRhBllgko9yrCp +l/BNksYTS4MFT6+Gua8QWSrZ5dE93AW/+iVWMyj+F1mv4i6gWSADsjriCiU8j+B2Bdc xeQRiKWQaQOkEFvg89XELdXF7XUYuEH8GIP/9lxySOlqK5WEcZwTkZvnqoTgDqnSIAe2 Uk4SaliEdFRVUUDAXvUytER1KS9pvQLCt8tlm0yH7gwhThOBNC0xc7MyF2374w6YubmQ Kfs2cJ4XDr10IO2TfmUl3+PMLRJaXoCiPr9F2UszLNc6NtjQkIDgvokNELp8Vv/eNd8J 3wfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2iZJVoc7675ssfCNuJNy1f8+4/MFSblSBo6DzIyzGW8=; b=gFAMifwaSIDc0qEXsoJqeNiRhLncC8Fpz+uelTTW8gbNrQz6dqzNOfZab4VYlcqctZ grAtQqomIGOejXS/rXzzukFyecFxBEHA7VBpS68Zklt0XKQ8D9n0U8uN72ByKoj3D+JU +DBptzY7ipwIbwf1NDcqjHjVCjqtJXob86QOYJr98NM9wiI2RefjiYy/LD0hjAITstBw dMuVwG0Txmztd2aTGx5JZYztgZ5nGoAYTGP37Tx6WxwVZKI9QbXMRoHZ1gEO9WWUBUap BkwbS693Yqc3ZYr+nMQtL8OofW/uRiwhvB0qqiDlaC2R+vDCotDbpMsir+QuhNNqnl8A a9iA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=YD0UkDV9; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id wu9-20020a170906eec900b007ae377adb6asi8476427ejb.628.2022.11.28.02.11.44; Mon, 28 Nov 2022 02:12:01 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=YD0UkDV9; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229911AbiK1KHj (ORCPT + 67 others); Mon, 28 Nov 2022 05:07:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229752AbiK1KHh (ORCPT ); Mon, 28 Nov 2022 05:07:37 -0500 Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DED012BFA for ; Mon, 28 Nov 2022 02:07:35 -0800 (PST) Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-142306beb9aso12342809fac.11 for ; Mon, 28 Nov 2022 02:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2iZJVoc7675ssfCNuJNy1f8+4/MFSblSBo6DzIyzGW8=; b=YD0UkDV9DmuOOVSBy88tYRqL/1jk9URzA9XQHleB1MPAqpNoQBvUfK5x7dNUuDs/5d DmHxIJTcnAEq36GFdJ52rkdDhtImiLTT7/+yJa8gmdj1b+8ae73mfsWaUXr0ek/YYfY2 nhhCMPqRWtSWIV3oEwV2Mdny26dINNvoCwzUp46V6zeXcCXYe1GCAluqIUNg/04EE/v9 aEhuOXCn5bvffMNifUSgNDhkj1ymCuuSHEpOQ/LttrGZkZcmtZ0VxFuNohymVFNtWaeo QjInWz3K7IqGH0SVH/4pietFjUSzwSg/oFYJfkftNKwP/q21GWe+Y/j1arziOZr9ib4P 0ndA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2iZJVoc7675ssfCNuJNy1f8+4/MFSblSBo6DzIyzGW8=; b=jssGTukhV5qWHW5cZmhN6ZcXg+UWq8h7oeTbEfYbYU3uzh9S1hztRscQJ43byMGa68 n5o9yelR2Drg/H06AgHaaFIYiDgsbs/up1KoWHyaknBBHbai/R2+R6tnUUMo1++JvMqB 9BnKWKu55pM+RnMSb0m5GSqZwsgxI1HSYLyAJOE0VrGhw79lFNJbAixsIl1qiwDlmbFk vsqTZsSrveNvM6yQsh5MhoHYIRaY1Xgi26Icp3OU/iw6Lv+yqKBYKFJVEfRv/9xFOGMZ jpnVdGyoorWtt0uXmrbN0SV92ZGe2GBJvjcY815KIRz0kQhceoG4na06SXO1r6BF8q07 Q7/Q== X-Gm-Message-State: ANoB5pmN1ODTcF0W6ToBZ1P1ZDQTjkhTYjscBU0YsVY9J0K99/8GAp+f ZUkHiGxC9qiZl2TLFwoI6IAaGlKPZBzB2gu+vmBdTQ== X-Received: by 2002:a05:6871:4609:b0:143:955d:ed7 with SMTP id nf9-20020a056871460900b00143955d0ed7mr4434805oab.233.1669630054629; Mon, 28 Nov 2022 02:07:34 -0800 (PST) MIME-Version: 1.0 References: <000000000000790da005ee3175a8@google.com> <26b9771db88198ff982476e3e24f411277cd213b.camel@sipsolutions.net> <0ee688ac-5c34-1592-23d3-fe100cadc570@linaro.org> In-Reply-To: <0ee688ac-5c34-1592-23d3-fe100cadc570@linaro.org> From: Dmitry Vyukov Date: Mon, 28 Nov 2022 11:07:23 +0100 Message-ID: Subject: Re: [syzbot] KASAN: use-after-free Read in rfkill_blocked To: Krzysztof Kozlowski Cc: Johannes Berg , syzbot , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Sun, 27 Nov 2022 at 20:59, Krzysztof Kozlowski wrote: > > On 25/11/2022 10:09, Johannes Berg wrote: > > Looks like an NFC issue to me, Krzysztof? > > > > I mean, rfkill got allocated by nfc_register_device(), freed by > > nfc_unregister_device(), and then used by nfc_dev_up(). Seems like the > > last bit shouldn't be possible after nfc_unregister_device()? > > > > johannes > > > > On Wed, 2022-11-23 at 22:24 -0800, syzbot wrote: > >> Hello, > >> > >> syzbot found the following issue on: > >> > >> HEAD commit: 0966d385830d riscv: Fix auipc+jalr relocation range checks > >> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >> console output: https://syzkaller.appspot.com/x/log.txt?x=11196d0d880000 > >> kernel config: https://syzkaller.appspot.com/x/.config?x=6295d67591064921 > >> dashboard link: https://syzkaller.appspot.com/bug?extid=0299462c067009827b2a > >> compiler: riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > >> userspace arch: riscv64 > >> > >> Unfortunately, I don't have any reproducer for this issue yet. > >> > >> IMPORTANT: if you fix the issue, please add the following tag to the commit: > >> Reported-by: syzbot+0299462c067009827b2a@syzkaller.appspotmail.com > >> > >> ================================================================== > >> BUG: KASAN: use-after-free in __lock_acquire+0x8ee/0x333e kernel/locking/lockdep.c:4897 > >> Read of size 8 at addr ffffaf8024249018 by task syz-executor.0/7946 > >> > >> CPU: 0 PID: 7946 Comm: syz-executor.0 Not tainted 5.17.0-rc1-syzkaller-00002-g0966d385830d #0 > >> Hardware name: riscv-virtio,qemu (DT) > >> Call Trace: > >> [] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:113 > >> [] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:119 > >> [] __dump_stack lib/dump_stack.c:88 [inline] > >> [] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:106 > >> [] print_address_description.constprop.0+0x2a/0x330 mm/kasan/report.c:255 > >> [] __kasan_report mm/kasan/report.c:442 [inline] > >> [] kasan_report+0x184/0x1e0 mm/kasan/report.c:459 > >> [] check_region_inline mm/kasan/generic.c:183 [inline] > >> [] __asan_load8+0x6e/0x96 mm/kasan/generic.c:256 > >> [] __lock_acquire+0x8ee/0x333e kernel/locking/lockdep.c:4897 > >> [] lock_acquire.part.0+0x1d0/0x424 kernel/locking/lockdep.c:5639 > >> [] lock_acquire+0x54/0x6a kernel/locking/lockdep.c:5612 > >> [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > >> [] _raw_spin_lock_irqsave+0x3e/0x62 kernel/locking/spinlock.c:162 > >> [] rfkill_blocked+0x22/0x62 net/rfkill/core.c:941 > >> [] nfc_dev_up+0x8e/0x26c net/nfc/core.c:102 > >> [] nfc_genl_dev_up+0x5e/0x8a net/nfc/netlink.c:770 > >> [] genl_family_rcv_msg_doit+0x19a/0x23c net/netlink/genetlink.c:731 > >> [] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] > >> [] genl_rcv_msg+0x236/0x3ba net/netlink/genetlink.c:792 > >> [] netlink_rcv_skb+0xf8/0x2be net/netlink/af_netlink.c:2494 > >> [] genl_rcv+0x36/0x4c net/netlink/genetlink.c:803 > >> [] netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] > >> [] netlink_unicast+0x40e/0x5fe net/netlink/af_netlink.c:1343 > >> [] netlink_sendmsg+0x4e0/0x994 net/netlink/af_netlink.c:1919 > >> [] sock_sendmsg_nosec net/socket.c:705 [inline] > >> [] sock_sendmsg+0xa0/0xc4 net/socket.c:725 > >> [] ____sys_sendmsg+0x46e/0x484 net/socket.c:2413 > >> [] ___sys_sendmsg+0x16c/0x1f6 net/socket.c:2467 > >> [] __sys_sendmsg+0xba/0x150 net/socket.c:2496 > >> [] __do_sys_sendmsg net/socket.c:2505 [inline] > >> [] sys_sendmsg+0x2c/0x3a net/socket.c:2503 > >> [] ret_from_syscall+0x0/0x2 > >> > >> Allocated by task 7946: > >> stack_trace_save+0xa6/0xd8 kernel/stacktrace.c:122 > >> kasan_save_stack+0x2c/0x58 mm/kasan/common.c:38 > >> kasan_set_track mm/kasan/common.c:45 [inline] > >> set_alloc_info mm/kasan/common.c:436 [inline] > >> ____kasan_kmalloc mm/kasan/common.c:515 [inline] > >> ____kasan_kmalloc mm/kasan/common.c:474 [inline] > >> __kasan_kmalloc+0x80/0xb2 mm/kasan/common.c:524 > >> kasan_kmalloc include/linux/kasan.h:270 [inline] > >> __kmalloc+0x190/0x318 mm/slub.c:4424 > >> kmalloc include/linux/slab.h:586 [inline] > >> kzalloc include/linux/slab.h:715 [inline] > >> rfkill_alloc+0x96/0x1aa net/rfkill/core.c:983 > >> nfc_register_device+0xe4/0x29e net/nfc/core.c:1129 > >> nci_register_device+0x538/0x612 net/nfc/nci/core.c:1252 > >> virtual_ncidev_open+0x82/0x12c drivers/nfc/virtual_ncidev.c:143 > >> misc_open+0x272/0x2c8 drivers/char/misc.c:141 > >> chrdev_open+0x1d4/0x478 fs/char_dev.c:414 > >> do_dentry_open+0x2a4/0x7d4 fs/open.c:824 > >> vfs_open+0x52/0x5e fs/open.c:959 > >> do_open fs/namei.c:3476 [inline] > >> path_openat+0x12b6/0x189e fs/namei.c:3609 > >> do_filp_open+0x10e/0x22a fs/namei.c:3636 > >> do_sys_openat2+0x174/0x31e fs/open.c:1214 > >> do_sys_open fs/open.c:1230 [inline] > >> __do_sys_openat fs/open.c:1246 [inline] > >> sys_openat+0xdc/0x164 fs/open.c:1241 > >> ret_from_syscall+0x0/0x2 > >> > >> Freed by task 7944: > >> stack_trace_save+0xa6/0xd8 kernel/stacktrace.c:122 > >> kasan_save_stack+0x2c/0x58 mm/kasan/common.c:38 > >> kasan_set_track+0x1a/0x26 mm/kasan/common.c:45 > >> kasan_set_free_info+0x1e/0x3a mm/kasan/generic.c:370 > >> ____kasan_slab_free mm/kasan/common.c:366 [inline] > >> ____kasan_slab_free+0x15e/0x180 mm/kasan/common.c:328 > >> __kasan_slab_free+0x10/0x18 mm/kasan/common.c:374 > >> kasan_slab_free include/linux/kasan.h:236 [inline] > >> slab_free_hook mm/slub.c:1728 [inline] > >> slab_free_freelist_hook+0x8e/0x1cc mm/slub.c:1754 > >> slab_free mm/slub.c:3509 [inline] > >> kfree+0xe0/0x3e4 mm/slub.c:4562 > >> rfkill_release+0x20/0x2a net/rfkill/core.c:831 > >> device_release+0x66/0x148 drivers/base/core.c:2229 > >> kobject_cleanup lib/kobject.c:705 [inline] > >> kobject_release lib/kobject.c:736 [inline] > >> kref_put include/linux/kref.h:65 [inline] > >> kobject_put+0x1bc/0x38e lib/kobject.c:753 > >> put_device+0x28/0x3a drivers/base/core.c:3512 > >> rfkill_destroy+0x2a/0x3c net/rfkill/core.c:1142 > >> nfc_unregister_device+0xac/0x232 net/nfc/core.c:1167 > >> nci_unregister_device+0x168/0x182 net/nfc/nci/core.c:1298 > >> virtual_ncidev_close+0x9c/0xbc drivers/nfc/virtual_ncidev.c:163 > > There were several issues found recently in virtual NCI driver, so this > might be one of them. There is no reproducer, though... Hi Krzysztof, Do you think it's related specifically to the virtual driver? I would assume it's a bug in the NCI core itself related to dynamic device destructions. This should affect e.g. USB devices as well. It's an issue only in the virtual driver. It means that the virtual driver uses the NCI core incorrectly, not the way all real drivers use it. If so the question is: what is the difference? We need to fix it. It's not useful to have unrealistic test drivers -- we both get false positives and don't get true positives. I think the issue may be localized from the KASAN report itself w/o a reproducer. Is there proper synchronization between nfc_unregister_device/rfkill_destroy and nfc_dev_up/rfkill_blocked? Something that prevents rfkill_blocked to be called after rfkill_destroy? If not, then that's the issue.