linux-kernel - Re: [syzbot] [fs?] KCSAN: data-race in file_end_write / posix_acl_update

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

Message-ID: <20250408-stirn-wettkampf-1111f59d44e7@brauner>
Date: Tue, 8 Apr 2025 12:29:23 +0200
From: Christian Brauner <brauner@...nel.org>
To: syzbot <syzbot+dbb3b5b8e91c5be8daad@...kaller.appspotmail.com>
Cc: jack@...e.cz, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [syzbot] [fs?] KCSAN: data-race in file_end_write /
 posix_acl_update_mode

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@...kaller.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

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?