Comment 17 for bug 2016398

Revision history for this message
Aleksandr Mikhalitsyn (mihalicyn) wrote (last edit ):

I've spent some time to look at this issue closely.

First of all I want to confirm that the issue is present in the original patch:
("UBUNTU: SAUCE: overlayfs: fix incorrect mnt_id of files opened from map_files")
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/fs/overlayfs/file.c?h=master-next&id=28eab192cf0e37156fc41b36f06790d5ca984834

But, this leak is not clearly visible on Ubuntu Focal (5.4) kernel, while being clearly visible (as "umount: /tmp/ovlissue/mountpointtmp/firstunion/tmp/ovlissue/mountpointtmp/secondunion: target is busy." error) on Lunar kernel. Reason for this difference in behavior is that this commit was lost in Lunar kernel:
("UBUNTU: SAUCE: overlayfs: allow with shiftfs as underlay")
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/fs/overlayfs/file.c?h=master-next&id=730264093da28294476d5c41b055a271facdd998

While this commit is not affecting on the struct file refcounter leak, it affects on *which* struct vfsmnt will leak (because struct file leak tends to struct path leak, struct path leak results into struct vfsmnt leak).

In focal kernel it will be *private* (created with clone_private_mount() helper) mount leak, but in the Lunar kernel it will be userspace visible mount leak. That's why umount fails with EBUSY.

Secondly, refcounter leak happens only when one overlayfs stacked on top of another overlayfs and if mmap(2) was called with this "stacked" overlayfs configuration.