[syzbot] [erofs?] INFO: task hung in erofs_bread

[syzbot] [erofs?] INFO: task hung in erofs_bread

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    590b221ed425 Add linux-next specific files for 20250912
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14b4947c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=12a1d1f3a8199632
dashboard link: https://syzkaller.appspot.com/bug?extid=1a9af3ef3c84c5e14dcc
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=17850e42580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12baf934580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/63a963fc26db/disk-590b221e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0c2013d30830/vmlinux-590b221e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7ee4d3a8e8f6/bzImage-590b221e.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/364a5efd8f50/mount_0.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=14baf934580000)

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

INFO: task syz.0.17:6071 blocked for more than 143 seconds.
      Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.17        state:D
 stack:28424 pid:6071  tgid:6065  ppid:5989   task_flags:0x400040 flags:0x00004004
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5360 [inline]
 __schedule+0x1798/0x4cc0 kernel/sched/core.c:6964
 __schedule_loop kernel/sched/core.c:7046 [inline]
 schedule+0x165/0x360 kernel/sched/core.c:7061
 io_schedule+0x80/0xd0 kernel/sched/core.c:7906
 folio_wait_bit_common+0x6b0/0xb90 mm/filemap.c:1330
 folio_put_wait_locked mm/filemap.c:1494 [inline]
 do_read_cache_folio+0x1aa/0x590 mm/filemap.c:3973
 read_mapping_folio include/linux/pagemap.h:999 [inline]
 erofs_bread+0x46f/0x7f0 fs/erofs/data.c:40
 erofs_readdir+0x58a/0x1020 fs/erofs/dir.c:81
 iterate_dir+0x399/0x570 fs/readdir.c:108
 __do_sys_getdents64 fs/readdir.c:410 [inline]
 __se_sys_getdents64+0xe4/0x260 fs/readdir.c:396
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fee78f8eba9
RSP: 002b:00007fee79e56038 EFLAGS: 00000246
 ORIG_RAX: 00000000000000d9
RAX: ffffffffffffffda RBX: 00007fee791d6090 RCX: 00007fee78f8eba9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00007fee79011e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fee791d6128 R14: 00007fee791d6090 R15: 00007ffcdf8b9388
 </TASK>

Showing all locks held in the system:
5 locks held by kworker/u8:0/12:
1 lock held by khungtaskd/31:
 #0: 
ffffffff8e33c820
 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6775
3 locks held by kworker/u8:2/35:
 #0: 
ffff88801a889148
 (
(wq_completion)events_unbound
){+.+.}-{0:0}, at: raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:636
 #1: ffff8880b8624008 (
psi_seq){-.-.}-{0:0}, at: process_one_work kernel/workqueue.c:3239 [inline]
psi_seq){-.-.}-{0:0}, at: process_scheduled_works+0x9ef/0x17b0 kernel/workqueue.c:3346
 #2: 
ffff88805488d250 (&devlink->lock_key#6){+.+.}-{4:4}, at: nsim_dev_trap_report_work+0x57/0xb80 drivers/net/netdevsim/dev.c:853
3 locks held by kswapd0/84:
2 locks held by getty/5630:
 #0: 
ffff88814dbd60a0
 (
&tty->ldisc_sem
){++++}-{0:0}
, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: 
ffffc9000332e2f0
 (
&ldata->atomic_read_lock
){+.+.}-{4:4}
, at: n_tty_read+0x43e/0x1400 drivers/tty/n_tty.c:2222
3 locks held by syz.0.17/6067:
2 locks held by syz.0.17/6071:
 #0: ffff888031f5d438 (&f->f_pos_lock){+.+.}-{4:4}, at: fdget_pos+0x247/0x320 fs/file.c:1232
 #1: ffff88805f1f86d0 (&type->i_mutex_dir_key#8){.+.+}-{4:4}, at: iterate_dir+0x292/0x570 fs/readdir.c:101
3 locks held by syz.1.18/6121:
2 locks held by syz.1.18/6123:
 #0: ffff888030faeb78 (&f->f_pos_lock){+.+.}-{4:4}, at: fdget_pos+0x247/0x320 fs/file.c:1232
 #1: ffff8880300b06d0 (&type->i_mutex_dir_key#8){.+.+}-{4:4}, at: iterate_dir+0x292/0x570 fs/readdir.c:101
9 locks held by syz.2.19/6148:
2 locks held by syz.2.19/6149:
 #0: ffff88803210a9b8 (&f->f_pos_lock){+.+.}-{4:4}, at: fdget_pos+0x247/0x320 fs/file.c:1232
 #1: ffff8880300b1150 (&type->i_mutex_dir_key#8){.+.+}-{4:4}, at: iterate_dir+0x292/0x570 fs/readdir.c:101
8 locks held by syz.3.20/6172:
2 locks held by syz.3.20/6173:
 #0: 
ffff888021fe9b38
 (
&f->f_pos_lock
){+.+.}-{4:4}
, at: fdget_pos+0x247/0x320 fs/file.c:1232
 #1: 
ffff88805f1f9150
 (&type->i_mutex_dir_key#8){.+.+}-{4:4}, at: iterate_dir+0x292/0x570 fs/readdir.c:101
3 locks held by syz.4.21/6210:
2 locks held by syz.4.21/6211:
 #0: 
ffff88802f23e638
 (
&f->f_pos_lock
){+.+.}-{4:4}
, at: fdget_pos+0x247/0x320 fs/file.c:1232
 #1: 
ffff88805f1f9bd0
 (


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

[PATCH] erofs: avoid reading more for fragment maps

[Gao Xiang]

Since all real encoded extents (directly handled by the decompression
subsystem) have a sane, limited maximum decoded length
(Z_EROFS_PCLUSTER_MAX_DSIZE), and the read‑more policy is only applied
if needed.

However, it makes no sense to read more for non‑encoded maps, such as
fragment extents, since such extents can be huge (up to i_size) and
there is no benefit to reading more at this layer.

For normal images, it does not really matter, but for crafted images
generated by syzbot, excessively large fragment extents can cause
read‑more to run for an overly long time.

Reported-by: syzbot+1a9af3ef3c84c5e14dcc@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/r/68c8583d.050a0220.2ff435.03a3.GAE@google.com
Fixes: b44686c8391b ("erofs: fix large fragment handling")
Fixes: b15b2e307c3a ("erofs: support on-disk compressed fragments data")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
 fs/erofs/zdata.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
index 2d73297003d2..625b8ae8f67f 100644
--- a/fs/erofs/zdata.c
+++ b/fs/erofs/zdata.c
@@ -1835,7 +1835,7 @@ static void z_erofs_pcluster_readmore(struct z_erofs_frontend *f,
 		map->m_la = end;
 		err = z_erofs_map_blocks_iter(inode, map,
 					      EROFS_GET_BLOCKS_READMORE);
-		if (err)
+		if (err || !(map->m_flags & EROFS_MAP_ENCODED))
 			return;
 
 		/* expand ra for the trailing edge if readahead */
@@ -1847,7 +1847,7 @@ static void z_erofs_pcluster_readmore(struct z_erofs_frontend *f,
 		end = round_up(end, PAGE_SIZE);
 	} else {
 		end = round_up(map->m_la, PAGE_SIZE);
-		if (!map->m_llen)
+		if (!(map->m_flags & EROFS_MAP_ENCODED) || !map->m_llen)
 			return;
 	}
 
-- 
2.43.5

Re: [syzbot] [erofs?] INFO: task hung in erofs_bread

[Gao Xiang]

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git dev-test

Re: [syzbot] [erofs?] INFO: task hung in erofs_bread

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1a9af3ef3c84c5e14dcc@syzkaller.appspotmail.com
Tested-by: syzbot+1a9af3ef3c84c5e14dcc@syzkaller.appspotmail.com

Tested on:

commit:         e8795f31 erofs: avoid reading more for fragment maps
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git dev-test
console output: https://syzkaller.appspot.com/x/log.txt?x=11137762580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4239c29711f936f
dashboard link: https://syzkaller.appspot.com/bug?extid=1a9af3ef3c84c5e14dcc
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.

Re: [PATCH] erofs: avoid reading more for fragment maps

[Chao Yu]

On 9/16/25 16:48, Gao Xiang wrote:
> Since all real encoded extents (directly handled by the decompression
> subsystem) have a sane, limited maximum decoded length
> (Z_EROFS_PCLUSTER_MAX_DSIZE), and the read‑more policy is only applied
> if needed.
> 
> However, it makes no sense to read more for non‑encoded maps, such as
> fragment extents, since such extents can be huge (up to i_size) and
> there is no benefit to reading more at this layer.
> 
> For normal images, it does not really matter, but for crafted images
> generated by syzbot, excessively large fragment extents can cause
> read‑more to run for an overly long time.
> 
> Reported-by: syzbot+1a9af3ef3c84c5e14dcc@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/r/68c8583d.050a0220.2ff435.03a3.GAE@google.com
> Fixes: b44686c8391b ("erofs: fix large fragment handling")
> Fixes: b15b2e307c3a ("erofs: support on-disk compressed fragments data")
> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,