FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

[Sasha Levin]

The patch below does not apply to the 6.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.18.y
git checkout FETCH_HEAD
git cherry-pick -x 1acb4fd2d011c4bd6cc961095ae17361c71ff61a
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '20261107051544-failed-6.18-1acb4fd2d011@kernel.org' --subject-prefix 'PATCH 6.18.y' 'HEAD^..'

Thanks,
Sasha

------------------ original commit in Linus's tree ------------------

From 1acb4fd2d011c4bd6cc961095ae17361c71ff61a Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers@kernel.org>
Date: Thu, 22 Oct 2026 21:15:22 +0000
Subject: [PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes

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 22b49b295d1f9..e5d38439bf585 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -170,6 +170,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 builtin signature is malformed
 - ``EBUSY``: this ioctl is already running on the file
 - ``EEXIST``: the file already has verity enabled
@@ -232,6 +233,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
@@ -310,6 +312,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 68dfccb697720..0c75616dca011 100644
--- a/fs/verity/measure.c
+++ b/fs/verity/measure.c
@@ -31,6 +31,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 b4c0892430cde..6694149f7b467 100644
--- a/fs/verity/read_metadata.c
+++ b/fs/verity/read_metadata.c
@@ -166,13 +166,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;
-- 
2.53.0

Re: FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

[Eric Biggers]

On Sat, Nov 07, 2026 at 05:15:44AM -0500, Sasha Levin wrote:
> The patch below does not apply to the 6.18-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> To reproduce the conflict and resubmit, you may use the following commands:
> 
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.18.y
> git checkout FETCH_HEAD
> git cherry-pick -x 1acb4fd2d011c4bd6cc961095ae17361c71ff61a
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '20261107051544-failed-6.18-1acb4fd2d011@kernel.org' --subject-prefix 'PATCH 6.18.y' 'HEAD^..'
> 
> Thanks,
> Sasha
> 

Actually a clean cherry-pick, and failed to Cc the fsverity mailing
list.

- Eric

Re: FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

[Sasha Levin]

On Sat, Nov 07, 2026 at 11:04:47AM -0800, Eric Biggers wrote:
>On Sat, Nov 07, 2026 at 05:15:44AM -0500, Sasha Levin wrote:
>> The patch below does not apply to the 6.18-stable tree.
>> If someone wants it applied there, or to any other stable or longterm
>> tree, then please email the backport, including the original git commit
>> id to <stable@vger.kernel.org>.
>>
>> To reproduce the conflict and resubmit, you may use the following commands:
>>
>> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.18.y
>> git checkout FETCH_HEAD
>> git cherry-pick -x 1acb4fd2d011c4bd6cc961095ae17361c71ff61a
>> # <resolve conflicts, build, test, etc.>
>> git commit -s
>> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '20261107051544-failed-6.18-1acb4fd2d011@kernel.org' --subject-prefix 'PATCH 6.18.y' 'HEAD^..'
>>
>> Thanks,
>> Sasha
>>
>
>Actually a clean cherry-pick, and failed to Cc the fsverity mailing

Ah interesting, looks like my scripts were a bit confused about the two Fixes:
tags. I'll look into that.

>list.

So I feel we have had the Cc discussion quite a few times now. We really have
to limit how many mails end up going out: this last release had thousands of
mails which took hours to send. Adding more lists will simply kill the mail
server and will harm everyone.

We have solutions for that!

See Konstantin's writeup[1] about lei with filters like dfn: or dfhh:.

We're not going to change this on our end: the kernel.org folks will complain,
mails will take days, and people will be grumpy at us.

If this is really not something you can work around, then we can figure out a
filter to exclude your patches so that all of us can continue being happy going
forward.


[1] https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started

-- 
Thanks,
Sasha

Re: FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

[Eric Biggers]

On Sat, Nov 07, 2026 at 04:14:47PM -0500, Sasha Levin wrote:
> So I feel we have had the Cc discussion quite a few times now. We really have
> to limit how many mails end up going out: this last release had thousands of
> mails which took hours to send. Adding more lists will simply kill the mail
> server and will harm everyone.
> 
> We have solutions for that!
> 
> See Konstantin's writeup[1] about lei with filters like dfn: or dfhh:.
> 
> We're not going to change this on our end: the kernel.org folks will complain,
> mails will take days, and people will be grumpy at us.
> 
> If this is really not something you can work around, then we can figure out a
> filter to exclude your patches so that all of us can continue being happy going
> forward.
> 
> 
> [1] https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started

I've already started to use lei to work around this issue with the
stable process, but everyone else will as well, which seems unlikely to
work well.  This also effectively means that subsystem mailing lists are
deprecated, as some of the development process is happening off-list.

- Eric

Re: FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

[Greg KH]

On Sat, Nov 07, 2026 at 01:26:33PM -0800, Eric Biggers wrote:
> On Sat, Nov 07, 2026 at 04:14:47PM -0500, Sasha Levin wrote:
> > So I feel we have had the Cc discussion quite a few times now. We really have
> > to limit how many mails end up going out: this last release had thousands of
> > mails which took hours to send. Adding more lists will simply kill the mail
> > server and will harm everyone.
> > 
> > We have solutions for that!
> > 
> > See Konstantin's writeup[1] about lei with filters like dfn: or dfhh:.
> > 
> > We're not going to change this on our end: the kernel.org folks will complain,
> > mails will take days, and people will be grumpy at us.
> > 
> > If this is really not something you can work around, then we can figure out a
> > filter to exclude your patches so that all of us can continue being happy going
> > forward.
> > 
> > 
> > [1] https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started
> 
> I've already started to use lei to work around this issue with the
> stable process, but everyone else will as well, which seems unlikely to
> work well.  This also effectively means that subsystem mailing lists are
> deprecated, as some of the development process is happening off-list.

No, all of the people involved in the patch that failed is copied.  It's
very odd that people who are not on the s-o-b chain would want to get
notice that a patch did not apply.

thanks,

greg k-h

Re: FAILED: patch "[PATCH] fsverity: Explicitly require FMODE_READ to retrieve hashes" failed to apply to 6.18-stable tree

[Eric Biggers]

On Sun, Nov 08, 2026 at 08:47:35AM -0500, Greg KH wrote:
> On Sat, Nov 07, 2026 at 01:26:33PM -0800, Eric Biggers wrote:
> > On Sat, Nov 07, 2026 at 04:14:47PM -0500, Sasha Levin wrote:
> > > So I feel we have had the Cc discussion quite a few times now. We really have
> > > to limit how many mails end up going out: this last release had thousands of
> > > mails which took hours to send. Adding more lists will simply kill the mail
> > > server and will harm everyone.
> > > 
> > > We have solutions for that!
> > > 
> > > See Konstantin's writeup[1] about lei with filters like dfn: or dfhh:.
> > > 
> > > We're not going to change this on our end: the kernel.org folks will complain,
> > > mails will take days, and people will be grumpy at us.
> > > 
> > > If this is really not something you can work around, then we can figure out a
> > > filter to exclude your patches so that all of us can continue being happy going
> > > forward.
> > > 
> > > 
> > > [1] https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started
> > 
> > I've already started to use lei to work around this issue with the
> > stable process, but everyone else will as well, which seems unlikely to
> > work well.  This also effectively means that subsystem mailing lists are
> > deprecated, as some of the development process is happening off-list.
> 
> No, all of the people involved in the patch that failed is copied.  It's
> very odd that people who are not on the s-o-b chain would want to get
> notice that a patch did not apply.

No, it's not odd at all.  Same reason we have subsystem mailing lists at
all: Linux kernel development is a collaborative process and lots of
people are involved, not just the people in MAINTAINERS (who also change
over time, may be unresponsive, go on vacation, etc.).  Just because
someone doesn't have a tag on a commit doesn't mean they weren't
involved or don't need to know about it.  We need to catch regressions
and missed backports, and failing to Cc the subsystem list is a very bad
start as then some of the people best able to help are left in the dark
unless they happen to take the time to use the lei workaround.

- Eric