Amir, this v2 addresses your comments on v1.

I have split the v2 into 3 commits:

* 1/3 is the actual fix, where only nfs_export is disabled. It caches the
  first lower idmap in each ovl_sb to avoid rescanning all lower layers
  for every repeated superblock.

* 2/3 checks that the targeted layout indeed forces nfs_export=off
  and that decodable handle requests fail with EOPNOTSUPP.

* 3/3 keeps index=on,nfs_export=off and verifies copy up still preserves
  hardlinks and mapped ownership.

I have made this split so that you may decide to include 1 or 2 selftests.

I have reproduced the bug through nfsd with the help of AI. The reproducer
exports an overlay containing a mode 0600 uid 0 file, obtains a real NFSv3
handle, drops a client to uid/gid 1000, then replays the saved handle after
unmount, reclaim, and remount. On an unpatched kernel, the replay
initializes the overlay inode with uid 1000 and the client can read and
overwrite the file. TBH, I don't know whether this layout may actually
happen in production, but it looks like a weird feature.

Changes since v1:
- disable only nfs_export (keep index enabled),
- cache the first lower idmap in struct ovl_sb instead of rescanning,
- add separate selftests for handle rejection and index copy up.

v1: https://lore.kernel.org/all/20260911194201.1334086-2-Jeremy.Jean@oss.cyber.gouv.fr/ 

Jérémy Jean (3):
  ovl: disable nfs_export for same-sb lower layers with different idmaps
  selftests: overlayfs: reject handles for mixed lower idmaps
  selftests: overlayfs: keep index copy up with mixed lower idmaps

 fs/overlayfs/ovl_entry.h                      |   2 +
 fs/overlayfs/super.c                          |  28 ++-
 .../filesystems/overlayfs/idmapped_mounts.c   | 201 +++++++++++++++++-
 3 files changed, 226 insertions(+), 5 deletions(-)

-- 
2.47.3

On Sun, Sep 20, 2026 at 10:33 PM Jérémy Jean
<Jeremy.Jean@oss.cyber.gouv.fr> wrote:
>
> Amir, this v2 addresses your comments on v1.
>
> I have split the v2 into 3 commits:
>
> * 1/3 is the actual fix, where only nfs_export is disabled. It caches the
>   first lower idmap in each ovl_sb to avoid rescanning all lower layers
>   for every repeated superblock.
>
> * 2/3 checks that the targeted layout indeed forces nfs_export=off
>   and that decodable handle requests fail with EOPNOTSUPP.
>
> * 3/3 keeps index=on,nfs_export=off and verifies copy up still preserves
>   hardlinks and mapped ownership.
>
> I have made this split so that you may decide to include 1 or 2 selftests.
>
> I have reproduced the bug through nfsd with the help of AI. The reproducer
> exports an overlay containing a mode 0600 uid 0 file, obtains a real NFSv3
> handle, drops a client to uid/gid 1000, then replays the saved handle after
> unmount, reclaim, and remount. On an unpatched kernel, the replay
> initializes the overlay inode with uid 1000 and the client can read and
> overwrite the file. TBH, I don't know whether this layout may actually
> happen in production, but it looks like a weird feature.

I do not know either.

I would like to get feedback from Christian on that, because if this
setup is not expected I'd rather fail the mount.

Thanks,
Amir.

>
> Changes since v1:
> - disable only nfs_export (keep index enabled),
> - cache the first lower idmap in struct ovl_sb instead of rescanning,
> - add separate selftests for handle rejection and index copy up.
>
> v1: https://lore.kernel.org/all/20260911194201.1334086-2-Jeremy.Jean@oss.cyber.gouv.fr/
>
> Jérémy Jean (3):
>   ovl: disable nfs_export for same-sb lower layers with different idmaps
>   selftests: overlayfs: reject handles for mixed lower idmaps
>   selftests: overlayfs: keep index copy up with mixed lower idmaps
>
>  fs/overlayfs/ovl_entry.h                      |   2 +
>  fs/overlayfs/super.c                          |  28 ++-
>  .../filesystems/overlayfs/idmapped_mounts.c   | 201 +++++++++++++++++-
>  3 files changed, 226 insertions(+), 5 deletions(-)
>
> --
> 2.47.3

On 2026-09-21 10:03, Amir Goldstein wrote:
> On Sun, Sep 20, 2026 at 10:33 PM Jérémy Jean
> <Jeremy.Jean@oss.cyber.gouv.fr> wrote:
>> TBH, I don't know whether this layout may actually
>> happen in production, but it looks like a weird feature.
> 
> I do not know either.
> 
> I would like to get feedback from Christian on that, because if this
> setup is not expected I'd rather fail the mount.

Hello Amir,

Thanks for the quick review of this series.
I will wait for Christian to answer before fixing your small remarks
in a v3.

Regards,
Jérémy