Linux fsverity development list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Andrey Albershteyn" <aalbersh@kernel.org>,
	ebiggers@kernel.org, hch@lst.de,
	"Carlos Maiolino" <cem@kernel.org>,
	fsverity@lists.linux.dev
Cc: david@fromorbit.com, "Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH v18 11/15] xfs: add fs-verity ioctls
Date: Mon, 02 Nov 2026 15:24:44 +0000	[thread overview]
Message-ID: <sashiko-outbox-193657@kernel.org> (raw)
In-Reply-To: <20261102144147.2393369-12-aalbersh@kernel.org>

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] xfs: premature S_VERITY set before xfs_free_eofblocks() causes UAF
- [Critical] xfs: fs-verity triggers compound page BUG_ON on large block size fs
- [High] xfs: xfs_fsverity_end_enable() skips rollback cleanup when desc is NULL
- [Medium] xfs: xfs_fileattr_set() rejects FS_VERITY_FL during FS_IOC_SETFLAGS
- [Medium] xfs: xfs_fileattr_set() races with in-progress FS_IOC_ENABLE_VERITY
--

commit 2331d2406515413653c5db56870e5226577de902
Author: Andrey Albershteyn <aalbersh@kernel.org>

xfs: add fs-verity ioctls

This commit exposes the FS_IOC_ENABLE_VERITY, FS_IOC_MEASURE_VERITY, and
FS_IOC_READ_VERITY_METADATA ioctls in xfs_file_ioctl() when the filesystem
has the verity feature enabled.

> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index f81b6e52ac403..37c6a2fae58cc 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c

[ ... ]

> @@ -1575,6 +1576,19 @@ xfs_file_ioctl(
>  	case XFS_IOC_VERIFY_MEDIA:
>  		return xfs_ioc_verify_media(filp, arg);
>  
> +	case FS_IOC_ENABLE_VERITY:
> +		if (!xfs_has_verity(mp))
> +			return -EOPNOTSUPP;
> +		return fsverity_ioctl_enable(filp, arg);

[Severity: High]
When FS_IOC_ENABLE_VERITY fails during Merkle tree construction or
descriptor validation, enable_verity() rolls back by calling
vops->end_enable_verity(filp, NULL, 0, params.tree_size).

In fs/xfs/xfs_fsverity.c:xfs_fsverity_end_enable(), local variable error is
initialized to 0 and the NULL descriptor check jumps directly to out:

	int			error = 0;
	loff_t			range_start = xfs_fsverity_metadata_offset(ip);

	xfs_assert_ilocked(ip, XFS_IOLOCK_EXCL);

	/* fs-verity failed, just cleanup */
	if (desc == NULL)
		goto out;
	...
out:
	if (error) {
		int	error2;

		error2 = xfs_fsverity_reset_inode(ip);
		if (error2)
			xfs_alert(ip->i_mount,
"ino 0x%llx failed to clean up new fsverity metadata, err %d",
					I_INO(ip), error2);
	}

	xfs_iflags_clear(ip, XFS_VERITY_CONSTRUCTION);
	return error;

Because error is 0 when desc is NULL, won't xfs_fsverity_reset_inode(ip) be
skipped on rollback, leaving dirty post-EOF Merkle tree folios in
inode->i_mapping and delayed allocation extents in ip->i_df after
XFS_VERITY_CONSTRUCTION is cleared?

[Severity: Medium]
While fsverity_ioctl_enable() -> enable_verity() is building the Merkle
tree, inode_lock(inode) is dropped between xfs_fsverity_begin_enable() and
xfs_fsverity_end_enable(), and XFS_DIFLAG2_VERITY is not set until
xfs_fsverity_end_enable().

During that window, can a concurrent FS_IOC_FSSETXATTR, FS_IOC_SETFLAGS, or
file_setattr call enter xfs_fileattr_set() -> xfs_ioctl_setattr_xflags()
and set XFS_DIFLAG2_DAX or XFS_DIFLAG_REALTIME (including bigrtalloc) on
the inode because neither function checks
xfs_iflags_test(ip, XFS_VERITY_CONSTRUCTION)?

[Severity: Medium]
Once FS_IOC_ENABLE_VERITY sets XFS_DIFLAG2_VERITY on an inode,
FS_IOC_GETFLAGS reports FS_VERITY_FL via:

  ioctl_getflags()
    -> xfs_fileattr_get()
      -> xfs_fill_fsxattr()
        -> fileattr_fill_xflags(fa, xfs_ip2xflags(ip))

When userspace tools such as chattr perform a read-modify-write via
FS_IOC_SETFLAGS (where fa->fsx_valid is false), fs/xfs/xfs_ioctl.c:
xfs_fileattr_set() checks:

	if (!fa->fsx_valid) {
		unsigned int allowed = FS_IMMUTABLE_FL | FS_APPEND_FL |
				       FS_NOATIME_FL | FS_NODUMP_FL |
				       FS_SYNC_FL | FS_DAX_FL |
				       FS_PROJINHERIT_FL;
...
		if (xfs_has_asciici(mp))
			allowed |= FS_CASEFOLD_FL;

		if (fa->flags & ~allowed)
			return -EOPNOTSUPP;
	}

Since FS_VERITY_FL is not included in allowed even when XFS_DIFLAG2_VERITY
is already set on the inode, won't FS_IOC_SETFLAGS updates (such as
chattr +i or chattr +a) on verity-enabled files fail with -EOPNOTSUPP?

[Severity: Critical]
On XFS filesystems where sb_blocksize > PAGE_SIZE (or whenever compound
folios are instantiated in inode->i_mapping), xfs_fsverity_begin_enable()
allows enabling verity, and fs/xfs/xfs_fsverity.c:xfs_fsverity_read_merkle()
fetches Merkle tree pages via generic_read_merkle_tree_page():

static struct page *
xfs_fsverity_read_merkle(
	struct inode		*inode,
	pgoff_t			index)
{
	index += xfs_fsverity_metadata_offset(XFS_I(inode)) >> PAGE_SHIFT;

	return generic_read_merkle_tree_page(inode, index);
}

When verify_data_block() and is_hash_block_verified() subsequently call
PageChecked() and SetPageChecked() on the returned struct page belonging to
a compound folio, won't SetPageChecked() trigger
VM_BUG_ON_PGFLAGS(PageCompound(page), page) (defined via PF_NO_COMPOUND) and
corrupt tail page flags?

> +	case FS_IOC_MEASURE_VERITY:
> +		if (!xfs_has_verity(mp))
> +			return -EOPNOTSUPP;
> +		return fsverity_ioctl_measure(filp, arg);
> +	case FS_IOC_READ_VERITY_METADATA:
> +		if (!xfs_has_verity(mp))
> +			return -EOPNOTSUPP;
> +		return fsverity_ioctl_read_metadata(filp, arg);

[Severity: Critical]
In fs/xfs/xfs_fsverity.c:xfs_fsverity_end_enable(), S_VERITY is set on the
VFS inode before calling xfs_free_eofblocks(ip):

	inode_set_flags(inode, S_VERITY, S_VERITY);

	/*
	 * Proactively remove unwritten extents left by COW preallocations and
	 * write preallocation in the merkle tree holes and past descriptor,
	 * and any delayed preallocations
	 */
	error = xfs_free_eofblocks(ip);
out:
	if (error) {
		int	error2;

		error2 = xfs_fsverity_reset_inode(ip);

Because enable_verity() has already hashed struct fsverity_info via
fsverity_set_info() before calling vops->end_enable_verity(), setting
S_VERITY makes fsverity_get_info(inode) return that unrefcounted pointer to
concurrent readers (buffered reads queueing bio verification work,
FS_IOC_MEASURE_VERITY, and FS_IOC_READ_VERITY_METADATA) while
xfs_free_eofblocks(ip) is still running.

If xfs_free_eofblocks(ip) fails, xfs_fsverity_reset_inode(ip) clears
S_VERITY (or leaves S_VERITY set if xfs_fsverity_delete_metadata(ip) also
fails) and enable_verity() removes and RCU-frees struct fsverity_info via
fsverity_remove_info(vi). Can concurrent readers or queued verification work
items then dereference the freed fsverity_info, or can concurrent
FS_IOC_READ_VERITY_METADATA calls invoke xfs_fsverity_get_descriptor() ->
xfs_bmap_last_extent() before xfs_free_eofblocks(ip) removes trailing
post-descriptor preallocations? Should inode_set_flags(inode, S_VERITY,
S_VERITY) only be called after xfs_free_eofblocks(ip) succeeds and rollback
is no longer possible?

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

  reply	other threads:[~2026-11-02 15:24 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 14:41 [PATCH v18 00/15] fs-verity support for XFS with post EOF merkle tree Andrey Albershteyn
2026-11-02 14:41 ` [PATCH v18 01/15] xfs: introduce fsverity on-disk changes Andrey Albershteyn
2026-11-02 15:08   ` sashiko-bot
2026-11-02 14:41 ` [PATCH v18 02/15] xfs: don't allow to enable DAX on fs-verity sealed inode Andrey Albershteyn
2026-11-02 14:41 ` [PATCH v18 03/15] xfs: disable direct read path for fs-verity files Andrey Albershteyn
2026-11-02 14:41 ` [PATCH v18 04/15] xfs: don't report dio_mem_align and dio_offset_align for fsverity files Andrey Albershteyn
2026-11-03  9:23   ` Christoph Hellwig
2026-11-02 14:41 ` [PATCH v18 05/15] xfs: handle fsverity I/O in write/read path Andrey Albershteyn
2026-11-02 15:13   ` sashiko-bot
2026-11-03  9:37   ` Christoph Hellwig
2026-11-03 13:55     ` Andrey Albershteyn
2026-11-03 14:53       ` Christoph Hellwig
2026-11-03 15:26         ` Andrey Albershteyn
2026-11-03 22:03         ` Eric Biggers
2026-11-02 14:41 ` [PATCH v18 06/15] xfs: use read ioend for fsverity data verification Andrey Albershteyn
2026-11-02 14:57   ` sashiko-bot
2026-11-03  9:39   ` Christoph Hellwig
2026-11-02 14:41 ` [PATCH v18 07/15] xfs: add XFS_BMAPI_UNWRITTEN to unmap unwritten extents in __xfs_bunmapi() Andrey Albershteyn
2026-11-02 15:02   ` sashiko-bot
2026-11-03  9:41   ` Christoph Hellwig
2026-11-03 14:31     ` Andrey Albershteyn
2026-11-03 14:39       ` Christoph Hellwig
2026-11-03 14:45         ` Andrey Albershteyn
2026-11-03 14:49           ` Christoph Hellwig
2026-11-03 15:17             ` Andrey Albershteyn
2026-11-02 14:41 ` [PATCH v18 08/15] xfs: don't remove written extents past EOF on fsverity inodes Andrey Albershteyn
2026-11-02 15:11   ` sashiko-bot
2026-11-03  9:42   ` Christoph Hellwig
2026-11-02 14:41 ` [PATCH v18 09/15] xfs: add fs-verity support Andrey Albershteyn
2026-11-02 15:34   ` sashiko-bot
2026-11-03 18:23     ` Eric Biggers
2026-11-02 14:41 ` [PATCH v18 10/15] xfs: initialize fs-verity on file open Andrey Albershteyn
2026-11-02 14:41 ` [PATCH v18 11/15] xfs: add fs-verity ioctls Andrey Albershteyn
2026-11-02 15:24   ` sashiko-bot [this message]
2026-11-02 14:41 ` [PATCH v18 12/15] xfs: advertise fs-verity being available on filesystem Andrey Albershteyn
2026-11-02 14:41 ` [PATCH v18 13/15] xfs: check and repair the verity inode flag state Andrey Albershteyn
2026-11-02 15:28   ` sashiko-bot
2026-11-02 14:41 ` [PATCH v18 14/15] xfs: introduce health state for corrupted fsverity metadata Andrey Albershteyn
2026-11-02 15:16   ` sashiko-bot
2026-11-02 14:41 ` [PATCH v18 15/15] xfs: enable ro-compat fs-verity flag Andrey Albershteyn
2026-11-02 15:35   ` sashiko-bot
2026-11-03  9:44   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-193657@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aalbersh@kernel.org \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=fsverity@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox