Re: [PATCH] fsverity: Set S_VERITY only after rollback is no longer possible

[sashiko-bot@kernel.org]

> Commit f77f281b6118 ("fsverity: use a hashtable to find the
> fsverity_info") changed the implementation of FS_IOC_ENABLE_VERITY to
> make concurrent reads start going through fsverity verification slightly
> earlier than they did before.
> 
> Instead of it happening when enable_verity() calls fsverity_set_info(),
> it now happens when ->end_enable_verity() sets S_VERITY.
> 
> However, ext4 and btrfs can roll back verity after they set S_VERITY,
> causing a use-after-free.
> 
> Fix that by making ext4 and btrfs set S_VERITY only after rollback is no
> longer possible.  On failure, don't roll back S_VERITY, but do roll back
> the filesystem-specific verity flag.
> 
> Also update enable_verity() to handle any future instances of this bug
> more safely by warning and *not* freeing the fsverity_info.
> 
> Finally, tweak some comments.  Clarify one, and move information from
> another to its proper place in the comment for ->end_enable_verity().
> 
> Fixes: f77f281b6118 ("fsverity: use a hashtable to find the fsverity_info")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261025204807.122875-1-ebiggers@kernel.org?part=1