[syzbot] [fs?] KCSAN: data-race in file_end_write / posix_acl_update_mode

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 0af2f6be1b42 Linux 6.15-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10c98070580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e5bf3e2a48bfe768
dashboard link: https://syzkaller.appspot.com/bug?extid=dbb3b5b8e91c5be8daad
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d90ae40aa6df/disk-0af2f6be.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/616ed7a70804/vmlinux-0af2f6be.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ed2c418afc9a/bzImage-0af2f6be.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+dbb3b5...@syzkaller.appspotmail.com

==================================================================
BUG: KCSAN: data-race in file_end_write / posix_acl_update_mode

write to 0xffff888118513aa0 of 2 bytes by task 16080 on cpu 1:
posix_acl_update_mode+0x220/0x250 fs/posix_acl.c:720
simple_set_acl+0x6c/0x120 fs/posix_acl.c:1022
set_posix_acl fs/posix_acl.c:954 [inline]
vfs_set_acl+0x581/0x720 fs/posix_acl.c:1133
do_set_acl+0xab/0x130 fs/posix_acl.c:1278
do_setxattr fs/xattr.c:633 [inline]
filename_setxattr+0x1f1/0x2b0 fs/xattr.c:665
path_setxattrat+0x28a/0x320 fs/xattr.c:713
__do_sys_setxattr fs/xattr.c:747 [inline]
__se_sys_setxattr fs/xattr.c:743 [inline]
__x64_sys_setxattr+0x6e/0x90 fs/xattr.c:743
x64_sys_call+0x28e7/0x2e10 arch/x86/include/generated/asm/syscalls_64.h:189
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xc9/0x1c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff888118513aa0 of 2 bytes by task 16073 on cpu 0:
file_end_write+0x1f/0x110 include/linux/fs.h:3059
vfs_fallocate+0x3a5/0x3b0 fs/open.c:350
ksys_fallocate fs/open.c:362 [inline]
__do_sys_fallocate fs/open.c:367 [inline]
__se_sys_fallocate fs/open.c:365 [inline]
__x64_sys_fallocate+0x78/0xc0 fs/open.c:365
x64_sys_call+0x295f/0x2e10 arch/x86/include/generated/asm/syscalls_64.h:286
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xc9/0x1c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x8000 -> 0x8072

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 16073 Comm: syz.6.3255 Not tainted 6.15.0-rc1-syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Christian Brauner]

This race is benign.
file_end_write() and similar helpers check whether this is a regular
file or not. And the type of a file can never change. The only thing
that can change here are the permission bits of course.

The only thing to worry about would be torn writes where somehow the
file type is written back after the permission bits and so S_ISREG()
could fail and the freeze protection semaphore wouldn't be released. If
that is an actual possibility we'd need to READ_ONCE()/WRITE_ONCE() the
hell out of this. Can this really happen with an unsigned short though?

[Jan Kara]

Well, it is one of those things that "standards do not prohibit the
compiler from doing this". OTOH it would be quite insane compiler to do
this kind of thing so I'm not sure it's worth all the churn...

Honza
--
Jan Kara <ja...@suse.com>
SUSE Labs, CR

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.