From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Haotian Zhang <vulab@iscas.ac.cn>,
glaubitz@physik.fu-berlin.de, frank.li@vivo.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HFS: btree: fix missing error check after hfs_bnode_find()
Date: Thu, 11 Dec 2025 15:13:01 -0800 [thread overview]
Message-ID: <3a143f53da945f7bad35aaff7bb40b1b6255d5ba.camel@dubeyko.com> (raw)
In-Reply-To: <20251209021401.1854-1-vulab@iscas.ac.cn>
On Tue, 2025-12-09 at 10:14 +0800, Haotian Zhang wrote:
> In hfs_brec_insert() and hfs_brec_update_parent(), hfs_bnode_find()
> may return ERR_PTR() on failure, but the result was used without
> checking, risking NULL pointer dereference or invalid pointer usage.
>
> Add IS_ERR() checks after these calls and return PTR_ERR()
> on error.
>
> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
> ---
> fs/hfs/brec.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/hfs/brec.c b/fs/hfs/brec.c
> index e49a141c87e5..afa1840a4847 100644
> --- a/fs/hfs/brec.c
> +++ b/fs/hfs/brec.c
> @@ -149,6 +149,8 @@ int hfs_brec_insert(struct hfs_find_data *fd,
> void *entry, int entry_len)
> new_node->parent = tree->root;
> }
> fd->bnode = hfs_bnode_find(tree, new_node->parent);
> + if (IS_ERR(fd->bnode))
> + return PTR_ERR(fd->bnode);
>
> /* create index data entry */
> cnid = cpu_to_be32(new_node->this);
> @@ -449,6 +451,8 @@ static int hfs_brec_update_parent(struct
> hfs_find_data *fd)
> new_node->parent = tree->root;
> }
> fd->bnode = hfs_bnode_find(tree, new_node->parent);
> + if (IS_ERR(fd->bnode))
> + return PTR_ERR(fd->bnode);
> /* create index key and entry */
> hfs_bnode_read_key(new_node, fd->search_key, 14);
> cnid = cpu_to_be32(new_node->this);
Frankly speaking, I am not sure that we need to add this check.
Because, we are trying to find the parent node that already has been
found in above logic of the method. So, we should have the parent node
available. Potentially, logic could work in wrong way, but we should
already have a reported bug already.
Even if this check makes sense, then we cannot simply return the error
code here. If you check the following logic, then you can see that we
call hfs_bnode_put() for the new node. So, if this check doesn't do
this in the case of error, then we create the leak here.
Have you ever reproduced the issue that you are trying to fix?
Thanks,
Slava.
prev parent reply other threads:[~2025-12-11 23:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 2:14 Haotian Zhang
2025-12-10 17:09 ` Markus Elfring
2025-12-11 23:13 ` Viacheslav Dubeyko [this message]
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=3a143f53da945f7bad35aaff7bb40b1b6255d5ba.camel@dubeyko.com \
--to=slava@dubeyko.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vulab@iscas.ac.cn \
/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
all inboxes | Powered by JetHome®