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

[Jan Kara]

On Tue 08-04-25 12:29:23, Christian Brauner wrote:
> On Tue, Apr 08, 2025 at 02:01:29AM -0700, syzbot wrote:
> > 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+dbb3b5b8e91c5be8daad@xxxxxxxxxxxxxxxxxxxxxxxxx
> > 
> > ==================================================================
> > 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
> 
> 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?

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 <jack@xxxxxxxx>
SUSE Labs, CR