linux-kernel - Re: [BUG] Data race on delayed_refs->num_heads_ready between btrfs_delete_ref_head and btrfs_run_delayed

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] [day] [month] [year] [list]

Message-ID: <CAL3q7H5NtJ+0eB6HzLw-JAewBSA8V8jZbPMapdwUA+P5axg+7g@mail.gmail.com>
Date: Mon, 12 May 2025 12:53:25 +0100
From: Filipe Manana <fdmanana@...nel.org>
To: cen zhang <zzzccc427@...il.com>
Cc: clm@...com, josef@...icpanda.com, dsterba@...e.com, 
	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org, 
	baijiaju1990@...il.com, zhenghaoran154@...il.com
Subject: Re: [BUG] Data race on delayed_refs->num_heads_ready between
 btrfs_delete_ref_head and btrfs_run_delayed_refs

On Sat, May 10, 2025 at 8:48 AM cen zhang <zzzccc427@...il.com> wrote:
>
> Hello maintainers,
>
> I would like to report a data race bug detected in
> the Btrfs filesystem on Linux kernel 6.14-rc4.
> The issue was discovered by our tools,
> which identified unsynchronized concurrent accesses to
> `delayed_refs->num_heads_ready`.
>
> The relevant stack trace detail is as follows:
>
> ===========================DATARACE===========================
> Function: btrfs_delete_ref_head+0x164/0x180 fs/btrfs/delayed-ref.c:550
> Function: check_ref_cleanup+0x178/0x290 fs/btrfs/extent-tree.c:3381
> Function: btrfs_free_tree_block+0x334/0x7f0 fs/btrfs/extent-tree.c:3444
> Function: btrfs_quota_disable+0x4d2/0x750 fs/btrfs/qgroup.c:1414
> Function: btrfs_ioctl_quota_ctl+0x18f/0x1f0 fs/btrfs/ioctl.c:3707
> Function: btrfs_ioctl+0x943/0xe40 fs/btrfs/ioctl.c:5325
> Function: vfs_ioctl fs/ioctl.c:51 [inline]
> Function: __do_sys_ioctl fs/ioctl.c:906 [inline]
> Function: __se_sys_ioctl+0x91/0xf0 fs/ioctl.c:892
> Function: do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> Function: do_syscall_64+0xc9/0x1a0 arch/x86/entry/common.c:83
> Function: entry_SYSCALL_64_after_hwframe+0x77/0x7f
> Function: 0x0
> ========================
>  __btrfs_run_delayed_refs+0xe0/0x1a50 fs/btrfs/extent-tree.c:2015
>  btrfs_run_delayed_refs+0xd1/0x2b0 fs/btrfs/extent-tree.c:2158
>  btrfs_commit_transaction+0x27a/0x1c40 fs/btrfs/transaction.c:2196
>  del_balance_item fs/btrfs/volumes.c:3810 [inline]
>  reset_balance_state+0x193/0x240 fs/btrfs/volumes.c:3874
>  btrfs_balance+0x1698/0x1770 fs/btrfs/volumes.c:4706
>  btrfs_ioctl_balance+0x290/0x470 fs/btrfs/ioctl.c:3587
>  btrfs_ioctl+0xcaf/0xe40 fs/btrfs/ioctl.c:5305
>  vfs_ioctl fs/ioctl.c:51 [inline]
>  __do_sys_ioctl fs/ioctl.c:906 [inline]
>  __se_sys_ioctl+0x91/0xf0 fs/ioctl.c:892
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xc9/0x1a0 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> =================================
>
> The code locations involved in the data race are:
>
> Write (fs/btrfs/delayed-ref.c):
>
> if (!head->processing)
>     delayed_refs->num_heads_ready--;
>
> Reader (fs/btrfs/extent-tree.c):
>
> delayed_refs = &trans->transaction->delayed_refs;
> if (min_bytes == 0) {
>     max_count = delayed_refs->num_heads_ready;
>     ...
> }
>
> I’ve verified that this issue still exists in the latest source tree as follows
>
> Write (fs/btrfs/delayed-ref.c):
>
> 548        if (!head->processing)
> 549                delayed_refs->num_heads_ready--;
>
> Reader (fs/btrfs/extent-tree.c):
>
> 2007        delayed_refs = &trans->transaction->delayed_refs;
> 2008        if (min_bytes == 0) {
> 2009                max_count = delayed_refs->num_heads_ready;
> 2010                min_bytes = U64_MAX;
> 2011        }

It's a harmless race. We can silence KCSAN and such tools with a
data_race() annotation there.

Patch sent:    https://lore.kernel.org/linux-btrfs/13e40ba1be5f87e2b79275f58f4defe11e6bd62d.1747050634.git.fdmanana@suse.com/

Thanks.

>
> Thank you for your attention to this matter.
>
> Best regards,
> Cen Zhang
>