linux-kernel - [PATCH 0/3] fs: Support btrfs cloned images and overlayfs

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-next>] [day] [month] [year] [list]

Message-Id: <20260114-tonyk-get_disk_uuid-v1-0-e6a319e25d57@igalia.com>
Date: Wed, 14 Jan 2026 01:31:40 -0300
From: André Almeida <andrealmeid@...lia.com>
To: 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>, 
 Amir Goldstein <amir73il@...il.com>, 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>
Cc: linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
 linux-btrfs@...r.kernel.org, linux-unionfs@...r.kernel.org, 
 kernel-dev@...lia.com, 
 André Almeida <andrealmeid@...lia.com>
Subject: [PATCH 0/3] fs: Support btrfs cloned images and overlayfs

Hi everyone,

As I reported some time ago, btrfs cloned images support and overlayfs
"index" check don't get along together[1]. Every time the same image
cloned is mounted, btrfs assigns a new random UUID for it to avoid
clashing with the exist UUID. This UUID is then used by overlayfs origin
check, to avoid reusing the same directory for a different filesystem.
Remounting the same filesystem in the same directory is supported, but
the different random UUIDs will make the check fail.

In an attempt to solve this, I reused export_operations::get_uuid() for
this purpose, to get the "real" UUID of a image, regardless of the
random UUID being exposed to userspace. overlayfs then use this UUID
internally for the origin check, and the remounting finally works.

I understand that not everyone is happy about repurposing get_uuid() for
that, but I'm totally open for going in another direction for solving
this problem not only for the combination of btrfs+overlayfs, but for
any filesytem that have similar issues with random UUIDs.

Using `btrfstune -m` or similar to change the cloned image UUID doesn't
work for the SteamOS use case, as we, well... use the UUIDs to identify
unmounted images and check if they are the same.

This series is based on top of another series[2], that should be available
at vfs-7.0.misc by now.

Thanks!

[1] https://lore.kernel.org/lkml/20251014015707.129013-1-andrealmeid@igalia.com/
[2] https://lore.kernel.org/lkml/20260112-tonyk-fs_uuid-v1-0-acc1889de772@igalia.com/

---
André Almeida (3):
      exportfs: Rename get_uuid() to get_disk_uuid()
      btrfs: Implement get_disk_uuid()
      ovl: Use real disk UUID for origin file handles

 fs/btrfs/export.c        | 20 ++++++++++++++++++++
 fs/nfsd/blocklayout.c    |  2 +-
 fs/nfsd/nfs4layouts.c    |  2 +-
 fs/overlayfs/copy_up.c   | 22 ++++++++++++++++++++--
 fs/xfs/xfs_export.c      |  2 +-
 fs/xfs/xfs_pnfs.c        |  2 +-
 fs/xfs/xfs_pnfs.h        |  2 +-
 include/linux/exportfs.h |  8 +++++---
 8 files changed, 50 insertions(+), 10 deletions(-)
---
base-commit: 336cebc7376296b2c25cf8433ff62b71fe929b0d
change-id: 20260114-tonyk-get_disk_uuid-f0d475ed170c

Best regards,
-- 
André Almeida <andrealmeid@...lia.com>