Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
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/

  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