Re: Patch "fs,fsverity: reject size changes on fsverity files in setattr_prepare" has been added to the 6.18-stable tree

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] vfs: verity file truncation bypass when CONFIG_FS_VERITY is disabled
--

commit 750dd8cb058f7ea5d2ca5305006f1c5e63c6eb32
Author: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>

fs,fsverity: reject size changes on fsverity files in setattr_prepare

This commit centralizes the check to reject truncates of fsverity files
into setattr_prepare() in fs/attr.c. This removes boilerplate code from
individual filesystems and fixes a missing truncation check in btrfs.

Link: https://lore.kernel.org/r/20260128152630.627409-2-hch@lst.de

> diff --git a/fs/attr.c b/fs/attr.c
> index 795f231d00e8e..2c94af08be183 100644
> --- a/fs/attr.c
> +++ b/fs/attr.c
> @@ -169,7 +169,17 @@ int setattr_prepare(struct mnt_idmap *idmap, struct dentry *dentry,
>  	 * ATTR_FORCE.
>  	 */
>  	if (ia_valid & ATTR_SIZE) {
> -		int error = inode_newsize_ok(inode, attr->ia_size);
> +		int error;
> +
> +		/*
> +		 * Verity files are immutable, so deny truncates.  This isn't
> +		 * covered by the open-time check because sys_truncate() takes a
> +		 * path, not an open file.
> +		 */
> +		if (IS_ENABLED(CONFIG_FS_VERITY) && IS_VERITY(inode))
> +			return -EPERM;

[Severity: High]
Does this logic inadvertently permit truncating verity files when
CONFIG_FS_VERITY is disabled?

Before this patch, filesystems explicitly called fsverity_prepare_setattr().
When CONFIG_FS_VERITY was disabled, the fallback implementation safely returned
-EOPNOTSUPP for any inode with the verity flag set.

By short-circuiting the check here with IS_ENABLED(CONFIG_FS_VERITY), it
appears an unprivileged user with DAC write access could use sys_truncate()
to bypass the check and modify a verity file if the kernel was built without
fsverity support.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026100754-drizzle-shape-0a72@gregkh?part=1