From: Gao Xiang <xiang@kernel.org>
To: Yifan Zhao <stopire@gmail.com>
Cc: linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH 4/8] erofs-utils: lib: fix buffer leaks in error paths
Date: Fri, 13 Nov 2026 00:20:51 +0100 [thread overview]
Message-ID: <avZJ00X9YuOPSkHw@MacBookPro.fritz.box> (raw)
In-Reply-To: <20261112124725.2774244-5-stopire@gmail.com>
Hi Yifan,
On Thu, Nov 12, 2026 at 08:47:21PM +0800, Yifan Zhao wrote:
> Fragment data is already written before its buffer is shrunk.
> A failed realloc() should leave the original buffer valid, so the
> fragment commit can continue without shrinking it.
>
> Also fix an inline data buffer leak when loading compressed metadata
> fails during rebuild.
>
> Fixes: 84bae6acdbee ("erofs-utils: lib: keep full data until the fragment is committed")
> Fixes: 1c230a485f25 ("erofs-utils: mkfs: support rebuild mode for compressed inodes")
> Assisted-by: Codex:gpt-6-astra
> Assisted-by: Claude Code:deepseek-v4.1-flash-1017
> Signed-off-by: Yifan Zhao <stopire@gmail.com>
> ---
> lib/compress.c | 2 ++
> lib/fragments.c | 8 ++------
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/lib/compress.c b/lib/compress.c
> index e1cfc05..b5f75ca 100644
> --- a/lib/compress.c
> +++ b/lib/compress.c
> @@ -2607,6 +2607,8 @@ int z_erofs_rebuild_load_metadata(struct erofs_sb_info *dst_sbi,
> err_free_ei:
> free(ei);
> err_out:
> + free(inode->idata);
> + inode->idata = NULL;
> list_for_each_entry_safe(ei, n, &extents, list) {
> list_del(&ei->list);
> free(ei);
Can we use a separate patch to fix that?
> diff --git a/lib/fragments.c b/lib/fragments.c
> index d4e79b2..3398888 100644
> --- a/lib/fragments.c
> +++ b/lib/fragments.c
> @@ -366,12 +366,8 @@ int erofs_fragment_commit(struct erofs_inode *inode, u32 tofh)
> memmove(fi->data, fi->data + fi->length - sz, sz);
>
> nb = realloc(fi->data, sz);
> - if (!nb) {
> - erofs_up_write(&bk->lock);
> - fi->data = NULL;
> - return -ENOMEM;
> - }
> - fi->data = nb;
> + if (nb)
> + fi->data = nb;
Does this one impact the reproducibility?
I mean that if realloc fails, we should just error out instead of
falling back, otherwise the generated image can be different.
Thanks,
Gao Xiang
> fi->pos = (erofs_off_t)offset;
> erofs_up_write(&bk->lock);
> inode->fragmentoff = fi->pos - len;
> --
> 2.56.0
>
>
next prev parent reply other threads:[~2026-11-12 23:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 12:47 [PATCH 0/8] erofs-utils: fix issues found by LLMs Yifan Zhao
2026-11-12 12:47 ` [PATCH 1/8] erofs-utils: lib: fix arithmetic overflow in large file handling Yifan Zhao
2026-11-12 12:47 ` [PATCH 2/8] erofs-utils: mkfs: fix incremental superblock stack overread Yifan Zhao
2026-11-12 12:47 ` [PATCH 3/8] erofs-utils: tar: fix out-of-bounds access when trimming PAX paths Yifan Zhao
2026-11-12 12:47 ` [PATCH 4/8] erofs-utils: lib: fix buffer leaks in error paths Yifan Zhao
2026-11-12 23:20 ` Gao Xiang [this message]
2026-11-12 12:47 ` [PATCH 5/8] erofs-utils: exclude: fix stack overflow when checking long paths Yifan Zhao
2026-11-12 12:47 ` [PATCH 6/8] erofs-utils: lib: fix gzran EOF handling and state leaks Yifan Zhao
2026-11-12 12:47 ` [PATCH 7/8] erofs-utils: lib: fix metabox inline data reads Yifan Zhao
2026-11-12 12:47 ` [PATCH 8/8] erofs-utils: fix read error and short read handling Yifan Zhao
2026-11-12 23:41 ` Gao Xiang
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=avZJ00X9YuOPSkHw@MacBookPro.fritz.box \
--to=xiang@kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=stopire@gmail.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