linux-kernel - Re: [syzbot] KCSAN: data-race in sbitmap_queue_clear / sbitmap_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Oct 2021 07:35:59 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     syzbot <syzbot+4f8bfd804b4a1f95b8f6@...kaller.appspotmail.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] KCSAN: data-race in sbitmap_queue_clear /
 sbitmap_queue_clear (3)

On 10/25/21 5:16 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    2f111a6fd5b5 Merge tag 'ceph-for-5.15-rc7' of git://github..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10dae330b00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b2868748300e5cf6
> dashboard link: https://syzkaller.appspot.com/bug?extid=4f8bfd804b4a1f95b8f6
> compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
> 
> 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+4f8bfd804b4a1f95b8f6@...kaller.appspotmail.com
> 
> ==================================================================
> BUG: KCSAN: data-race in sbitmap_queue_clear / sbitmap_queue_clear
> 
> write to 0xffffe8ffffd145b8 of 4 bytes by interrupt on cpu 1:
>  sbitmap_queue_clear+0xca/0xf0 lib/sbitmap.c:606
>  blk_mq_put_tag+0x82/0x90
>  __blk_mq_free_request+0x114/0x180 block/blk-mq.c:507
>  blk_mq_free_request+0x2c8/0x340 block/blk-mq.c:541
>  __blk_mq_end_request+0x214/0x230 block/blk-mq.c:565
>  blk_mq_end_request+0x37/0x50 block/blk-mq.c:574
>  lo_complete_rq+0xca/0x170 drivers/block/loop.c:541
>  blk_complete_reqs block/blk-mq.c:584 [inline]
>  blk_done_softirq+0x69/0x90 block/blk-mq.c:589
>  __do_softirq+0x12c/0x26e kernel/softirq.c:558
>  run_ksoftirqd+0x13/0x20 kernel/softirq.c:920
>  smpboot_thread_fn+0x22f/0x330 kernel/smpboot.c:164
>  kthread+0x262/0x280 kernel/kthread.c:319
>  ret_from_fork+0x1f/0x30
> 
> write to 0xffffe8ffffd145b8 of 4 bytes by interrupt on cpu 0:
>  sbitmap_queue_clear+0xca/0xf0 lib/sbitmap.c:606
>  blk_mq_put_tag+0x82/0x90
>  __blk_mq_free_request+0x114/0x180 block/blk-mq.c:507
>  blk_mq_free_request+0x2c8/0x340 block/blk-mq.c:541
>  __blk_mq_end_request+0x214/0x230 block/blk-mq.c:565
>  blk_mq_end_request+0x37/0x50 block/blk-mq.c:574
>  lo_complete_rq+0xca/0x170 drivers/block/loop.c:541
>  blk_complete_reqs block/blk-mq.c:584 [inline]
>  blk_done_softirq+0x69/0x90 block/blk-mq.c:589
>  __do_softirq+0x12c/0x26e kernel/softirq.c:558
>  run_ksoftirqd+0x13/0x20 kernel/softirq.c:920
>  smpboot_thread_fn+0x22f/0x330 kernel/smpboot.c:164
>  kthread+0x262/0x280 kernel/kthread.c:319
>  ret_from_fork+0x1f/0x30

This is just a per-cpu alloc hint, it's racy by nature. What's the
preferred way to silence these?

-- 
Jens Axboe