From: Al Viro <viro@zeniv.linux.org.uk>
To: Peng Zhang <zhangpeng362@huawei.com>
Cc: almaz.alexandrovich@paragon-software.com,
kari.argillander@gmail.com, akpm@linux-foundation.org,
ntfs3@lists.linux.dev, linux-kernel@vger.kernel.org,
sunnanyong@huawei.com, wangkefeng.wang@huawei.com,
Dan Carpenter <error27@gmail.com>
Subject: Re: [PATCH -next] fs/ntfs3: Fix potential NULL/IS_ERR bug in ntfs_lookup()
Date: Thu, 12 Jan 2023 04:11:44 +0000 [thread overview]
Message-ID: <Y7+IgD3OslNt4XKY@ZenIV> (raw)
In-Reply-To: <Y7+B40Mnnm7/rY+O@ZenIV>
On Thu, Jan 12, 2023 at 03:43:31AM +0000, Al Viro wrote:
> On Thu, Jan 12, 2023 at 01:32:48AM +0000, Peng Zhang wrote:
> > From: ZhangPeng <zhangpeng362@huawei.com>
> >
> > Dan Carpenter reported a Smatch static checker warning:
> >
> > fs/ntfs3/namei.c:96 ntfs_lookup()
> > error: potential NULL/IS_ERR bug 'inode'
> > It will cause null-ptr-deref when dir_search_u() returns NULL if the
> > file is not found.
> > Fix this by replacing IS_ERR() with IS_ERR_OR_NULL() to add a check for
> > NULL.
>
> That's a bad approach - you are papering over bad calling conventions instead of
> fixing them.
>
> IS_ERR_OR_NULL is almost never the right tool. Occasionally there are valid
> cases for function possibly returning pointer/NULL/ERR_PTR(...); this is
> almost certainly not one of those.
>
> Incidentally, inodes with NULL ->i_op should never exist. _Any_ place that
> sets ->i_op to NULL is broken, plain and simple. A new instance of struct
> inode has ->i_op pointing to empty method table; it *is* initialized.
IOW, the real bug is in ntfs_read_mft() -
inode->i_op = NULL;
in there is garbage. Unless I'm misreading the history, it used to be possible
for the damn thing to get all the way to ntfs_lookup() - up until the
commit 0e8235d28f3a "fs/ntfs3: Check fields while reading" had taken that
path out:
- if (!is_rec_base(rec))
- goto Ok;
+ if (!is_rec_base(rec)) {
+ err = -EINVAL;
+ goto out;
+ }
is the relevant part. Situation after that commit:
* useless check in ntfs_lookup() is a dead code; it should be
taken out, especially since it's broken.
* NULL assignment in ntfs_read_mft() is still garbage; thankfully,
with the current tree the inode will either have it overwritten by later
assignment or it won't make it out of ntfs_read_mft(). Still, that
assignment should be taken out and shot to get rid of bad example.
While we are at it, the calling conventions of ntfs_read_mft() could've
been better. Look:
ntfs_read_mft(inode, ...) either returns its first argument (on success) or
it disposes of the inode the argument points to and returns ERR_PTR(-E...)
(on failure). There is only one caller, and it would be easier to follow if
it had been
/* If this is a freshly allocated inode, need to read it now. */
if (inode->i_state & I_NEW) {
int err = ntfs_read_mft(inode, name, ref);
if (unlikely(err)) {
if (name)
ntfs_set_state(sb->s_fs_info, NTFS_DIRTY_ERROR);
iget_failed(inode);
return ERR_PTR(err);
}
} else if (ref->seq != ntfs_i(inode)->mi.mrec->seq) {
/* Inode overlaps? */
_ntfs_bad_inode(inode);
}
return inode;
with ntfs_read_mft() always acting the same way wrt inode refcount...
next prev parent reply other threads:[~2023-01-12 4:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 1:32 [PATCH -next] fs/ntfs3: Fix potential NULL/IS_ERR bug in ntfs_lookup() Peng Zhang
2023-01-12 3:43 ` Al Viro
2023-01-12 4:11 ` Al Viro [this message]
2023-01-13 10:05 ` Konstantin Komarov
2023-01-16 20:18 ` Al Viro
2023-01-16 20:34 ` Al Viro
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=Y7+IgD3OslNt4XKY@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=error27@gmail.com \
--cc=kari.argillander@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=sunnanyong@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=zhangpeng362@huawei.com \
/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.