linux-kernel - Re: [REGRESSION] erofs: new file-backed stacking limit breaks container overlay use case in 6.12.63

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: <eef84292-a81f-4af0-83b4-c124932b973a@linux.alibaba.com>
Date: Fri, 26 Dec 2025 22:22:01 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Alekséi Naidénov <an@...italtide.io>,
 stable@...r.kernel.org
Cc: linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
 xiang@...nel.org, Amir Goldstein <amir73il@...il.com>,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [REGRESSION] erofs: new file-backed stacking limit breaks
 container overlay use case in 6.12.63




Hi Alekséi,

On 2025/12/26 20:17, Alekséi Naidénov wrote:
> 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.

The following issue just tracks this:
https://github.com/coreos/fedora-coreos-tracker/issues/2087

I don't think more information is needed, but I really think the EROFS
commit is needed to avoid kernel stack overflow due to nested fses.

> 
> 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.
Yes, but there are two overlayfs + one file-backed EROFS already, and
it exceeds FILESYSTEM_MAX_STACK_DEPTH.

That is overlayfs refuses to mount the nested fses.

Thanks,
Gao Xiang