[PATCH 0/3] fixes for ubifs xattr operations

[Hou Tao]

Hi Richard,

I have written two xfstest cases [1] for these fixes three months ago, could you please
check whether the proposed solution is OK ?

Regards,
Tao

[1]: https://www.spinics.net/lists/fstests/msg14383.html

On 2020/6/30 21:04, Hou Tao wrote:
> Hi,
> 
> The patch set tries to fix the race between ubifs xattr read
> operations and write operations.
> 
> Now inode_lock() is acquired during xattr write ops (set & remove),
> however no extra lock is taken in xattr read ops (list & get), and
> it leads to three problems:
> 
> (1) ubifs_listxattr() may incur memory corruption and assertion failure
> 
> (2) ubifs_xattr_get() may incur assertion failure
> 
> (3) ubifs_xattr_get() may return a stale xattr value
> 
> To fix it, instead of adding a xattr-related rwsem for ubifs inode,
> we decide to fix these problems simply and still do xattr read operation
> locklessly. The major concern is that xattr read operations (list & get)
> may return xattr names or values which is still in creation or removal
> process, but we think that's OK because no stale name or value is
> returned, just either the old ones or the new ones.
> 
> Comments are weclome.
> 
> Regards,
> Tao
> 
> Hou Tao (3):
>   ubifs: check the remaining name buffer during xattr list
>   ubifs: protect assertion of xattr value size by ui_mutex during xattr
>     get
>   ubifs: ensure only one in-memory xattr inode is created
> 
>  fs/ubifs/xattr.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>