[PATCH] ovl: reject verity= together with userxattr

[PATCH] ovl: reject verity= together with userxattr

[Tao Cui]

From: Tao Cui <cuitao@kylinos.cn>

userxattr forces metacopy off, and copy-up only computes and stores
the verity digest for metacopy inodes.  With "userxattr,verity=on"
(or verity=require) the mount succeeds, verity is advertised in
mountinfo, but no digest is ever generated and no lowerdata is ever
verified - the option silently does nothing:

  $ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
  (mount succeeds; after copy-up the upper inode carries only the
   origin xattr, no metacopy xattr, no digest)

Follow the existing pattern for redirect_dir/metacopy and reject the
explicit combination at parse time:

  $ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
  mount: /mnt: wrong fs type, bad option, bad superblock...
  overlayfs: conflicting options: userxattr,verity=on

This does not affect per-file fs-verity on the lower layers used
together with userxattr (e.g. fstests overlay/089): it only concerns
the verity= mount option, whose copy-up digest semantics cannot be
honored when userxattr forces metacopy off.

Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
 fs/overlayfs/params.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
index c93fcaa45d4a..29dfc16fecc9 100644
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -997,6 +997,11 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx,
 			pr_err("conflicting options: userxattr,metacopy=on\n");
 			return -EINVAL;
 		}
+		if (config->verity_mode) {
+			pr_err("conflicting options: userxattr,verity=%s\n",
+			       ovl_verity_mode(config));
+			return -EINVAL;
+		}
 		/*
 		 * Silently disable default setting of redirect and metacopy.
 		 * This shall be the default in the future as well: these
-- 
2.43.0

Re: [PATCH] ovl: reject verity= together with userxattr

[Amir Goldstein]

On Thu, Sep 3, 2026 at 8:45 AM Tao Cui <cui.tao@linux.dev> wrote:
>
> From: Tao Cui <cuitao@kylinos.cn>
>
> userxattr forces metacopy off, and copy-up only computes and stores
> the verity digest for metacopy inodes.  With "userxattr,verity=on"
> (or verity=require) the mount succeeds, verity is advertised in
> mountinfo, but no digest is ever generated and no lowerdata is ever
> verified - the option silently does nothing:
>
>   $ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
>   (mount succeeds; after copy-up the upper inode carries only the
>    origin xattr, no metacopy xattr, no digest)

If metacopy is disabled, then the data of the upper file is in the upper file
there is not supposed to be a verity signature for the upper file data
verity signature is to attest the data of the lower file, so this report
is strange.

Moreover, even though metacopy=off does not create new meta copies,
it still respects existing metacopy xattr, which may very well also contain a
verity digest, so the statement "silently does nothing" is inaccurate.

I admit that user xattrs for verity digest is an odd combination, but it does
what it is supposed to do.

If you want to report a bug please explain how the security model gets
broken.

Thanks,
Amir.

Re: [PATCH] ovl: reject verity= together with userxattr

[Tao Cui]

Hi Amir,

在 2026/9/3 16:09, Amir Goldstein 写道:
> On Thu, Sep 3, 2026 at 8:45 AM Tao Cui <cui.tao@linux.dev> wrote:
>>
>> From: Tao Cui <cuitao@kylinos.cn>
>>
>> userxattr forces metacopy off, and copy-up only computes and stores
>> the verity digest for metacopy inodes.  With "userxattr,verity=on"
>> (or verity=require) the mount succeeds, verity is advertised in
>> mountinfo, but no digest is ever generated and no lowerdata is ever
>> verified - the option silently does nothing:
>>
>>   $ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
>>   (mount succeeds; after copy-up the upper inode carries only the
>>    origin xattr, no metacopy xattr, no digest)
> 
> If metacopy is disabled, then the data of the upper file is in the upper file
> there is not supposed to be a verity signature for the upper file data
> verity signature is to attest the data of the lower file, so this report
> is strange.
> 
> Moreover, even though metacopy=off does not create new meta copies,
> it still respects existing metacopy xattr, which may very well also contain a
> verity digest, so the statement "silently does nothing" is inaccurate.
> 
> I admit that user xattrs for verity digest is an odd combination, but it does
> what it is supposed to do.
> 
> If you want to report a bug please explain how the security model gets
> broken.
> 

Thanks for the explanation.  I hadn't considered that pre-existing
metacopy xattrs are still respected regardless of the mount option,
and that with metacopy off the copy-up data lives in the upper file
where there is nothing to attest.  The patch gets this wrong, please
drop it.

The fs-verity section in overlayfs.rst does spell this out; I read
it too narrowly.

Thanks,
Tao

> Thanks,
> Amir.