From: "Toralf Förster" <toralf.foerster@gmx.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: fs/debugfs/inode.c: thoughts about "CID 101681 Dereference after null check"
Date: Sat, 12 Apr 2014 20:47:51 +0200 [thread overview]
Message-ID: <53498A57.2080004@gmx.de> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Just for fun (and to learn a little bit) I picked up an arbitrary entry from coverity [1] :
CID 101681 Dereference after null check
Either the check against null is unnecessary, or there may be a null pointer dereference.
In debugfs_rename: Pointer is checked against null but then dereferenced anyway
IMO it might be a real issue. At line 606 of fs/debugfs/inode.c we have:
trap = lock_rename(new_dir, old_dir);
/* Source or destination directories don't exist? */
if (!old_dir->d_inode || !new_dir->d_inode)
goto exit;
and later :
exit:
if (dentry && !IS_ERR(dentry))
dput(dentry);
unlock_rename(new_dir, old_dir);
return NULL;
And in the file fs/namei.c starting with line 2481 we do have :
void unlock_rename(struct dentry *p1, struct dentry *p2)
{
mutex_unlock(&p1->d_inode->i_mutex);
if (p1 != p2) {
mutex_unlock(&p2->d_inode->i_mutex);
mutex_unlock(&p1->d_inode->i_sb->s_vfs_rename_mutex);
}
}
I'm wondering if the NULL check should be made before lock_rename() and probably just returns NULL, eg.:
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 8c41b52..7ead0f6 100644
- --- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -603,10 +603,10 @@ struct dentry *debugfs_rename(struct dentry *old_dir, struct dentry *old_dentry,
struct dentry *dentry = NULL, *trap;
const char *old_name;
- - trap = lock_rename(new_dir, old_dir);
/* Source or destination directories don't exist? */
if (!old_dir->d_inode || !new_dir->d_inode)
- - goto exit;
+ return NULL;
+ trap = lock_rename(new_dir, old_dir);
/* Source does not exist, cyclic rename, or mountpoint? */
if (!old_dentry->d_inode || old_dentry == trap ||
d_mountpoint(old_dentry))
[1] https://scan5.coverity.com:8443/reports.htm#v32611/p10063/fileInstanceId=55651059&defectInstanceId=17130709&mergedDefectId=101681&eventId=17130709-7
- --
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlNJilcACgkQxOrN3gB26U5Y6AD7BYgw4eNSRZQsQj2B8dx5rr+S
TWXKJbTdU/YbBYMRU0wA/Anqpr/i9HoSLN20L57F6U+1uJir4WTXWCIenjV/jpkY
=MuEz
-----END PGP SIGNATURE-----
reply other threads:[~2014-04-12 18:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=53498A57.2080004@gmx.de \
--to=toralf.foerster@gmx.de \
--cc=gregkh@linuxfoundation.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 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.