[PATCH 6.1] fsverity: Explicitly require FMODE_READ to retrieve hashes

[PATCH 6.1] fsverity: Explicitly require FMODE_READ to retrieve hashes

[Eric Biggers]

commit 1acb4fd2d011c4bd6cc961095ae17361c71ff61a upstream.

The comment in fsverity_ioctl_read_metadata(), which justifies not
checking for FMODE_READ, doesn't consider that the nonstandard access
mode 3 (ioctl-only) exists.

Opening an ioctl-only fd generally requires read (and write) permission.
However, there are gaps with certain LSMs: an ioctl-only fd requests
read (and write) permission via security_inode_permission, but not
security_file_open.  With certain LSMs relying on the latter, such as
Landlock and AppArmor, an ioctl-only fd can be opened without the LSM
granting read (and write) permission.

Since FS_IOC_READ_VERITY_METADATA returns hashes of file contents
blocks, it should require read permission.  This also applies to
FS_IOC_MEASURE_VERITY, which returns a hash for the whole file.

Meanwhile, ioctl-only fds are a rarely-used feature, not known to be
used with either ioctl.

Therefore, just disallow these ioctls on ioctl-only file descriptors,
similar to what was already done with FS_IOC_ENABLE_VERITY.

More specifically, explicitly check for FMODE_READ.  This also covers
write-only fds to non-verity files which otherwise would have failed
with ENODATA.  This change in error code for write-only fds should be
fine too, as these ioctls cannot be usefully used with write-only fds
anyway, but it's worth noting as another technicality.

Fixes: 4dd893d832cf ("fs-verity: implement FS_IOC_MEASURE_VERITY ioctl")
Fixes: e17fe6579de0 ("fs-verity: add FS_IOC_READ_VERITY_METADATA ioctl")
Cc: stable@vger.kernel.org
Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Link: https://patch.msgid.link/20261022211522.1489943-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
 Documentation/filesystems/fsverity.rst |  3 +++
 fs/verity/measure.c                    | 10 ++++++++++
 fs/verity/read_metadata.c              | 14 ++++++++++----
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index cb8e7573882a1..3c7ddd6790baa 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -157,6 +157,7 @@ fatal signal), no changes are made to the file.
 FS_IOC_ENABLE_VERITY can fail with the following errors:
 
 - ``EACCES``: the process does not have write access to the file
+- ``EBADF``: the file descriptor is not open for reading
 - ``EBADMSG``: the signature is malformed
 - ``EBUSY``: this ioctl is already running on the file
 - ``EEXIST``: the file already has verity enabled
@@ -219,6 +220,7 @@ regardless of the size of the file.
 
 FS_IOC_MEASURE_VERITY can fail with the following errors:
 
+- ``EBADF``: the file descriptor is not open for reading
 - ``EFAULT``: the caller provided inaccessible memory
 - ``ENODATA``: the file is not a verity file
 - ``ENOTTY``: this type of filesystem does not implement fs-verity
@@ -291,6 +293,7 @@ blocks from disk without actually verifying the path to the root node.
 
 FS_IOC_READ_VERITY_METADATA can fail with the following errors:
 
+- ``EBADF``: the file descriptor is not open for reading
 - ``EFAULT``: the caller provided inaccessible memory
 - ``EINTR``: the ioctl was interrupted before any data was read
 - ``EINVAL``: reserved fields were set, or ``offset + length``
diff --git a/fs/verity/measure.c b/fs/verity/measure.c
index e99c00350c28d..70735f2708772 100644
--- a/fs/verity/measure.c
+++ b/fs/verity/measure.c
@@ -28,6 +28,16 @@ int fsverity_ioctl_measure(struct file *filp, void __user *_uarg)
 	const struct fsverity_hash_alg *hash_alg;
 	struct fsverity_digest arg;
 
+	/*
+	 * This ioctl returns a hash of the file contents, so it should require
+	 * read permission.  Disallow it on ioctl-only (i.e., nonstandard access
+	 * mode 3) fds, which can in some cases be acquired without passing all
+	 * LSM read-permission checks.  Also disallow write-only fds, which can
+	 * refer only to non-verity files which would fail with ENODATA anyway.
+	 */
+	if (!(filp->f_mode & FMODE_READ))
+		return -EBADF;
+
 	vi = fsverity_get_info(inode);
 	if (!vi)
 		return -ENODATA; /* not a verity file */
diff --git a/fs/verity/read_metadata.c b/fs/verity/read_metadata.c
index 2aefc5565152a..1ef755130407b 100644
--- a/fs/verity/read_metadata.c
+++ b/fs/verity/read_metadata.c
@@ -156,13 +156,19 @@ int fsverity_ioctl_read_metadata(struct file *filp, const void __user *uarg)
 	int length;
 	void __user *buf;
 
+	/*
+	 * This ioctl returns file contents block hashes, so it should require
+	 * read permission.  Disallow it on ioctl-only (i.e., nonstandard access
+	 * mode 3) fds, which can in some cases be acquired without passing all
+	 * LSM read-permission checks.  Also disallow write-only fds, which can
+	 * refer only to non-verity files which would fail with ENODATA anyway.
+	 */
+	if (!(filp->f_mode & FMODE_READ))
+		return -EBADF;
+
 	vi = fsverity_get_info(inode);
 	if (!vi)
 		return -ENODATA; /* not a verity file */
-	/*
-	 * Note that we don't have to explicitly check that the file is open for
-	 * reading, since verity files can only be opened for reading.
-	 */
 
 	if (copy_from_user(&arg, uarg, sizeof(arg)))
 		return -EFAULT;

base-commit: c75b0cf0982c00cddfd88d1acf3872f79b40980c
-- 
2.56.0

Re: [PATCH 6.1] fsverity: Explicitly require FMODE_READ to retrieve hashes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] fsverity: missing FMODE_READ check in fsverity_ioctl_enable()
--

commit ce00f17646315fc0b3de9e3b97325887e3d4a262
Author: Eric Biggers <ebiggers@kernel.org>

fsverity: Explicitly require FMODE_READ to retrieve hashes

This commit backports upstream commit 1acb4fd2d011c4bd6cc961095ae17361c71ff61a to require FMODE_READ in fsverity_ioctl_measure() and fsverity_ioctl_read_metadata(), and documents that FS_IOC_ENABLE_VERITY, FS_IOC_MEASURE_VERITY, and FS_IOC_READ_VERITY_METADATA fail with EBADF when the file descriptor is not open for reading.

Link: https://patch.msgid.link/20261022211522.1489943-1-ebiggers@kernel.org

> diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
> index cb8e7573882a1..3c7ddd6790baa 100644
> --- a/Documentation/filesystems/fsverity.rst
> +++ b/Documentation/filesystems/fsverity.rst
> @@ -157,6 +157,7 @@ fatal signal), no changes are made to the file.
>  FS_IOC_ENABLE_VERITY can fail with the following errors:
>  
>  - ``EACCES``: the process does not have write access to the file
> +- ``EBADF``: the file descriptor is not open for reading
>  - ``EBADMSG``: the signature is malformed
>  - ``EBUSY``: this ioctl is already running on the file
>  - ``EEXIST``: the file already has verity enabled

[Severity: Medium]
Does fsverity_ioctl_enable() also need an explicit FMODE_READ check in this
branch?

In mainline, fsverity_ioctl_enable() gained a check for FMODE_READ when
Merkle tree construction was converted to use __kernel_read().  That
change is not in this tree, where fsverity_ioctl_enable() only checks
file_permission(filp, MAY_WRITE) and deny_write_access(filp), and
build_merkle_tree_level() reads directly from the page cache via
read_file_data_page().

As a result, FS_IOC_ENABLE_VERITY never returns -EBADF when the file
descriptor is not open for reading (returning -ETXTBSY on O_WRONLY fds and
succeeding on mode 3 ioctl-only fds).  A process confined by Landlock or
AppArmor can still open a DAC-writable file with access mode 3 without
passing security_file_open() read/write checks and invoke
FS_IOC_ENABLE_VERITY to hash the file contents and permanently enable
fs-verity.

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

Re: [PATCH 6.1] fsverity: Explicitly require FMODE_READ to retrieve hashes

[Eric Biggers]

On Sat, Nov 07, 2026 at 07:21:27PM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Does fsverity_ioctl_enable() also need an explicit FMODE_READ check in this
> branch?
> 
> In mainline, fsverity_ioctl_enable() gained a check for FMODE_READ when
> Merkle tree construction was converted to use __kernel_read().  That
> change is not in this tree, where fsverity_ioctl_enable() only checks
> file_permission(filp, MAY_WRITE) and deny_write_access(filp), and
> build_merkle_tree_level() reads directly from the page cache via
> read_file_data_page().

I'll consider backporting 04839139213c ("fsverity: reject
FS_IOC_ENABLE_VERITY on mode 3 fds") separately.  It is independent of
this patch.

- Eric