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

Message-ID: <CAFRLqsUCLMz0hY-GaPj1Z=fhkgRHjxVXHZ8kz0PvkFN0b=8L2Q@mail.gmail.com>
Date: Sat, 10 May 2025 15:48:00 +0800
From: cen zhang <zzzccc427@...il.com>
To: clm@...com, josef@...icpanda.com, dsterba@...e.com
Cc: linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org, 
	baijiaju1990@...il.com, zhenghaoran154@...il.com
Subject: [BUG] Data race on delayed_refs->num_heads_ready between
 btrfs_delete_ref_head and btrfs_run_delayed_refs

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        }

Thank you for your attention to this matter.

Best regards,
Cen Zhang