[syzbot] [ocfs2?] KASAN: use-after-free Read in ocfs2_check_dir_entry

[syzbot] [ocfs2?] KASAN: use-after-free Read in ocfs2_check_dir_entry

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    cfd4039213e7 Merge tag 'io_uring-6.19-20251208' of git://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=149b5992580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8750900a7c493a0b
dashboard link: https://syzkaller.appspot.com/bug?extid=c897823f699449cc3eb4
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16f1aec2580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17e32a1a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/57e430560492/disk-cfd40392.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9d30cdb15e4b/vmlinux-cfd40392.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ea35480882e2/bzImage-cfd40392.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/494d52f48e7a/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=12f1aec2580000)

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

(kworker/u8:17,3565,1):ocfs2_read_blocks_sync:112 ERROR: status = -12
(kworker/u8:17,3565,1):ocfs2_read_locked_inode:599 ERROR: status = -12
==================================================================
BUG: KASAN: use-after-free in ocfs2_check_dir_entry+0x3a0/0x480 fs/ocfs2/dir.c:318
Read of size 2 at addr ffff888052e81780 by task kworker/u8:17/3565

CPU: 1 UID: 0 PID: 3565 Comm: kworker/u8:17 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Workqueue: ocfs2_wq ocfs2_complete_recovery
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x240 mm/kasan/report.c:482
 kasan_report+0x118/0x150 mm/kasan/report.c:595
 ocfs2_check_dir_entry+0x3a0/0x480 fs/ocfs2/dir.c:318
 ocfs2_dir_foreach_blk_id fs/ocfs2/dir.c:1826 [inline]
 ocfs2_dir_foreach_blk+0xfff/0x1420 fs/ocfs2/dir.c:1954
 ocfs2_dir_foreach+0x42/0x70 fs/ocfs2/dir.c:1965
 ocfs2_queue_orphans fs/ocfs2/journal.c:2215 [inline]
 ocfs2_recover_orphans fs/ocfs2/journal.c:2299 [inline]
 ocfs2_complete_recovery+0xc37/0x20b0 fs/ocfs2/journal.c:1366
 process_one_work kernel/workqueue.c:3257 [inline]
 process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421
 kthread+0x711/0x8a0 kernel/kthread.c:463
 ret_from_fork+0x599/0xb30 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x5c2 pfn:0x52e81
flags: 0x80000000000000(node=0|zone=1)
raw: 0080000000000000 ffffea00014ba088 ffffea00014ba008 0000000000000000
raw: 00000000000005c2 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Movable, gfp_mask 0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), pid 6060, tgid 6060 (syz.2.19), ts 112783813754, free_ts 113851953043
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x234/0x290 mm/page_alloc.c:1846
 prep_new_page mm/page_alloc.c:1854 [inline]
 get_page_from_freelist+0x28c0/0x2960 mm/page_alloc.c:3915
 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5210
 alloc_pages_mpol+0xd1/0x380 mm/mempolicy.c:2486
 folio_alloc_mpol_noprof+0x39/0xe0 mm/mempolicy.c:2505
 shmem_alloc_folio mm/shmem.c:1890 [inline]
 shmem_alloc_and_add_folio mm/shmem.c:1932 [inline]
 shmem_get_folio_gfp+0x633/0x1a70 mm/shmem.c:2556
 shmem_get_folio mm/shmem.c:2662 [inline]
 shmem_write_begin+0x166/0x320 mm/shmem.c:3315
 generic_perform_write+0x29d/0x8c0 mm/filemap.c:4314
 shmem_file_write_iter+0xfb/0x120 mm/shmem.c:3490
 new_sync_write fs/read_write.c:593 [inline]
 vfs_write+0x5d5/0xb40 fs/read_write.c:686
 ksys_write+0x14b/0x260 fs/read_write.c:738
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5931 tgid 5931 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1395 [inline]
 free_unref_folios+0xc28/0x1810 mm/page_alloc.c:3000
 folios_put_refs+0x569/0x670 mm/swap.c:1002
 folio_batch_release include/linux/pagevec.h:101 [inline]
 shmem_undo_range+0x49e/0x1490 mm/shmem.c:1137
 shmem_truncate_range mm/shmem.c:1249 [inline]
 shmem_evict_inode+0x26e/0xa70 mm/shmem.c:1379
 evict+0x5f4/0xae0 fs/inode.c:837
 __dentry_kill+0x209/0x660 fs/dcache.c:670
 finish_dput+0xc9/0x480 fs/dcache.c:879
 __fput+0x69d/0xa80 fs/file_table.c:476
 task_work_run+0x1d4/0x260 kernel/task_work.c:233
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]
 exit_to_user_mode_loop+0xff/0x4f0 kernel/entry/common.c:75
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
 syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
 do_syscall_64+0x2e3/0xf80 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff888052e81680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff888052e81700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff888052e81780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff888052e81800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff888052e81880: 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 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

Forwarded: [PATCH] ocfs2: fix use-after-free when reading a bad inode

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ocfs2: fix use-after-free when reading a bad inode
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When ocfs2_read_locked_inode() fails with -ENOMEM or other errors,
it calls make_bad_inode() to mark the inode as bad but still returns
a valid inode pointer through the iget machinery. The function
_ocfs2_get_system_file_inode() only checks for IS_ERR(inode) but
not for bad inodes, causing the bad inode to be returned to callers.

During orphan recovery, ocfs2_queue_orphans() gets this bad inode
for the orphan directory and passes it to ocfs2_dir_foreach().
Since the inode was never properly initialized due to the earlier
read failure, iterating the directory accesses freed or uninitialized
memory, triggering a use-after-free in ocfs2_check_dir_entry().

Fix this by adding an is_bad_inode() check in _ocfs2_get_system_file_inode()
after ocfs2_iget() returns. If the inode is bad, release it with iput()
and return NULL. This protects all callers of ocfs2_get_system_file_inode()
from receiving bad inodes.

Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c897823f699449cc3eb4
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ocfs2/sysfile.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/ocfs2/sysfile.c b/fs/ocfs2/sysfile.c
index d53a6cc866be..f443479f7d3e 100644
--- a/fs/ocfs2/sysfile.c
+++ b/fs/ocfs2/sysfile.c
@@ -145,6 +145,13 @@ static struct inode * _ocfs2_get_system_file_inode(struct ocfs2_super *osb,
 		inode = NULL;
 		goto bail;
 	}
+
+	if(is_bad_inode(inode)) {
+		iput(inode);
+		inode = NULL;
+		goto bail;
+	}
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 	if (type == LOCAL_USER_QUOTA_SYSTEM_INODE ||
 	    type == LOCAL_GROUP_QUOTA_SYSTEM_INODE ||
-- 
2.43.0

Forwarded: [PATCH] ocfs2: validate inline directory i_size during inode read

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ocfs2: validate inline directory i_size during inode read
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When reading an inode from disk, ocfs2_validate_inode_block() performs
various sanity checks but does not validate the size of inline
directories. If the filesystem is corrupted, an inline directory's
i_size can exceed the actual inline data capacity (id_count).

This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline
data buffer, triggering a use-after-free when accessing directory
entries from freed memory.

In the syzbot report:
  - i_size was 1099511627576 bytes (~1TB)
  - Actual inline data capacity (id_count) is typically <256 bytes
  - A garbage rec_len (54648) caused ctx->pos to jump out of bounds
  - This triggered a UAF in ocfs2_check_dir_entry()

Fix by adding a validation check in ocfs2_validate_inode_block() to
ensure inline directories have i_size <= id_count. This catches the
corruption early during inode read and prevents all downstream code
from operating on invalid data.

Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c897823f699449cc3eb4
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ocfs2/inode.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index 8340525e5589..9eb364bef5c3 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -1521,6 +1521,21 @@ int ocfs2_validate_inode_block(struct super_block *sb,
 		}
 	}
 
+	if (S_ISDIR(le16_to_cpu(di->i_mode)) &&
+	    (di->i_dyn_features & cpu_to_le16(OCFS2_INLINE_DATA_FL))) {
+		struct ocfs2_inline_data *data = &di->id2.i_data;
+
+		if (le64_to_cpu(di->i_size) > le16_to_cpu(data->id_count)) {
+			rc = ocfs2_error(sb,
+					 "Invalid dinode #%llu: inline directory "
+					 "i_size %llu exceeds id_count %u\n",
+					 (unsigned long long)bh->b_blocknr,
+					 (unsigned long long)le64_to_cpu(di->i_size),
+					 le16_to_cpu(data->id_count));
+			goto bail;
+		}
+	}
+
 	rc = 0;
 
 bail:
-- 
2.43.0