From: Cong Ding <dinggnu@gmail.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: Chris Mason <clmason@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] btrfs: fix potential null pointer dereference bug
Date: Thu, 24 Jan 2013 18:46:42 -0500 [thread overview]
Message-ID: <20130124234642.GA29022@gmail.com> (raw)
In-Reply-To: <20130124153420.GC2349@localhost.localdomain>
On Thu, Jan 24, 2013 at 10:34:20AM -0500, Josef Bacik wrote:
> On Sat, Jan 19, 2013 at 08:27:45AM -0700, Cong Ding wrote:
> > The bug happens when rb_node == NULL. It causes variable node to be NULL and
> > then the NULL pointer is dereferenced this line:
> > BUG_ON((struct btrfs_root *)node->data != root);
> >
> > Based on my analysis, function tree_search should not return NULL to variable
> > rb_node in this case (otherwise here has to be something unknown thing wrong),
> > so I replace "if (rb_node)" with UG_ON(!rb_node).
> >
> > Signed-off-by: Cong Ding <dinggnu@gmail.com>
>
> I don't want to add more BUG_ON()'s, just return an error.
But rb_node really has no chance to be 0, so I think we should use BUG_ON
rather than return an error. If we return an error number here, its caller
should check the returned value and call BUG_ON(ret) - it makes no difference.
The file system doesn't have any way to handle this kind of error (and I think
if it happens, there must be some hardware error or some other program
directly operates on the file system bypassing linux system call). If you
don't want to add more BUG_ON, I suggest to check variable "node" in the
existing BUG_ON as the following code.
- BUG_ON((struct btrfs_root *)node->data != root);
+ BUG_ON(!node || (struct btrfs_root *)node->data != root);
What's your opinion, or do you have a better solution?
Thanks,
- cong
>From 3a5b4df67dd177b7cbc61c555349fd7e87ef6b54 Mon Sep 17 00:00:00 2001
From: Cong Ding <dinggnu@gmail.com>
Date: Thu, 24 Jan 2013 18:30:45 -0500
Subject: [PATCH] btrfs: fix potential null pointer dereference bug
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node->data != root);
So we check node before the dereference.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
---
fs/btrfs/relocation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 17c306b..938b037 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1269,7 +1269,7 @@ static int __update_reloc_root(struct btrfs_root *root, int del)
}
spin_unlock(&rc->reloc_root_tree.lock);
- BUG_ON((struct btrfs_root *)node->data != root);
+ BUG_ON(!node || (struct btrfs_root *)node->data != root);
if (!del) {
spin_lock(&rc->reloc_root_tree.lock);
--
1.7.10.4
prev parent reply other threads:[~2013-01-24 23:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-19 15:27 [PATCH] btrfs: fix potential null pointer dereference bug Cong Ding
2013-01-24 15:34 ` Josef Bacik
2013-01-24 23:46 ` Cong Ding [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=20130124234642.GA29022@gmail.com \
--to=dinggnu@gmail.com \
--cc=clmason@fusionio.com \
--cc=jbacik@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).