[syzbot] [mm?] [bcachefs?] UBSAN: shift-out-of-bounds in filemap_get_entry

Hello,

syzbot found the following issue on:

HEAD commit: 69e858e0b8b2 Merge tag 'uml-for-linus-6.14-rc1' of git://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17814b24580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d033b14aeef39158
dashboard link: https://syzkaller.appspot.com/bug?extid=a0ae55e3dde11d2d790c
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13877b64580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16063ddf980000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-69e858e0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a53b888c1f3f/vmlinux-69e858e0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6b5e17edafc0/bzImage-69e858e0.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/680b2fde83a8/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]

------------[ cut here ]------------
UBSAN: shift-out-of-bounds in lib/xarray.c:147:16
shift exponent 192 is too large for 64-bit type 'unsigned long'
CPU: 0 UID: 0 PID: 2666 Comm: kworker/u4:9 Not tainted 6.13.0-syzkaller-09760-g69e858e0b8b2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: loop0 loop_rootcg_workfn
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:231 [inline]
__ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468
get_offset lib/xarray.c:147 [inline]
xas_descend lib/xarray.c:207 [inline]
xas_load+0x583/0x5c0 lib/xarray.c:246
filemap_get_entry+0x1f0/0x3b0 mm/filemap.c:1860
shmem_get_folio_gfp+0x285/0x1840 mm/shmem.c:2446
shmem_get_folio mm/shmem.c:2628 [inline]
shmem_write_begin+0x165/0x350 mm/shmem.c:3278
generic_perform_write+0x346/0x990 mm/filemap.c:4189
shmem_file_write_iter+0xf9/0x120 mm/shmem.c:3454
do_iter_readv_writev+0x71a/0x9d0
vfs_iter_write+0x23e/0x600 fs/read_write.c:974
lo_write_bvec drivers/block/loop.c:245 [inline]
lo_write_simple drivers/block/loop.c:266 [inline]
do_req_filebacked drivers/block/loop.c:520 [inline]
loop_handle_cmd drivers/block/loop.c:1926 [inline]
loop_process_work+0x1429/0x21c0 drivers/block/loop.c:1961
process_one_work kernel/workqueue.c:3236 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317
worker_thread+0x870/0xd30 kernel/workqueue.c:3398
kthread+0x7a9/0x920 kernel/kthread.c:464
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>


---
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 [email protected].

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 syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

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

This is an xarray issue. I suspect it's a race condition, although it
could be somebody doing a misplaced DMA or something. How easy is it to
reproduce?

(nb: I am on holiday for the next week, so I'm not going to be focused
on this, I just don't want other people wasting their time looking for a
bug somewhere that it isn't)

It's got a C reproducer, and you already use ktest, so

build-test-kernel run -IP ~/ktest/tests/syzbot-repro.ktest a0ae55e3dde11d2d790c

(it's the extid from the dashboard link)

If that doesn't work ping me and the syzbot folks, there are some
improvements that could be made and I'm going to need them anyways since
I have a ton of syzbot bugs to start cranking through soon.