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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox