From: Utkal Singh <singhutkal015@gmail.com>
To: linux-erofs@lists.ozlabs.org
Cc: hsiangkao@linux.alibaba.com, yifan.yfzhao@foxmail.com,
singhutkal015@gmail.com
Subject: [PATCH] erofs-utils: lib: validate z_extents against inode size
Date: Tue, 17 Mar 2026 08:21:15 +0000 [thread overview]
Message-ID: <20260317082115.34389-1-singhutkal015@gmail.com> (raw)
z_extents is read from on-disk metadata and used as the upper bound
for extent lookups in z_erofs_map_blocks_ext(). A corrupted value
can be arbitrarily large (up to 2^48-1), causing erofs_read_metabuf()
to access offsets far beyond the actual extent table. The resulting
garbage is parsed as z_erofs_extent records, leading to wrong physical
addresses used for I/O, silent data corruption, or crashes.
Since each extent covers at least one logical cluster, the extent
count cannot exceed DIV_ROUND_UP(i_size, 1 << z_lclusterbits).
Validate z_extents against this bound at inode initialization time
and reject invalid values with -EFSCORRUPTED.
Signed-off-by: Utkal Singh <singhutkal015@gmail.com>
---
lib/zmap.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/lib/zmap.c b/lib/zmap.c
index 0e7af4e..2f679b7 100644
--- a/lib/zmap.c
+++ b/lib/zmap.c
@@ -675,8 +675,26 @@ static int z_erofs_fill_inode_lazy(struct erofs_inode *vi)
vi->z_lclusterbits = sbi->blkszbits + (h->h_clusterbits & 15);
if (vi->datalayout == EROFS_INODE_COMPRESSED_FULL &&
(vi->z_advise & Z_EROFS_ADVISE_EXTENTS)) {
+ u64 max_extents;
+
vi->z_extents = le32_to_cpu(h->h_extents_lo) |
((u64)le16_to_cpu(h->h_extents_hi) << 32);
+
+ /*
+ * Each extent covers at least one logical cluster, so
+ * the extent count must not exceed the number of lclusters.
+ * Reject bogus values to prevent out-of-bounds metadata
+ * reads in z_erofs_map_blocks_ext().
+ */
+ max_extents = DIV_ROUND_UP(vi->i_size,
+ 1ULL << vi->z_lclusterbits);
+ if (vi->z_extents > max_extents) {
+ erofs_err("bogus z_extents %llu (max %llu) for nid %llu",
+ vi->z_extents | 0ULL, max_extents | 0ULL,
+ vi->nid | 0ULL);
+ err = -EFSCORRUPTED;
+ goto out_put_metabuf;
+ }
goto done;
}
vi->z_algorithmtype[0] = h->h_algorithmtype & 15;
--
2.43.0
next reply other threads:[~2026-03-17 8:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 8:21 Utkal Singh [this message]
2026-03-17 8:34 ` [PATCH] erofs-utils: lib: validate z_extents against inode size Gao Xiang
2026-03-17 9:01 ` Gao Xiang
2026-03-17 9:28 ` Utkal Singh
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=20260317082115.34389-1-singhutkal015@gmail.com \
--to=singhutkal015@gmail.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=yifan.yfzhao@foxmail.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