[syzbot] [xfs?] KFENCE: memory corruption in xfs_idata_realloc

[syzbot] [xfs?] KFENCE: memory corruption in xfs_idata_realloc

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    c02d24a5af66 Add linux-next specific files for 20241003
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=164f779f980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=94f9caf16c0af42d
dashboard link: https://syzkaller.appspot.com/bug?extid=8a8170685a482c92e86a
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=13012707980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/641e642c9432/disk-c02d24a5.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/98aaf20c29e0/vmlinux-c02d24a5.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c23099f2d86b/bzImage-c02d24a5.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/547c3034fd79/mount_0.gz

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

XFS (loop2): Quotacheck: Done.
==================================================================
BUG: KFENCE: memory corruption in krealloc_noprof+0x160/0x2e0

Corrupted memory at 0xffff88823bedafeb [ 0x03 0x00 0xd8 0x62 0x75 0x73 0x01 0x00 0x00 0x11 0x4c 0x00 0x00 0x00 0x00 0x00 ] (in kfence-#108):
 krealloc_noprof+0x160/0x2e0
 xfs_idata_realloc+0x116/0x1b0 fs/xfs/libxfs/xfs_inode_fork.c:523
 xfs_dir2_sf_addname_easy fs/xfs/libxfs/xfs_dir2_sf.c:469 [inline]
 xfs_dir2_sf_addname+0x899/0x1b60 fs/xfs/libxfs/xfs_dir2_sf.c:432
 xfs_dir_createname_args+0x152/0x200 fs/xfs/libxfs/xfs_dir2.c:308
 xfs_dir_createname+0x4b3/0x640 fs/xfs/libxfs/xfs_dir2.c:361
 xfs_dir_create_child+0xe3/0x490 fs/xfs/libxfs/xfs_dir2.c:860
 xfs_create+0x8cc/0xf60 fs/xfs/xfs_inode.c:722
 xfs_generic_create+0x5d5/0xf50 fs/xfs/xfs_iops.c:213
 lookup_open fs/namei.c:3595 [inline]
 open_last_lookups fs/namei.c:3694 [inline]
 path_openat+0x1c03/0x3590 fs/namei.c:3930
 do_filp_open+0x235/0x490 fs/namei.c:3960
 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415
 do_sys_open fs/open.c:1430 [inline]
 __do_sys_openat fs/open.c:1446 [inline]
 __se_sys_openat fs/open.c:1441 [inline]
 __x64_sys_openat+0x247/0x2a0 fs/open.c:1441
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

kfence-#108: 0xffff88823bedafa0-0xffff88823bedafea, size=75, cache=kmalloc-96

allocated by task 7203 on cpu 1 at 147.184900s (0.409032s ago):
 kmalloc_noprof include/linux/slab.h:882 [inline]
 xfs_init_local_fork fs/xfs/libxfs/xfs_inode_fork.c:55 [inline]
 xfs_iformat_local+0x2db/0x620 fs/xfs/libxfs/xfs_inode_fork.c:97
 xfs_iformat_data_fork+0x38f/0x7b0 fs/xfs/libxfs/xfs_inode_fork.c:264
 xfs_inode_from_disk+0xaa9/0xf60 fs/xfs/libxfs/xfs_inode_buf.c:254
 xfs_iget_cache_miss fs/xfs/xfs_icache.c:683 [inline]
 xfs_iget+0xc5a/0x2f00 fs/xfs/xfs_icache.c:821
 xfs_mountfs+0x1040/0x2020 fs/xfs/xfs_mount.c:873
 xfs_fs_fill_super+0x11f0/0x1460 fs/xfs/xfs_super.c:1765
 get_tree_bdev+0x3f7/0x570 fs/super.c:1635
 vfs_get_tree+0x90/0x2b0 fs/super.c:1800
 do_new_mount+0x2be/0xb40 fs/namespace.c:3507
 do_mount fs/namespace.c:3847 [inline]
 __do_sys_mount fs/namespace.c:4055 [inline]
 __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:4032
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

freed by task 7203 on cpu 0 at 147.535434s (0.189887s ago):
 krealloc_noprof+0x160/0x2e0
 xfs_idata_realloc+0x116/0x1b0 fs/xfs/libxfs/xfs_inode_fork.c:523
 xfs_dir2_sf_addname_easy fs/xfs/libxfs/xfs_dir2_sf.c:469 [inline]
 xfs_dir2_sf_addname+0x899/0x1b60 fs/xfs/libxfs/xfs_dir2_sf.c:432
 xfs_dir_createname_args+0x152/0x200 fs/xfs/libxfs/xfs_dir2.c:308
 xfs_dir_createname+0x4b3/0x640 fs/xfs/libxfs/xfs_dir2.c:361
 xfs_dir_create_child+0xe3/0x490 fs/xfs/libxfs/xfs_dir2.c:860
 xfs_create+0x8cc/0xf60 fs/xfs/xfs_inode.c:722
 xfs_generic_create+0x5d5/0xf50 fs/xfs/xfs_iops.c:213
 lookup_open fs/namei.c:3595 [inline]
 open_last_lookups fs/namei.c:3694 [inline]
 path_openat+0x1c03/0x3590 fs/namei.c:3930
 do_filp_open+0x235/0x490 fs/namei.c:3960
 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415
 do_sys_open fs/open.c:1430 [inline]
 __do_sys_openat fs/open.c:1446 [inline]
 __se_sys_openat fs/open.c:1441 [inline]
 __x64_sys_openat+0x247/0x2a0 fs/open.c:1441
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7203 Comm: syz.2.194 Not tainted 6.12.0-rc1-next-20241003-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
==================================================================


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

Re: [syzbot] [xfs?] KFENCE: memory corruption in xfs_idata_realloc

[Christoph Hellwig]

[adding the kfence maintainers]

On Tue, Oct 08, 2024 at 04:43:23PM -0700, syzbot wrote:
> dashboard link: https://syzkaller.appspot.com/bug?extid=8a8170685a482c92e86a

[...]

> XFS (loop2): Quotacheck: Done.
> ==================================================================
> BUG: KFENCE: memory corruption in krealloc_noprof+0x160/0x2e0
> 
> Corrupted memory at 0xffff88823bedafeb [ 0x03 0x00 0xd8 0x62 0x75 0x73 0x01 0x00 0x00 0x11 0x4c 0x00 0x00 0x00 0x00 0x00 ] (in kfence-#108):
>  krealloc_noprof+0x160/0x2e0
>  xfs_idata_realloc+0x116/0x1b0 fs/xfs/libxfs/xfs_inode_fork.c:523

I've tried to make sense of this report and failed.

Documentation/dev-tools/kfence.rst explains these messages as:

KFENCE also uses pattern-based redzones on the other side of an object's guard
page, to detect out-of-bounds writes on the unprotected side of the object.
These are reported on frees::

But doesn't explain what "the other side of an object's guard page" is.

Either way this is in the common krealloc code, which is a bit special
as it uses ksize to figure out what the actual underlying allocation
size of an object is to make use of that.  Without understanding the
actual error I wonder if that's something kfence can't cope with?

Re: [syzbot] [xfs?] KFENCE: memory corruption in xfs_idata_realloc

[Marco Elver]

On Thu, 10 Oct 2024 at 08:48, Christoph Hellwig <hch@infradead.org> wrote:
>
> [adding the kfence maintainers]
>
> On Tue, Oct 08, 2024 at 04:43:23PM -0700, syzbot wrote:
> > dashboard link: https://syzkaller.appspot.com/bug?extid=8a8170685a482c92e86a
>
> [...]
>
> > XFS (loop2): Quotacheck: Done.
> > ==================================================================
> > BUG: KFENCE: memory corruption in krealloc_noprof+0x160/0x2e0
> >
> > Corrupted memory at 0xffff88823bedafeb [ 0x03 0x00 0xd8 0x62 0x75 0x73 0x01 0x00 0x00 0x11 0x4c 0x00 0x00 0x00 0x00 0x00 ] (in kfence-#108):
> >  krealloc_noprof+0x160/0x2e0
> >  xfs_idata_realloc+0x116/0x1b0 fs/xfs/libxfs/xfs_inode_fork.c:523
>
> I've tried to make sense of this report and failed.
>
> Documentation/dev-tools/kfence.rst explains these messages as:
>
> KFENCE also uses pattern-based redzones on the other side of an object's guard
> page, to detect out-of-bounds writes on the unprotected side of the object.
> These are reported on frees::
>
> But doesn't explain what "the other side of an object's guard page" is.

Every kfence object has a guard page right next to where it's allocated:

  [ GUARD | OBJECT + "wasted space" ]

or

  [ "wasted space" + OBJECT | GUARD ]

The GUARD is randomly on the left or right. If an OOB access straddles
into the GUARD, we get a page fault. For objects smaller than
page-size, there'll be some "wasted space" on the object page, which
is on "the other side" vs. where the guard page is. If a OOB write or
other random memory corruption doesn't hit the GUARD, but the "wasted
space" portion next to an object that would be detected as "Corrupted
memory" on free because the redzone pattern was likely stomped on.

> Either way this is in the common krealloc code, which is a bit special
> as it uses ksize to figure out what the actual underlying allocation
> size of an object is to make use of that.  Without understanding the
> actual error I wonder if that's something kfence can't cope with?

krealloc + KFENCE broke in next-20241003:
https://lore.kernel.org/all/CANpmjNM5XjwwSc8WrDE9=FGmSScftYrbsvC+db+82GaMPiQqvQ@mail.gmail.com/T/#u
It's been removed from -next since then.

It's safe to ignore.

#syz dup: KFENCE: memory corruption in add_sysfs_param

Re: [syzbot] [xfs?] KFENCE: memory corruption in xfs_idata_realloc

[Christoph Hellwig]

On Thu, Oct 10, 2024 at 09:50:06AM +0200, Marco Elver wrote:
> > I've tried to make sense of this report and failed.
> >
> > Documentation/dev-tools/kfence.rst explains these messages as:
> >
> > KFENCE also uses pattern-based redzones on the other side of an object's guard
> > page, to detect out-of-bounds writes on the unprotected side of the object.
> > These are reported on frees::
> >
> > But doesn't explain what "the other side of an object's guard page" is.
> 
> Every kfence object has a guard page right next to where it's allocated:
> 
>   [ GUARD | OBJECT + "wasted space" ]
> 
> or
> 
>   [ "wasted space" + OBJECT | GUARD ]
> 
> The GUARD is randomly on the left or right. If an OOB access straddles
> into the GUARD, we get a page fault. For objects smaller than
> page-size, there'll be some "wasted space" on the object page, which
> is on "the other side" vs. where the guard page is. If a OOB write or
> other random memory corruption doesn't hit the GUARD, but the "wasted
> space" portion next to an object that would be detected as "Corrupted
> memory" on free because the redzone pattern was likely stomped on.

Thanks!  Searching kfence.txt for random I find that explaination in
the intro now.  Can you maybe expand the section I quoted to make
this more clear, by saying something like:

KFENCE also uses pattern-based redzones on the side of the object that
is not covered by the GUARD (which is randomly allocated to either the
left or the right), to detect out-of-bounds writes there as well.
These are reported on frees::


> 
> > Either way this is in the common krealloc code, which is a bit special
> > as it uses ksize to figure out what the actual underlying allocation
> > size of an object is to make use of that.  Without understanding the
> > actual error I wonder if that's something kfence can't cope with?
> 
> krealloc + KFENCE broke in next-20241003:
> https://lore.kernel.org/all/CANpmjNM5XjwwSc8WrDE9=FGmSScftYrbsvC+db+82GaMPiQqvQ@mail.gmail.com/T/#u
> It's been removed from -next since then.
> 
> It's safe to ignore.

Thanks!