[v6.6] KASAN: use-after-free Read in generic_perform_write

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: cc1a1c5b404a Linux 6.6.103
git tree: linux-6.6.y
console output: https://syzkaller.appspot.com/x/log.txt?x=159dc1f0580000
kernel config: https://syzkaller.appspot.com/x/.config?x=412020841cf033b0
dashboard link: https://syzkaller.appspot.com/bug?extid=65fde1a06da8d5b614b1
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/46c06862a545/disk-cc1a1c5b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/38ddabb6fc8b/vmlinux-cc1a1c5b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b130b7d031b5/bzImage-cc1a1c5b.xz

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

==================================================================
BUG: KASAN: use-after-free in copy_page_from_iter_atomic+0xaf1/0x1530 lib/iov_iter.c:592
Read of size 4096 at addr ffff888077507000 by task kworker/u4:1/12

CPU: 0 PID: 12 Comm: kworker/u4:1 Not tainted syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/14/2025
Workqueue: loop1 loop_workfn
Call Trace:
<TASK>
dump_stack_lvl+0x16c/0x230 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xac/0x220 mm/kasan/report.c:468
kasan_report+0x117/0x150 mm/kasan/report.c:581
check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x288/0x290 mm/kasan/generic.c:187
__asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
copy_page_from_iter_atomic+0xaf1/0x1530 lib/iov_iter.c:592
generic_perform_write+0x350/0x5b0 mm/filemap.c:4024
shmem_file_write_iter+0xfb/0x120 mm/shmem.c:2884
do_iter_readv_writev fs/read_write.c:-1 [inline]
do_iter_write+0x79a/0xc70 fs/read_write.c:860
lo_write_bvec drivers/block/loop.c:244 [inline]
lo_write_simple drivers/block/loop.c:266 [inline]
do_req_filebacked drivers/block/loop.c:490 [inline]
loop_handle_cmd drivers/block/loop.c:1933 [inline]
loop_process_work+0x1097/0x1ed0 drivers/block/loop.c:1968
process_one_work kernel/workqueue.c:2634 [inline]
process_scheduled_works+0xa45/0x15b0 kernel/workqueue.c:2711
worker_thread+0xa55/0xfc0 kernel/workqueue.c:2792
kthread+0x2fa/0x390 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:152
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:293
</TASK>

The buggy address belongs to the physical page:
page:ffffea0001dd41c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x77507
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000000 ffffea000079de88 ffffea0001dd7e88 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x100dc0(GFP_USER|__GFP_ZERO), pid 8458, tgid 8456 (syz.1.727), ts 403696182904, free_ts 403853552877
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x1cd/0x210 mm/page_alloc.c:1554
prep_new_page mm/page_alloc.c:1561 [inline]
get_page_from_freelist+0x195c/0x19f0 mm/page_alloc.c:3191
__alloc_pages+0x1e3/0x460 mm/page_alloc.c:4457
lbmLogInit fs/jfs/jfs_logmgr.c:1816 [inline]
lmLogInit+0x316/0x1a30 fs/jfs/jfs_logmgr.c:1270
open_inline_log fs/jfs/jfs_logmgr.c:1175 [inline]
lmLogOpen+0x4ef/0xfb0 fs/jfs/jfs_logmgr.c:1069
jfs_mount_rw+0xea/0x670 fs/jfs/jfs_mount.c:257
jfs_fill_super+0x592/0xac0 fs/jfs/super.c:565
mount_bdev+0x22b/0x2d0 fs/super.c:1643
legacy_get_tree+0xea/0x180 fs/fs_context.c:662
vfs_get_tree+0x8c/0x280 fs/super.c:1764
do_new_mount+0x24b/0xa40 fs/namespace.c:3377
do_mount fs/namespace.c:3717 [inline]
__do_sys_mount fs/namespace.c:3926 [inline]
__se_sys_mount+0x2da/0x3c0 fs/namespace.c:3903
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x55/0xb0 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x68/0xd2
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1154 [inline]
free_unref_page_prepare+0x7ce/0x8e0 mm/page_alloc.c:2336
free_unref_page+0x32/0x2e0 mm/page_alloc.c:2429
lbmLogShutdown fs/jfs/jfs_logmgr.c:1864 [inline]
lmLogShutdown+0x43a/0x830 fs/jfs/jfs_logmgr.c:1684
lmLogClose+0x28a/0x520 fs/jfs/jfs_logmgr.c:1460
jfs_umount+0x2ef/0x3c0 fs/jfs/jfs_umount.c:114
jfs_put_super+0x8c/0x190 fs/jfs/super.c:194
generic_shutdown_super+0x134/0x2b0 fs/super.c:693
kill_block_super+0x44/0x90 fs/super.c:1660
deactivate_locked_super+0x97/0x100 fs/super.c:481
cleanup_mnt+0x429/0x4c0 fs/namespace.c:1250
task_work_run+0x1ce/0x250 kernel/task_work.c:239
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop+0xe6/0x110 kernel/entry/common.c:177
exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:210
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x1a/0x50 kernel/entry/common.c:302
do_syscall_64+0x61/0xb0 arch/x86/entry/common.c:87
entry_SYSCALL_64_after_hwframe+0x68/0xd2

Memory state around the buggy address:
ffff888077506f00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff888077506f80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff888077507000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff888077507080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888077507100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


---
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