Re: [syzbot] [mm?] KCSAN: data-race in copy_page_from_iter_atomic / pagecache_isize_extended

[Jann Horn <jannh@google.com>]

On Tue, May 6, 2025 at 9:52 AM syzbot
<syzbot+189d4742d07e937d68ea@syzkaller.appspotmail.com> wrote:
> HEAD commit:    01f95500a162 Merge tag 'uml-for-linux-6.15-rc6' of git://g..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17abbb68580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=6154604431d9aaf9
> dashboard link: https://syzkaller.appspot.com/bug?extid=189d4742d07e937d68ea
> compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
[...]
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+189d4742d07e937d68ea@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KCSAN: data-race in copy_page_from_iter_atomic / pagecache_isize_extended

I think this is a problem with the KCSAN implementation.

This is a race between writing to a userspace-owned page and reading
from a userspace-owned page.

This kind of pattern should be fairly trivial to trigger: If userspace
tells the kernel to read from a GUP'd page or pagecache on one thread,
and simultaneously tells the kernel to write to the same page on
another thread, we'll get a data race. This is not really a kernel
data race; it is more like a userspace race whose memory accesses
happen to go through the kernel.

So I think the fix would be for KCSAN to ignore anything in such
pages. The hard part is, I'm not sure how to tell what kind of page
we're dealing with from the kernel, some MM people might know...
distinguishing normal pagecache/anon pages from other pages might be
doable, but I guess it probably gets hard when thinking about
driver-allocated pages that were mapped into userspace vs
driver-allocated pages that are used internally in the driver...

> read to 0xffff88811d47e000 of 2048 bytes by task 37 on cpu 0:
>  memcpy_from_iter lib/iov_iter.c:73 [inline]
>  iterate_bvec include/linux/iov_iter.h:123 [inline]
>  iterate_and_advance2 include/linux/iov_iter.h:304 [inline]
>  iterate_and_advance include/linux/iov_iter.h:328 [inline]
>  __copy_from_iter lib/iov_iter.c:249 [inline]
>  copy_page_from_iter_atomic+0x77f/0xff0 lib/iov_iter.c:483
>  copy_folio_from_iter_atomic include/linux/uio.h:210 [inline]
>  generic_perform_write+0x2c2/0x490 mm/filemap.c:4121
>  shmem_file_write_iter+0xc5/0xf0 mm/shmem.c:3464
>  lo_rw_aio+0x5f7/0x7c0 drivers/block/loop.c:-1
>  do_req_filebacked drivers/block/loop.c:-1 [inline]
>  loop_handle_cmd drivers/block/loop.c:1866 [inline]
>  loop_process_work+0x52d/0xa60 drivers/block/loop.c:1901
>  loop_workfn+0x31/0x40 drivers/block/loop.c:1925
>  process_one_work kernel/workqueue.c:3238 [inline]
>  process_scheduled_works+0x4cb/0x9d0 kernel/workqueue.c:3319
>  worker_thread+0x582/0x770 kernel/workqueue.c:3400
>  kthread+0x486/0x510 kernel/kthread.c:464
>  ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:153
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> write to 0xffff88811d47e018 of 4072 bytes by task 4432 on cpu 1:
>  zero_user_segments include/linux/highmem.h:278 [inline]
>  folio_zero_segment include/linux/highmem.h:635 [inline]
>  pagecache_isize_extended+0x26f/0x340 mm/truncate.c:850
>  ext4_alloc_file_blocks+0x4ad/0x720 fs/ext4/extents.c:4545
>  ext4_do_fallocate fs/ext4/extents.c:4694 [inline]
>  ext4_fallocate+0x2b8/0x660 fs/ext4/extents.c:4750
>  vfs_fallocate+0x410/0x450 fs/open.c:338
>  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+0x7a/0xd0 fs/open.c:365
>  x64_sys_call+0x2b88/0x2fb0 arch/x86/include/generated/asm/syscalls_64.h:286
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xd0/0x1a0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f