erofs-utils: upgrade 1.6 -> 1.7.1

(From OE-Core rev: 333e644466c7b6749481988b638e23ec78316c4a)

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Alexander Kanavin
2023-11-27 11:17:40 +01:00
committed by Richard Purdie
parent f8199bc908
commit 4ab32e3f76
3 changed files with 4 additions and 212 deletions

View File

@@ -5,11 +5,8 @@ SECTION = "base"
LIC_FILES_CHKSUM = "file://COPYING;md5=73001d804ea1e3d84365f652242cca20"
HOMEPAGE = "https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/README"
SRCREV = "21710612d35cd952490959bfa6ea9fe87aaa52dd"
SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git;branch=master;protocol=https \
file://0001-erofs-utils-fsck-don-t-allocate-read-too-large-exten.patch \
file://0002-erofs-utils-fsck-block-insane-long-paths-when-extrac.patch \
"
SRCREV = "83d94dc619075e71ca4d0f42941cfc18d269a2af"
SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git;branch=master;protocol=https"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>(\d+(\.\d+)+))"
@@ -19,8 +16,9 @@ DEPENDS = "util-linux-libuuid"
inherit pkgconfig autotools
PACKAGECONFIG ??= "lz4"
PACKAGECONFIG ??= "lz4 zlib"
PACKAGECONFIG[lz4] = "--enable-lz4,--disable-lz4,lz4"
PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
EXTRA_OECONF = "${PACKAGECONFIG_CONFARGS} --disable-fuse"

View File

@@ -1,126 +0,0 @@
From c769805c79d5acede65d96e5786aa5ebb46c01e0 Mon Sep 17 00:00:00 2001
From: Gao Xiang <hsiangkao@linux.alibaba.com>
Date: Fri, 2 Jun 2023 11:05:19 +0800
Subject: [PATCH 1/2] erofs-utils: fsck: don't allocate/read too large extents
Since some crafted EROFS filesystem images could have insane large
extents, which causes unexpected bahaviors when extracting data.
Fix it by extracting large extents with a buffer of a reasonable
maximum size limit and reading multiple times instead.
Note that only `--extract` option is impacted.
CVE: CVE-2023-33552
Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-33552
Reported-by: Chaoming Yang <lometsj@live.com>
Fixes: 412c8f908132 ("erofs-utils: fsck: add --extract=X support to extract to path X")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230602030519.117071-1-hsiangkao@linux.alibaba.com
Upstream-Status: Backport
Signed-off-by: Ross Burton <ross.burton@arm.com>
---
fsck/main.c | 63 +++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 49 insertions(+), 14 deletions(-)
diff --git a/fsck/main.c b/fsck/main.c
index 6b42252..6689ad8 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -392,6 +392,8 @@ static int erofs_verify_inode_data(struct erofs_inode *inode, int outfd)
}
while (pos < inode->i_size) {
+ unsigned int alloc_rawsize;
+
map.m_la = pos;
if (compressed)
ret = z_erofs_map_blocks_iter(inode, &map,
@@ -420,10 +422,28 @@ static int erofs_verify_inode_data(struct erofs_inode *inode, int outfd)
if (!(map.m_flags & EROFS_MAP_MAPPED) || !fsckcfg.check_decomp)
continue;
- if (map.m_plen > raw_size) {
- raw_size = map.m_plen;
- raw = realloc(raw, raw_size);
- BUG_ON(!raw);
+ if (map.m_plen > Z_EROFS_PCLUSTER_MAX_SIZE) {
+ if (compressed) {
+ erofs_err("invalid pcluster size %" PRIu64 " @ offset %" PRIu64 " of nid %" PRIu64,
+ map.m_plen, map.m_la,
+ inode->nid | 0ULL);
+ ret = -EFSCORRUPTED;
+ goto out;
+ }
+ alloc_rawsize = Z_EROFS_PCLUSTER_MAX_SIZE;
+ } else {
+ alloc_rawsize = map.m_plen;
+ }
+
+ if (alloc_rawsize > raw_size) {
+ char *newraw = realloc(raw, alloc_rawsize);
+
+ if (!newraw) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ raw = newraw;
+ raw_size = alloc_rawsize;
}
if (compressed) {
@@ -434,18 +454,27 @@ static int erofs_verify_inode_data(struct erofs_inode *inode, int outfd)
}
ret = z_erofs_read_one_data(inode, &map, raw, buffer,
0, map.m_llen, false);
+ if (ret)
+ goto out;
+
+ if (outfd >= 0 && write(outfd, buffer, map.m_llen) < 0)
+ goto fail_eio;
} else {
- ret = erofs_read_one_data(&map, raw, 0, map.m_plen);
- }
- if (ret)
- goto out;
+ u64 p = 0;
- if (outfd >= 0 && write(outfd, compressed ? buffer : raw,
- map.m_llen) < 0) {
- erofs_err("I/O error occurred when verifying data chunk @ nid %llu",
- inode->nid | 0ULL);
- ret = -EIO;
- goto out;
+ do {
+ u64 count = min_t(u64, alloc_rawsize,
+ map.m_llen);
+
+ ret = erofs_read_one_data(&map, raw, p, count);
+ if (ret)
+ goto out;
+
+ if (outfd >= 0 && write(outfd, raw, count) < 0)
+ goto fail_eio;
+ map.m_llen -= count;
+ p += count;
+ } while (map.m_llen);
}
}
@@ -460,6 +489,12 @@ out:
if (buffer)
free(buffer);
return ret < 0 ? ret : 0;
+
+fail_eio:
+ erofs_err("I/O error occurred when verifying data chunk @ nid %llu",
+ inode->nid | 0ULL);
+ ret = -EIO;
+ goto out;
}
static inline int erofs_extract_dir(struct erofs_inode *inode)
--
2.34.1

View File

@@ -1,80 +0,0 @@
From 6cebfbb79b1d5d8feb48801e1008eea5bfa8b599 Mon Sep 17 00:00:00 2001
From: Gao Xiang <hsiangkao@linux.alibaba.com>
Date: Fri, 2 Jun 2023 13:52:56 +0800
Subject: [PATCH 2/2] erofs-utils: fsck: block insane long paths when
extracting images
Since some crafted EROFS filesystem images could have insane deep
hierarchy (or may form directory loops) which triggers the
PATH_MAX-sized path buffer OR stack overflow.
Actually some crafted images cannot be deemed as real corrupted
images but over-PATH_MAX paths are not something that we'd like to
support for now.
CVE: CVE-2023-33551
Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-33551
Reported-by: Chaoming Yang <lometsj@live.com>
Fixes: f44043561491 ("erofs-utils: introduce fsck.erofs")
Fixes: b11f84f593f9 ("erofs-utils: fsck: convert to use erofs_iterate_dir()")
Fixes: 412c8f908132 ("erofs-utils: fsck: add --extract=X support to extract to path X")
Signeo-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230602055256.18061-1-hsiangkao@linux.alibaba.com
Upstream-Status: Backport
Signed-off-by: Ross Burton <ross.burton@arm.com>
---
fsck/main.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/fsck/main.c b/fsck/main.c
index 6689ad8..28d95ec 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -680,28 +680,35 @@ again:
static int erofsfsck_dirent_iter(struct erofs_dir_context *ctx)
{
int ret;
- size_t prev_pos = fsckcfg.extract_pos;
+ size_t prev_pos, curr_pos;
if (ctx->dot_dotdot)
return 0;
- if (fsckcfg.extract_path) {
- size_t curr_pos = prev_pos;
+ prev_pos = fsckcfg.extract_pos;
+ curr_pos = prev_pos;
+
+ if (prev_pos + ctx->de_namelen >= PATH_MAX) {
+ erofs_err("unable to fsck since the path is too long (%u)",
+ curr_pos + ctx->de_namelen);
+ return -EOPNOTSUPP;
+ }
+ if (fsckcfg.extract_path) {
fsckcfg.extract_path[curr_pos++] = '/';
strncpy(fsckcfg.extract_path + curr_pos, ctx->dname,
ctx->de_namelen);
curr_pos += ctx->de_namelen;
fsckcfg.extract_path[curr_pos] = '\0';
- fsckcfg.extract_pos = curr_pos;
+ } else {
+ curr_pos += ctx->de_namelen;
}
-
+ fsckcfg.extract_pos = curr_pos;
ret = erofsfsck_check_inode(ctx->dir->nid, ctx->de_nid);
- if (fsckcfg.extract_path) {
+ if (fsckcfg.extract_path)
fsckcfg.extract_path[prev_pos] = '\0';
- fsckcfg.extract_pos = prev_pos;
- }
+ fsckcfg.extract_pos = prev_pos;
return ret;
}
--
2.34.1