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>] [day] [month] [year] [list]
Message-ID: <20251226123453.5914-1-an@digitaltide.io>
Date: Fri, 26 Dec 2025 13:34:37 +0100
From: Alekséi Naidénov <an@...italtide.io>
To: stable@...r.kernel.org
Cc: linux-erofs@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org,
	xiang@...nel.org
Subject: [REGRESSION] erofs: new file-backed stacking limit breaks container overlay use case in 6.12.63

Hello,

I am reporting a regression in the 6.12 stable series related to EROFS file-backed mounts.

After updating from Linux 6.12.62 to 6.12.63, a previously working setup using OSTree-backed 
composefs mounts as Podman rootfs no longer works.

The regression appears to be caused by the following commit:

    34447aeedbaea8f9aad3da5b07030a1c0e124639 ("erofs: limit the level of fs stacking for file-backed mounts")
    (backport of upstream commit d53cd891f0e4311889349fff3a784dc552f814b9)

## Setup description

We use OSTree to materialize filesystem trees, which are mounted via composefs (EROFS + overlayfs) 
as a read-only filesystem. This mounted composefs tree is then used as a Podman rootfs, with 
Podman mounting a writable overlayfs on top for each container.

This setup worked correctly on Linux 6.12.62 and earlier.

In short, the stacking looks like:

  EROFS (file-backed)
    -> composefs (EROFS + overlayfs with ostree repo as datadir, read-only)
        -> Podman rootfs overlays (RW upperdir)

There is no recursive or self-stacking of EROFS.

## Working case (6.12.62)

The composefs mount exists and Podman can successfully start a container using it as rootfs.

Example composefs mount:

    ❯ mount | grep a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c
    a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c on /home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c type overlay (ro,noatime,lowerdir+=/proc/self/fd/10,datadir+=/proc/self/fd/7,redirect_dir=on,metacopy=on)

(lowedir is a handle for the erofs file-backed mount, datadir is a handle for the ostree 
repository objects directory)

Running Podman:

    ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l
    root@...1e785bba3:/# uname -a
    Linux d691e785bba3 6.12.62 #1-NixOS SMP PREEMPT_DYNAMIC Fri Dec 12 17:37:22 UTC 2025 x86_64 GNU/Linux
    root@...1e785bba3:/# 

(succeed)

## Failing case (6.12.63)

After upgrading to 6.12.63, the same command fails when Podman tries to create the writable overlay 
on top of the composefs mount.

Error:

    ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l    
    Error: rootfs-overlay: creating overlay failed "/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c" from native overlay: mount overlay:/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/merge, flags: 0x4, data: lowerdir=/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c,upperdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/upper,workdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/work,userxattr: invalid argument
    ❯ uname -a
    Linux ci-node-09 6.12.63 #1-NixOS SMP PREEMPT_DYNAMIC Thu Dec 18 12:55:23 UTC 2025 x86_64 GNU/Linux

## Expected behavior

Using a composefs (EROFS + overlayfs) read-only mount as the lowerdir for a container rootfs overlay 
should continue to work as it did in 6.12.62.

## Actual behavior

Overlayfs mounting fails with EINVAL when stacking on top of the composefs mount backed by EROFS.

## Notes

The setup does not involve recursive EROFS mounting or unbounded stacking depth. It appears the new stacking 
limit rejects this valid and previously supported container use case.

Please let me know if further details or testing would be helpful.

Thank you,
-- 
 Alekséi Nadénov



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ