]> git.ipfire.org Git - thirdparty/util-linux.git/commit
mount: Fix race in loop device reuse code
authorJan Kara <jack@suse.cz>
Thu, 20 Jan 2022 11:47:05 +0000 (12:47 +0100)
committerKarel Zak <kzak@redhat.com>
Tue, 25 Jan 2022 16:10:46 +0000 (17:10 +0100)
commit3e1fc3bbee99384cf43c2677cf77756a0ef002c0
treec6d0208d84f2fa7eefeb9a596f55928b3f871720
parent4eda4ec8af067702fcb23ec50a541411c5845594
mount: Fix race in loop device reuse code

Small timing changes in the kernel loop device handling broke the
following loop:

while :; do mount -o loop,ro isofs.iso isofs/; umount isofs/; done

which quickly reports:
mount: /mnt: can't read superblock on /dev/loop0.
umount: /mnt: not mounted.

And this loop is broken because of a subtle interaction with
systemd-udevd that also opens the loop device. The race seems to be in
mount(8) handling itself and the altered kernel timing makes it happen.
It look like:

bash                                systemd-udevd
  mount -o loop,ro isofs.iso isofs/
    /dev/loop0 is created and bound to isofs.iso, autoclear is set for
    loop0
                                    opens /dev/loop0
  umount isofs/
  loop0 still lives because systemd-udev still has device open
  mount -o loop,ro isofs.iso isofs/
    gets to mnt_context_setup_loopdev()
      loopcxt_find_overlap()
      sees loop0 is still valid and with proper parameters
      reuse = true;
                                    close /dev/loop0
                                      last fd closed => loop0 is
                                        cleaned up
      loopcxt_get_fd()
        opens loop0 but it is no longer the device we wanted!
    calls mount(2) which fails because we cannot read from the loop device

Fix the problem by rechecking that loop device is still attached after
opening the device. This makes sure the kernel will not autoclear the
device anymore.

Signed-off-by: Jan Kara <jack@suse.cz>
libmount/src/context_loopdev.c