Re: [request for 3.10 inclusion][PATCH 3/3] Btrfs: make xattr replace operations atomic

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Jun 03, 2015 at 02:09:27AM +0000, Sheng Yong wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> 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 <oliva@gnu.org>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> Signed-off-by: Chris Mason <clm@fb.com>
> [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 <shengyong1@huawei.com>

Thanks, I've also added this to 3.14-stable.

greg k-h