linux-kernel - Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOQ4uxhHFvYNAgES9wpM_C-7GvfwXC2xet1ensfeQOyPJRAuNQ@mail.gmail.com>
Date: Wed, 28 Jan 2026 12:49:45 +0100
From: Amir Goldstein <amir73il@...il.com>
To: André Almeida <andrealmeid@...lia.com>
Cc: Christoph Hellwig <hch@....de>, Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>, 
	NeilBrown <neil@...wn.name>, Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>, 
	Tom Talpey <tom@...pey.com>, Carlos Maiolino <cem@...nel.org>, Chris Mason <clm@...com>, 
	David Sterba <dsterba@...e.com>, Miklos Szeredi <miklos@...redi.hu>, 
	Christian Brauner <brauner@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, 
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	Qu Wenruo <wqu@...e.com>, linux-btrfs@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	kernel-dev@...lia.com, vivek@...labora.com, 
	Ludovico de Nittis <ludovico.denittis@...labora.com>
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@...il.com> wrote:
>
> On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@...lia.com> wrote:
> >
> > Em 23/01/2026 10:24, André Almeida escreveu:
> > >
> > > Em 22/01/2026 17:07, Amir Goldstein escreveu:
> > >> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@...il.com>
> > >> wrote:
> > >>>
> > >>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
> > >>> <andrealmeid@...lia.com> wrote:
> > >>>>
> > >> ...
> > >>>> Actually they are not in the same fs, upper and lower are coming from
> > >>>> different fs', so when trying to mount I get the fallback to
> > >>>> `uuid=null`. A quick hack circumventing this check makes the mount
> > >>>> work.
> > >>>>
> > >>>> If you think this is the best way to solve this issue (rather than
> > >>>> following the VFS helper path for instance),
> > >>>
> > >>> That's up to you if you want to solve the "all lower layers on same fs"
> > >>> or want to also allow lower layers on different fs.
> > >>> The former could be solved by relaxing the ovl rules.
> > >>>
> > >>>> please let me know how can
> > >>>> I safely lift this restriction, like maybe adding a new flag for this?
> > >>>
> > >>> I think the attached patch should work for you and should not
> > >>> break anything.
> > >>>
> > >>> It's only sanity tested and will need to write tests to verify it.
> > >>>
> > >>
> > >> Andre,
> > >>
> > >> I tested the patch and it looks good on my side.
> > >> If you want me to queue this patch for 7.0,
> > >> please let me know if it addresses your use case.
> > >>
> > >
> > > Hi Amir,
> > >
> > > I'm still testing it to make sure it works my case, I will return to you
> > > ASAP. Thanks for the help!
> > >
> >
> > So, your patch wasn't initially working in my setup here, and after some
> > debugging it turns out that on ovl_verify_fh() *fh would have a NULL
> > UUID, but *ofh would have a valid UUID, so the compare would then fail.
> >
> > Adding this line at ovl_get_fh() fixed the issue for me and made the
> > patch work as I was expecting:
> >
> > +       if (!ovl_origin_uuid(ofs))
> > +               fh->fb.uuid = uuid_null;
> > +
> >          return fh;
> >
> > Please let me know if that makes sense to you.
>
> It does not make sense to me.
> I think you may be using the uuid=off feature in the wrong way.
> What you did was to change the stored UUID, but this NOT the
> purpose of uuid=off.
>
> The purpose of uuid=off is NOT to allow mounting an overlayfs
> that was previously using a different lower UUID.
> The purpose is to mount overlayfs the from the FIRST time with
> uuid=off so that ovl_verify_origin_fh() gets null uuid from the
> first call that sets the ORIGIN xattr.
>
> IOW, if user want to be able to change underlying later UUID
> user needs to declare from the first overlayfs mount that this
> is expected to happen, otherwise, overlayfs will assume that
> an unintentional wrong configuration was used.
>
> I updated the documentation to try to explain this better:
>
> Is my understanding of the problems you had correct?
> Is my solution understood and applicable to your use case?
>

Hi Andre,

Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
I would need your feedback soon.

FWIW, I think that this change of restrictions for uuid=null could be backported
to stable kernels, but I am not going to mark it for auto select, because
I'd rather see if anyone shouts with upstream kernel first when (if) we make
this change and manually backport later per demand.

Thanks,
Amir.