Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in clone_mnt

From: Christian Brauner

Date: Sat Feb 14 2026 - 10:59:31 EST


On Sat, Feb 14, 2026 at 02:01:26AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: c22e26bd0906 Merge tag 'landlock-7.0-rc1' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12c6a6e6580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6428d17febdfb14e
> dashboard link: https://syzkaller.appspot.com/bug?extid=a89f9434fb5a001ccd58
> compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b33c549157ca/disk-c22e26bd.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/34c7ded19553/vmlinux-c22e26bd.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/66faec2158ed/bzImage-c22e26bd.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+a89f9434fb5a001ccd58@xxxxxxxxxxxxxxxxxxxxxxxxx

Right, this should be fixed by the appended patch. If someone had the
bright idea to make the real rootfs a shared or dependent mount and it
is later copied the copy will become a peer of the old real rootfs mount
or a dependent mount of it. If locking the new rootfs mount for mounting
fails or the subsequent do_loopback() fails we rely on the copy of the
real root mount to be cleaned up by path_put(). The problem is that this
doesn't deal with mount propagation and will leave the mounts linked in
the propagation lists. Fix this by actually unmounting the copied tree.