On Wed, Jun 03, 2015 at 02:09:27AM +0000, Sheng Yong wrote: > From: Filipe Manana <[email protected]> > > commit 5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339 upstream. > > Replacing a xattr consists of doing a lookup for its existing value, delete > the current value from the respective leaf, release the search path and then > finally insert the new value. This leaves a time window where readers > (getxattr, > listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs, > so this has security implications. > > This change also fixes 2 other existing issues which were: > > *) Deleting the old xattr value without verifying first if the new xattr will > fit in the existing leaf item (in case multiple xattrs are packed in the > same item due to name hash collision); > > *) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't > exist but we have have an existing item that packs muliple xattrs with > the same name hash as the input xattr. In this case we should return > ENOSPC. > > A test case for xfstests follows soon. > > Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace > implementation. > > Reported-by: Alexandre Oliva <[email protected]> > Signed-off-by: Filipe Manana <[email protected]> > Signed-off-by: Chris Mason <[email protected]> > [shengyong: backport to 3.10 > - FIX: CVE-2014-9710 > - adjust context > - ASSERT() was added v3.12, so we do check with if statement > - set the first parameter of btrfs_item_nr() as NULL, because it is not > used, and is removed in v3.13 > ] > Signed-off-by: Sheng Yong <[email protected]>
Thanks, I've also added this to 3.14-stable. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
