Re: [PATCH] ocfs2: retain all security xattrs during inode creation

[Joseph Qi]

On 9/16/26 9:54 PM, Heming Zhao wrote:
> On Wed, Sep 16, 2026 at 08:02:58PM +0800, Joseph Qi wrote:
>> When creating a new inode, ocfs2_init_security_get() stores the
>> security xattr returned by the LSM framework in
>> ocfs2_security_xattr_info so that it can be written later within the
>> same transaction.  But ocfs2_initxattrs() only ever looks at the
>> first element of the xattr array, and it keeps the name as a bare
>> pointer into memory owned by the security layer instead of copying
>> it.  The value, by contrast, is already duplicated with kmemdup().
>>
>> With stacked LSMs, security_inode_init_security() provides one xattr
>> per LSM, so all labels but the first are silently dropped and never
>> written to disk, leaving newly created files without the security
>> xattrs the other LSMs rely on.
>>
>> The borrowed name is not an outright bug with the LSMs in tree
>> today: security_inode_init_security() frees only ->value once the
>> callback returns, and documents ->name as the attribute name
>> suffix, so the pointer stays valid for as long as ocfs2 uses it.
>> It is fragile though, as an LSM that allocates the name together
>> with the value would turn it into a use-after-free, so the rework
>> below copies the names as well.
>>
>> Fix this by storing copies of all the security xattrs: allocate an
>> array in ocfs2_initxattrs(), copy the names and values, account for
>> all of them in the credit calculations, and write each one in
>> ocfs2_init_security_set().
>>
>> While at it, switch the allocations from GFP_KERNEL to GFP_NOFS.
>> The callback runs in the inode creation path with the parent
>> directory locked, and the security layer allocates the very same
>> xattr array with GFP_NOFS, so direct reclaim must not be allowed to
>> recurse into the filesystem from here.
>>
>> Fixes: de3004c874e7 ("ocfs2: Switch to security_inode_init_security()")
>> Signed-off-by: Joseph Qi <joseph.qi@xxxxxxxxxxxxxxxxx>
> 
> The code looks good to me.
> Reviewed-by: Heming Zhao <heming.zhao@xxxxxxxx>

Thanks, sashiko has review comments for the case of 512B block size:
https://sashiko.dev/#/patchset/20260916120258.3583355-1-joseph.qi@xxxxxxxxxxxxxxxxx?part=1

It looks simple and I'll address it in v2.

BTW, I've sent the update policy including cc ocfs2-devel, but It hasn't
been merged yet.

Thanks,
Joseph