All of lore.kernel.org
 help / color / mirror / Atom feed
* z_erofs_extent.plen == 0x2000000 can lead to crash
@ 2025-10-01 21:57 rtm
  2025-10-02  0:21 ` Gao Xiang
  0 siblings, 1 reply; 2+ messages in thread
From: rtm @ 2025-10-01 21:57 UTC (permalink / raw)
  To: Gao Xiang, Chao Yu; +Cc: linux-erofs

Here's a corrupt erofs image that can cause a crash:

# wget http://www.rtmrtm.org/rtm/erofs4a.img
# mount -t erofs -o loop erofs4a.img /mnt
# cat < /mnt/d/y > /dev/null
 kernel BUG at block/blk-mq.c:1152!
 Oops: invalid opcode: 0000 [#1] SMP PTI
 CPU: 11 UID: 0 PID: 1315 Comm: cat Not tainted 6.17.0-01737-g50c19e20ed2e #29 PREEMPT(voluntary)
 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
 RIP: 0010:blk_mq_end_request+0x28/0x30

The problem is that the inner "do" loop of z_erofs_submit_queue() runs
without bound submitting read requests, because bvec.bv_len is zero.
The reason for the zero is that the broken filesystem image contains
an z_erofs_extent.plen of 0x2000000. This looks non-zero to the

        } else if (map->m_plen) {

in z_erofs_map_blocks_ext(), but then the code does

                        map->m_plen &= Z_EROFS_EXTENT_PLEN_MASK;

causing m_plen to be zero.

If CONFIG_EROFS_FS_DEBUG, the problem is caught by
z_erofs_submit_queue()'s

                                DBG_BUGON(bvec.bv_len < sb->s_blocksize);

Robert Morris
rtm@mit.edu



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-10-02  0:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-01 21:57 z_erofs_extent.plen == 0x2000000 can lead to crash rtm
2025-10-02  0:21 ` Gao Xiang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.