From nobody Thu Apr 9 04:03:25 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 932F93B637C; Wed, 11 Mar 2026 07:54:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215650; cv=none; b=snqfQT7623G9n/4mGH3slUmrxmoWmt5kZZd8VvOq9XRTKjJsPYHcA95jK+ww/WN9r7+1G62FbYwt+N1yy3uCwAyXFa+SRfSfumZ/XsoqmETF/XsoMWs3PXDuSp9f9AAwsim9SYjpgRqGwrmvfzPQx/QCbJAZ5AUGEt8qN+nUiDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215650; c=relaxed/simple; bh=skNWWmbc9+h+qi6WLHyh66ccES1vxHJD8cwqkG8Tn/c=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=TrWFwpC0LD5vMxn/VUJC0HJv+G0lOskOBmVlTvqOzzUWKmTQze0sqpPN2+2ax25fzQfV0RV6cX4KV6yDDYIUPrNhIT+ySGw+7GOuFNgX2GzV7bBEJ/UYvJrKK1R3x9vhqiMWxMA8au2fg9T80VMNqIHiVi/2FTEkDxMI3HGbE00= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=nYvkLpmV; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="nYvkLpmV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version: Message-ID; bh=skNWWmbc9+h+qi6WLHyh66ccES1vxHJD8cwqkG8Tn/c=; b=n YvkLpmVx2GY8ZEQgQIHHhhVlqokEDQmvj1BOuvXxkdHc/rM01bBPSjnD3KO0D1jU siGLSnWueEx64C0mvTGFk9TTefYPAyKwyiUyuaH2eUcV6OO8ULNyeoMRp2ESnnIC N2/b4eGd5BkjAxADuQ56pLsOnndSbiHGHqij9ji40w= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 15:53:47 +0800 (CST) Date: Wed, 11 Mar 2026 15:53:47 +0800 (CST) From: "Jianzhou Zhao" To: linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org Subject: BUG: KCSAN: data-race in ext4_fill_super / super_s_dev_test X-Priority: 3 X-Mailer: Coremail Webmail Server Version 2023.4-cmXT build 20251222(83accb85) Copyright (c) 2002-2026 www.mailtech.cn 163com X-NTES-SC: AL_Qu2cAf6auk4p4SiQYOkfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5Bifrwxzs6b+rT3Z4H5NBjrjWolyQ== Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <39269fa3.69b0.19cdbe33a75.Coremail.luckd0g@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgDn7ruLH7FpK792AA--.38990W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9guwO2mxH4vEngAA3g X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] fs: KCSAN: data-race in ext4_fill_super / super_s_dev_test Dear Maintainers, We are writing to report a KCSAN-detected data race vulnerability within th= e VFS and ext4 subsystem. This bug was found by our custom fuzzing tool, Ra= cePilot. The race occurs during the filesystem mount procedure when `ext4_c= heck_journal_data_mode` (via `ext4_fill_super`) sets `SB_I_CGROUPWB` in `sb= ->s_iflags` without strict synchronization, while `super_s_dev_test` contem= poraneously checks for the `SB_I_RETIRED` bit in the same `s_iflags` variab= le while iterating over `fs_supers`. We observed this bug on the Linux kern= el version 6.18.0-08691-g2061f18ad76e-dirty. Call Trace & Context =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KCSAN: data-race in ext4_fill_super / super_s_dev_test write to 0xffff88802f427058 of 8 bytes by task 25360 on cpu 1: ext4_check_journal_data_mode fs/ext4/super.c:5021 [inline] __ext4_fill_super fs/ext4/super.c:5364 [inline] ext4_fill_super+0x1308/0x7590 fs/ext4/super.c:5777 get_tree_bdev_flags+0x256/0x370 fs/super.c:1699 get_tree_bdev+0x1f/0x30 fs/super.c:1722 ext4_get_tree+0x1c/0x30 fs/ext4/super.c:5809 ... __x64_sys_mount+0x1d7/0x210 fs/namespace.c:4201 read to 0xffff88802f427058 of 8 bytes by task 25340 on cpu 0: super_s_dev_test+0x1c/0xa0 fs/super.c:1386 sget_fc+0x13a/0x6c0 fs/super.c:755 sget_dev fs/super.c:1413 [inline] get_tree_bdev_flags+0x124/0x370 fs/super.c:1685 get_tree_bdev+0x1f/0x30 fs/super.c:1722 ext4_get_tree+0x1c/0x30 fs/ext4/super.c:5809 ... __x64_sys_mount+0x1d7/0x210 fs/namespace.c:4201 value changed: 0x0000000000000000 -> 0x0000000000004001 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 25340 Comm: syz.1.1392 Not tainted 6.18.0-08691-g2061f18= ad76e-dirty #44 PREEMPT(voluntary)=20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/= 2014 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Execution Flow & Code Context During the mounting phase of a new ext4 instance, the system allocates a su= perblock and inserts it into the `fs_supers` list globally (handled in `sge= t_fc()`). Later, the `ext4_fill_super()` phase modifies `sb->s_iflags` conf= iguration properties directly. This happens without acquiring the `sb_lock`= which covers list traversals. Concretely, in `fs/ext4/super.c`: ```c // fs/ext4/super.c static int ext4_check_journal_data_mode(struct super_block *sb) { ... } else { sb->s_iflags |=3D SB_I_CGROUPWB; // <-- Plain concurrent write } return 0; } ``` Whenever another concurrent mount thread (or internal iteration) searches t= hrough existing superblocks for the block device via `sget_dev()`, it itera= tes over the linked structures calling `super_s_dev_test()`. `super_s_dev_t= est` inspects `s->s_iflags` to verify the retired status. ```c // fs/super.c static int super_s_dev_test(struct super_block *s, struct fs_context *fc) { return !(s->s_iflags & SB_I_RETIRED) && // <-- Plain concurrent read s->s_dev =3D=3D *(dev_t *)fc->sget_key; } ``` Root Cause Analysis A KCSAN data race arises because one thread configures the internal superbl= ock identifier flags concurrently while a secondary thread traverses the gl= obal list of superblocks scanning for active block devices. `s->s_iflags` a= cts as shared state globally visible through the filesystem subsystem list = from the point it gets listed in `sget_fc`. The read evaluation of `s_iflag= s` overlaps with the logical OR operation, establishing an undocumented rac= e. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This data race is functionally extremely minor or mostly benign since the r= ead only targets the `SB_I_RETIRED` bit, while the write sets the `SB_I_CGR= OUPWB` bit. However, the lack of annotations can trigger aggressive compile= r tearing implementations across architecture layouts, risking transient fa= lse `SB_I_RETIRED` positives causing unexpected remount disconnections. It = generates excessive fuzzing alerts that obscure critical concurrency flaws. Proposed Fix We can wrap the evaluation condition in `super_s_dev_test()` explicitly to = advise KCSAN and suppress the diagnostic alert effectively, affirming the c= oncurrent access is tracked by the developers and functionally verified. ```diff --- a/fs/super.c +++ b/fs/super.c @@ -1383,7 +1383,7 @@ static int super_s_dev_set(struct super_block *s, str= uct fs_context *fc) =20 static int super_s_dev_test(struct super_block *s, struct fs_context *fc) { - return !(s->s_iflags & SB_I_RETIRED) && + return !(data_race(s->s_iflags) & SB_I_RETIRED) && s->s_dev =3D=3D *(dev_t *)fc->sget_key; } ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team