From: Waqar Hameed <waqar.hameed@axis.com>
To: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: Richard Weinberger <richard@nod.at>,
Sascha Hauer <s.hauer@pengutronix.de>, <kernel@axis.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] ubifs: Fix use-after-free in ubifs_tnc_end_commit
Date: Sun, 10 Nov 2024 22:48:50 +0100 [thread overview]
Message-ID: <pndbjymzrnh.fsf@axis.com> (raw)
In-Reply-To: <3c46013e-809e-cdcf-8648-2ffe2ab6c32b@huawei.com> (Zhihao Cheng's message of "Sat, 9 Nov 2024 10:34:25 +0800")
On Sat, Nov 09, 2024 at 10:34 +0800 Zhihao Cheng <chengzhihao1@huawei.com> wrote:
> 在 2024/10/9 22:46, Waqar Hameed 写道:
> 3 nits below.
>
> 1. Make the title as 'ubifs: authentication: Fix use-after-free in
> ubifs_tnc_end_commit'
>
> 2. At the begining of the commit msg, describe the problem:
> After TNC tree inserting(which may trigger a znode split and change the
> znode->parent) and deleting(which may trigger znode freeing), the
> znode->cparent(which still points to a freed znode) may not be updated at the
> begining of commit, which could trigger an UAF problem while accessing
> znode->cparent in write_index().
Alright, will rephrase the commit message a bit.
>
>> Running
>> rm -f /etc/test-file.bin
>> dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync
>> in a loop, with `CONFIG_UBIFS_FS_AUTHENTICATION`, KASAN reports:
>> BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950
>> Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153
>> Call trace:
>
> [...]
>> diff --git a/fs/ubifs/tnc_commit.c b/fs/ubifs/tnc_commit.c
>> index a55e04822d16..a464eb557585 100644
>> --- a/fs/ubifs/tnc_commit.c
>> +++ b/fs/ubifs/tnc_commit.c
>> @@ -657,6 +657,7 @@ static int get_znodes_to_commit(struct ubifs_info *c)
>> znode->alt = 0;
>> cnext = find_next_dirty(znode);
>> if (!cnext) {
>
> 3. I'd like to add the the assertion 'ubifs_assert(c, !znode->parent);'
Wouldn't the assert always be true? Since the root node wouldn't have a
parent. Or are we afraid of some other edge cases (bugs?) that might
have been missed and want to be defensive here? Either way, I'll add the
assert.
>> + znode->cparent = NULL;
>> znode->cnext = c->cnext;
>> break;
>> }
>>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Waqar Hameed <waqar.hameed@axis.com>
To: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: Richard Weinberger <richard@nod.at>,
Sascha Hauer <s.hauer@pengutronix.de>, <kernel@axis.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] ubifs: Fix use-after-free in ubifs_tnc_end_commit
Date: Sun, 10 Nov 2024 22:48:50 +0100 [thread overview]
Message-ID: <pndbjymzrnh.fsf@axis.com> (raw)
In-Reply-To: <3c46013e-809e-cdcf-8648-2ffe2ab6c32b@huawei.com> (Zhihao Cheng's message of "Sat, 9 Nov 2024 10:34:25 +0800")
On Sat, Nov 09, 2024 at 10:34 +0800 Zhihao Cheng <chengzhihao1@huawei.com> wrote:
> 在 2024/10/9 22:46, Waqar Hameed 写道:
> 3 nits below.
>
> 1. Make the title as 'ubifs: authentication: Fix use-after-free in
> ubifs_tnc_end_commit'
>
> 2. At the begining of the commit msg, describe the problem:
> After TNC tree inserting(which may trigger a znode split and change the
> znode->parent) and deleting(which may trigger znode freeing), the
> znode->cparent(which still points to a freed znode) may not be updated at the
> begining of commit, which could trigger an UAF problem while accessing
> znode->cparent in write_index().
Alright, will rephrase the commit message a bit.
>
>> Running
>> rm -f /etc/test-file.bin
>> dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync
>> in a loop, with `CONFIG_UBIFS_FS_AUTHENTICATION`, KASAN reports:
>> BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950
>> Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153
>> Call trace:
>
> [...]
>> diff --git a/fs/ubifs/tnc_commit.c b/fs/ubifs/tnc_commit.c
>> index a55e04822d16..a464eb557585 100644
>> --- a/fs/ubifs/tnc_commit.c
>> +++ b/fs/ubifs/tnc_commit.c
>> @@ -657,6 +657,7 @@ static int get_znodes_to_commit(struct ubifs_info *c)
>> znode->alt = 0;
>> cnext = find_next_dirty(znode);
>> if (!cnext) {
>
> 3. I'd like to add the the assertion 'ubifs_assert(c, !znode->parent);'
Wouldn't the assert always be true? Since the root node wouldn't have a
parent. Or are we afraid of some other edge cases (bugs?) that might
have been missed and want to be defensive here? Either way, I'll add the
assert.
>> + znode->cparent = NULL;
>> znode->cnext = c->cnext;
>> break;
>> }
>>
next prev parent reply other threads:[~2024-11-10 21:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 14:46 [PATCH v2] ubifs: Fix use-after-free in ubifs_tnc_end_commit Waqar Hameed
2024-10-09 14:46 ` Waqar Hameed
2024-11-09 2:34 ` Zhihao Cheng
2024-11-09 2:34 ` Zhihao Cheng
2024-11-10 21:48 ` Waqar Hameed [this message]
2024-11-10 21:48 ` Waqar Hameed
2024-11-11 1:23 ` Zhihao Cheng
2024-11-11 1:23 ` 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=pndbjymzrnh.fsf@axis.com \
--to=waqar.hameed@axis.com \
--cc=chengzhihao1@huawei.com \
--cc=kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=s.hauer@pengutronix.de \
/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.