From: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
To: Shuangpeng <shuangpeng.kernel@gmail.com>
Cc: ocfs2-devel@lists.linux.dev, mark@fasheh.com, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, linux-kernel@vger.kernel.org
Subject: Re: [BUG] ocfs2: slab-out-of-bounds in down_read_trylock from quota-on path
Date: Wed, 1 Apr 2026 09:06:45 -0300 [thread overview]
Message-ID: <ac0Buq9DS9kREZvt@fedora> (raw)
In-Reply-To: <40B9252B-5C73-47A8-BFE0-1A76B1D9F437@gmail.com>
On Wed, Mar 25, 2026 at 03:15:27PM -0400, Shuangpeng wrote:
> Hi Kernel Maintainers,
>
> I hit the following KASAN report while testing current upstream kernel:
>
> KASAN: slab-out-of-bounds in down_read_trylock
>
> on commit bbeb83d3182abe0d245318e274e8531e5dd7a948 (Mar 24 2026)
>
> The reproducer and .config files are here:
> https://gist.github.com/shuangpengbai/d2612321387d8c6be057b1a9a2e1c422
>
> The faulting access happens in ocfs2_read_virt_blocks() when it calls
> down_read_trylock(&OCFS2_I(inode)->ip_alloc_sem), but KASAN reports that
> the accessed object belongs to f2fs_inode_cache. This looks like OCFS2 code
> may be interpreting a non-OCFS2 inode as an OCFS2 inode, but I am not fully
> sure yet.
>
> I'm happy to test debug patches or provide additional information.
>
> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>
>
> [ 52.307203][ T8456] ==================================================================
> [ 52.310017][ T8456] BUG: KASAN: slab-out-of-bounds in down_read_trylock (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-long.h:38 ./include/linux/atomic/atomic-instrumented.h:3189 kernel/locking/rwsem.c:1295 kernel/locking/rwsem.c:1576)
> [ 52.312429][ T8456] Read of size 8 at addr ffff8881641a21d0 by task a.out/8456
> [ 52.313159][ T8456]
> [ 52.313410][ T8456] CPU: 0 UID: 0 PID: 8456 Comm: a.out Not tainted 6.19.0-08383-g99a19d63fa32 #34 PREEMPT(full)
> [ 52.313417][ T8456] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> [ 52.313421][ T8456] Call Trace:
> [ 52.313423][ T8456] <TASK>
> [ 52.313425][ T8456] dump_stack_lvl (lib/dump_stack.c:122)
> [ 52.313433][ T8456] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)
> [ 52.313462][ T8456] kasan_report (mm/kasan/report.c:597)
> [ 52.313480][ T8456] kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
> [ 52.313486][ T8456] down_read_trylock (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-long.h:38 ./include/linux/atomic/atomic-instrumented.h:3189 kernel/locking/rwsem.c:1295 kernel/locking/rwsem.c:1576)
> [ 52.313498][ T8456] ocfs2_read_virt_blocks (fs/ocfs2/extent_map.c:994)
> [ 52.313540][ T8456] ocfs2_read_quota_block (fs/ocfs2/quota_local.c:147)
> [ 52.313556][ T8456] ocfs2_local_check_quota_file (fs/ocfs2/quota_local.c:175)
> [ 52.313585][ T8456] dquot_load_quota_sb (fs/quota/dquot.c:2455)
> [ 52.313591][ T8456] dquot_load_quota_inode (fs/quota/dquot.c:2499)
> [ 52.313598][ T8456] f2fs_quota_on (fs/f2fs/super.c:3414)
> [ 52.313604][ T8456] __se_sys_quotactl (fs/quota/quota.c:960 fs/quota/quota.c:916)
> [ 52.313629][ T8456] do_syscall_64 (arch/x86/entry/syscall_64.c:?)
> [ 52.313633][ T8456] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> [ 52.313638][ T8456] RIP: 0033:0x7f00b1646f29
> [ 52.313646][ T8456] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 48
>
> Code starting with the faulting instruction
> ===========================================
> 0: 00 c3 add %al,%bl
> 2: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
> 9: 00 00 00
> c: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 11: 48 89 f8 mov %rdi,%rax
> 14: 48 89 f7 mov %rsi,%rdi
> 17: 48 89 d6 mov %rdx,%rsi
> 1a: 48 89 ca mov %rcx,%rdx
> 1d: 48 rex.W
> [ 52.313651][ T8456] RSP: 002b:00007fff9de6e208 EFLAGS: 00000246 ORIG_RAX: 00000000000000b3
> [ 52.313658][ T8456] RAX: ffffffffffffffda RBX: 0000000020000944 RCX: 00007f00b1646f29
> [ 52.313661][ T8456] RDX: 0000000000000003 RSI: 0000000020000040 RDI: ffffffff80000202
> [ 52.313665][ T8456] RBP: 00007fff9de6e2f0 R08: 0000000000000000 R09: 0000000000000000
> [ 52.313668][ T8456] R10: 0000000020000080 R11: 0000000000000246 R12: 000056025d47a220
> [ 52.313671][ T8456] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [ 52.313675][ T8456] </TASK>
> [ 52.313677][ T8456]
> [ 52.342046][ T8456] The buggy address belongs to the object at ffff8881641a1dd0
> [ 52.342046][ T8456] which belongs to the cache f2fs_inode_cache of size 1144
> [ 52.343498][ T8456] The buggy address is located 1024 bytes inside of
> [ 52.343498][ T8456] allocated 1144-byte region [ffff8881641a1dd0, ffff8881641a2248)
> [ 52.344931][ T8456]
> [ 52.345181][ T8456] The buggy address belongs to the physical page:
> [ 52.345836][ T8456] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff8881641a3ba0 pfn:0x1641a0
> [ 52.346859][ T8456] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> [ 52.347717][ T8456] memcg:ffff8881641a7c39
> [ 52.348161][ T8456] flags: 0x17ff00000000240(workingset|head|node=0|zone=2|lastcpupid=0x7ff)
> [ 52.349030][ T8456] page_type: f5(slab)
> [ 52.349443][ T8456] raw: 017ff00000000240 ffff88810e6f0640 ffff88810e6d1690 ffff88810e6d1690
> [ 52.350313][ T8456] raw: ffff8881641a3ba0 000000080019000c 00000000f5000000 ffff8881641a7c39
> [ 52.351182][ T8456] head: 017ff00000000240 ffff88810e6f0640 ffff88810e6d1690 ffff88810e6d1690
> [ 52.352063][ T8456] head: ffff8881641a3ba0 000000080019000c 00000000f5000000 ffff8881641a7c39
> [ 52.352941][ T8456] head: 017ff00000000003 ffffea0005906801 00000000ffffffff 00000000ffffffff
> [ 52.353818][ T8456] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> [ 52.354693][ T8456] page dumped because: kasan: bad access detected
> [ 52.355345][ T8456] page_owner tracks the page as allocated
> [ 52.355932][ T8456] page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_RECLAIMABLE|_7
> [ 52.358085][ T8456] post_alloc_hook (./include/linux/page_owner.h:? mm/page_alloc.c:1884)
> [ 52.358576][ T8456] get_page_from_freelist (mm/page_alloc.c:? mm/page_alloc.c:3950)
> [ 52.359133][ T8456] __alloc_frozen_pages_noprof (mm/page_alloc.c:5245)
> [ 52.359722][ T8456] allocate_slab (mm/slub.c:3240 mm/slub.c:3411)
> [ 52.360179][ T8456] refill_objects (mm/slub.c:7092)
> [ 52.360653][ T8456] refill_sheaf (mm/slub.c:2790)
> [ 52.361091][ T8456] __pcs_replace_empty_main (mm/slub.c:2808 mm/slub.c:4546)
> [ 52.361651][ T8456] kmem_cache_alloc_lru_noprof (mm/slub.c:4640 mm/slub.c:4773 mm/slub.c:4807)
> [ 52.362239][ T8456] f2fs_alloc_inode (fs/f2fs/super.c:1753)
> [ 52.362732][ T8456] alloc_inode (fs/inode.c:?)
> [ 52.363169][ T8456] iget_locked (fs/inode.c:1472)
> [ 52.363616][ T8456] f2fs_iget (fs/f2fs/inode.c:575)
> [ 52.364048][ T8456] f2fs_fill_super (fs/f2fs/super.c:5026)
> [ 52.364550][ T8456] get_tree_bdev_flags (fs/super.c:1695)
> [ 52.365071][ T8456] vfs_get_tree (fs/super.c:1754)
> [ 52.365522][ T8456] do_new_mount (fs/namespace.c:1194 fs/namespace.c:3760 fs/namespace.c:3836)
> [ 52.365987][ T8456] page last free pid 1 tgid 1 stack trace:
> [ 52.366581][ T8456] __free_frozen_pages (./include/linux/page_owner.h:? mm/page_alloc.c:1433 mm/page_alloc.c:2973)
> [ 52.367108][ T8456] free_contig_range (mm/page_alloc.c:7237)
> [ 52.367618][ T8456] destroy_args (mm/debug_vm_pgtable.c:?)
> [ 52.368088][ T8456] debug_vm_pgtable (mm/debug_vm_pgtable.c:?)
> [ 52.368590][ T8456] do_one_initcall (init/main.c:1378)
> [ 52.369084][ T8456] do_initcall_level (init/main.c:1439)
> [ 52.369596][ T8456] do_initcalls (init/main.c:1453)
> [ 52.370043][ T8456] kernel_init_freeable (init/main.c:1692)
> [ 52.370580][ T8456] kernel_init (init/main.c:1580)
> [ 52.371027][ T8456] ret_from_fork (arch/x86/kernel/process.c:164)
> [ 52.371506][ T8456] ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
> [ 52.372006][ T8456]
> [ 52.372254][ T8456] Memory state around the buggy address:
> [ 52.372827][ T8456] ffff8881641a2080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 52.373641][ T8456] ffff8881641a2100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 52.374456][ T8456] >ffff8881641a2180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 52.375275][ T8456] ^
> [ 52.375962][ T8456] ffff8881641a2200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 52.376779][ T8456] ffff8881641a2280: fc fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00
> [ 52.377593][ T8456] ==================================================================
>
>
> Best,
> Shuangpeng
>
Hi Shuangpeng,
This looks like a quota format mismatch rather than an OCFS2 bug itself.
Your reproducer creates an F2FS image with quota format id = 3, which is
specific to OCFS2. When quotactl() is issued, the following path is taken:
f2fs_quota_on
-> dquot_load_quota_inode
-> dquot_load_quota_sb
-> ocfs2_local_check_quota_file
Inside dquot_load_quota_sb(), find_quota_format(id) resolves the format based
solely on the on-disk id. Since id = 3 corresponds to ocfs2_quota_format, the
quota subsystem ends up invoking OCFS2-specific handlers on an F2FS inode.
So the root cause is that the quota framework does not validate whether the
quota format is compatible with the filesystem.
next prev parent reply other threads:[~2026-04-01 12:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 19:15 [BUG] ocfs2: slab-out-of-bounds in down_read_trylock from quota-on path Shuangpeng
2026-04-01 12:06 ` Pedro Demarchi Gomes [this message]
2026-04-01 20:36 ` Shuangpeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac0Buq9DS9kREZvt@fedora \
--to=pedrodemargomes@gmail.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=shuangpeng.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox