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 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.