Thread (6 messages) 6 messages, 4 authors, 2022-11-30

Re: [syzbot] KASAN: use-after-free Read in rfkill_blocked

From: Krzysztof Kozlowski <hidden>
Date: 2022-11-28 10:15:26
Also in: linux-wireless, lkml

On 28/11/2022 11:07, Dmitry Vyukov wrote:
On Sun, 27 Nov 2022 at 20:59, Krzysztof Kozlowski
[off-list ref] wrote:
quoted
On 25/11/2022 10:09, Johannes Berg wrote:
quoted
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:
quoted
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:
[<ffffffff8000a228>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:113
[<ffffffff831668cc>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:119
[<ffffffff831756ba>] __dump_stack lib/dump_stack.c:88 [inline]
[<ffffffff831756ba>] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:106
[<ffffffff8047479e>] print_address_description.constprop.0+0x2a/0x330 mm/kasan/report.c:255
[<ffffffff80474d4c>] __kasan_report mm/kasan/report.c:442 [inline]
[<ffffffff80474d4c>] kasan_report+0x184/0x1e0 mm/kasan/report.c:459
[<ffffffff80475b20>] check_region_inline mm/kasan/generic.c:183 [inline]
[<ffffffff80475b20>] __asan_load8+0x6e/0x96 mm/kasan/generic.c:256
[<ffffffff80112b70>] __lock_acquire+0x8ee/0x333e kernel/locking/lockdep.c:4897
[<ffffffff80116582>] lock_acquire.part.0+0x1d0/0x424 kernel/locking/lockdep.c:5639
[<ffffffff8011682a>] lock_acquire+0x54/0x6a kernel/locking/lockdep.c:5612
[<ffffffff831afa2c>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
[<ffffffff831afa2c>] _raw_spin_lock_irqsave+0x3e/0x62 kernel/locking/spinlock.c:162
[<ffffffff83034f0a>] rfkill_blocked+0x22/0x62 net/rfkill/core.c:941
[<ffffffff830b8862>] nfc_dev_up+0x8e/0x26c net/nfc/core.c:102
[<ffffffff830bb742>] nfc_genl_dev_up+0x5e/0x8a net/nfc/netlink.c:770
[<ffffffff8296f9ae>] genl_family_rcv_msg_doit+0x19a/0x23c net/netlink/genetlink.c:731
[<ffffffff82970420>] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
[<ffffffff82970420>] genl_rcv_msg+0x236/0x3ba net/netlink/genetlink.c:792
[<ffffffff8296ded2>] netlink_rcv_skb+0xf8/0x2be net/netlink/af_netlink.c:2494
[<ffffffff8296ecb2>] genl_rcv+0x36/0x4c net/netlink/genetlink.c:803
[<ffffffff8296cbcc>] netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
[<ffffffff8296cbcc>] netlink_unicast+0x40e/0x5fe net/netlink/af_netlink.c:1343
[<ffffffff8296d29c>] netlink_sendmsg+0x4e0/0x994 net/netlink/af_netlink.c:1919
[<ffffffff826d264e>] sock_sendmsg_nosec net/socket.c:705 [inline]
[<ffffffff826d264e>] sock_sendmsg+0xa0/0xc4 net/socket.c:725
[<ffffffff826d4dd4>] ____sys_sendmsg+0x46e/0x484 net/socket.c:2413
[<ffffffff826d8bca>] ___sys_sendmsg+0x16c/0x1f6 net/socket.c:2467
[<ffffffff826d8e78>] __sys_sendmsg+0xba/0x150 net/socket.c:2496
[<ffffffff826d8f3a>] __do_sys_sendmsg net/socket.c:2505 [inline]
[<ffffffff826d8f3a>] sys_sendmsg+0x2c/0x3a net/socket.c:2503
[<ffffffff80005716>] 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?
Both, although maybe not this particular issue. There were like five
separate reports last few days...
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.
Earlier this year there was a bigger fix for unregister path in NFC -
see commits:
da5c0f119203 (nfc_unregister_device+nfc_fw_download
ef27324e2c (nci_unregister_device+nci_cmd_work)
1b0e81416 (rfkill related)
and these pointed out inherent issues in locking/synchronization of NFC
core modules. I don't think we fixed all of the core issues, rather only
what was reported, so some specific scenarios.
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.
Mentioned 1b0e81416a tried to do this and that time I had impression fix
is correct. However it seems it is not... (or not enough)

Best regards,
Krzysztof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help