From: sashiko-bot@kernel.org
To: "Zhihao Cheng" <chengzhihao1@huawei.com>,
richard@nod.at, ext-adrian.hunter@nokia.com
Cc: linux-mtd@lists.infradead.org, yangerkun@huawei.com, yi.zhang@huawei.com
Subject: Re: [PATCH 1/2] ubifs: tnc_delete: Don't free zero-branch znodes if memory allocation fails
Date: Wed, 14 Oct 2026 06:28:50 +0000 [thread overview]
Message-ID: <sashiko-outbox-170861@kernel.org> (raw)
In-Reply-To: <20261014060252.3531356-2-chengzhihao1@huawei.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ubifs: assertion failure on lookups due to zero-child znode after tnc_delete() error
--
commit 5c1854483c2d06b6fd3fc46791b422fcd958956f
Author: Zhihao Cheng <chengzhihao1@huawei.com>
ubifs: tnc_delete: Don't free zero-branch znodes if memory allocation fails
This commit delays the freeing of zero-branch znodes in tnc_delete()
until after all insert_old_idx_znode() calls succeed. It introduces a
local stack list to track znodes to be freed, aiming to prevent a
use-after-free race condition when traversing the TNC tree.
> diff --git a/fs/ubifs/tnc.c b/fs/ubifs/tnc.c
> --- a/fs/ubifs/tnc.c
> +++ b/fs/ubifs/tnc.c
[ ... ]
> @@ -2542,15 +2543,20 @@ static int tnc_delete(struct ubifs_info *c, struct ubifs_znode *znode, int n)
> atomic_long_dec(&c->dirty_zn_cnt);
>
> err = insert_old_idx_znode(c, znode);
> - if (err)
> + if (err) {
> + zn = free_head.fnext;
> + while (zn) {
> + struct ubifs_znode *next = zn->fnext;
> +
> + zn->fnext = NULL;
> + zn = next;
> + }
> return err;
[Severity: High]
If insert_old_idx_znode() returns an error like -ENOMEM, does this early
return leave the zero-child znode linked in the TNC tree?
Because we return before removing the znode from its parent's zbranch array,
the tree retains a node with child_cnt == 0. If a subsequent read operation
(which is permitted even after the filesystem is forced to read-only mode)
traverses this znode, it will call ubifs_search_zbranch():
fs/ubifs/tnc_misc.c:ubifs_search_zbranch() {
int beg = 0, end = znode->child_cnt, mid;
int cmp;
const struct ubifs_zbranch *zbr = &znode->zbranch[0];
ubifs_assert(c, end > beg);
...
}
With end == 0 and beg == 0, this will trigger the assertion failure, which
can panic the kernel if mounted with assert=panic. Does this error path need
to remove the znode from its parent's zbranch, or otherwise mark it to
prevent lookups from tripping the assertion?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014060252.3531356-1-chengzhihao1@huawei.com?part=1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-10-14 6:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 6:02 [PATCH 0/2] ubifs: tnc_delete: Fix two uaf bug when mem failure occurs Zhihao Cheng
2026-10-14 6:02 ` [PATCH 1/2] ubifs: tnc_delete: Don't free zero-branch znodes if memory allocation fails Zhihao Cheng
2026-10-14 6:28 ` sashiko-bot [this message]
2026-10-14 6:48 ` Zhihao Cheng
2026-10-14 6:02 ` [PATCH 2/2] ubifs: tnc_delete: Don't update collapsed " Zhihao Cheng
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=sashiko-outbox-170861@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chengzhihao1@huawei.com \
--cc=ext-adrian.hunter@nokia.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.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