[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120914200557.GP19694@redhat.com>
Date: Fri, 14 Sep 2012 16:05:57 -0400
From: Aristeu Rozanski <aris@...hat.com>
To: Sasha Levin <levinsasha928@...il.com>
Cc: tj@...nel.org, dan.carpenter@...cle.com, fengguang.wu@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Revert "xattr: mark variable as uninitialized to
make both gcc and smatch happy"
Sasha,
On Fri, Sep 14, 2012 at 09:35:53PM +0200, Sasha Levin wrote:
> This reverts commit 0142145ddb1d6c841be4eae2c7a32dd18ad34b24.
>
> Short version:
>
> Not initializing 'new_xattr' at the beginning of __simple_xattr_set() may lead to
> dereferencing it later on in the function.
>
>
> Long version:
>
> The fix for the warnings generated by smatch due to 'new_xattr' being dereferenced
> without a check from being non-NULL is incorrect.
>
> The problem is that the fix removed initialization of new_xattr with NULL, which
> meant that new_xattr could be anything at the beginning of __simple_xattr_set(),
> and might have not been initialized at any point throughout the function.
>
> In case new_xattr does get left uninitialized ('value == 0' case) and XATTR_REPLACE
> being set, the fix will actually lead us to dereferencing new_xattr even if we wouldn't
> have done so before.
>
> Why? Looking at the original code:
>
> if (flags & XATTR_REPLACE) {
> xattr = new_xattr;
> err = -ENODATA;
> } else if (new_xattr) {
> list_add(&new_xattr->list, &xattrs->head);
> xattr = NULL;
> }
> out:
> spin_unlock(&xattrs->lock);
> if (xattr) {
> kfree(xattr->name);
> kfree(xattr);
> }
> return err;
not to mention this:
list_for_each_entry(xattr, &xattrs->head, list) {
if (!strcmp(name, xattr->name)) {
if (flags & XATTR_CREATE) {
xattr = new_xattr;
err = -EEXIST;
} else if (new_xattr) {
list_replace(&xattr->list, &new_xattr->list);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
} else {
list_del(&xattr->list);
}
goto out;
}
}
Good catch.
--
Aristeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists