linux-ext4 - Re: [bug report] tune2fs: filesystem inconsistency occurs by concurrent write

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230626021758.GF8954@mit.edu>
Date:   Sun, 25 Jun 2023 22:17:58 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     zhanchengbin <zhanchengbin1@...wei.com>
Cc:     linux-ext4@...r.kernel.org, linfeilong <linfeilong@...wei.com>,
        louhongxiang@...wei.com, liuzhiqiang26@...wei.com
Subject: Re: [bug report] tune2fs: filesystem inconsistency occurs by
 concurrent write

On Mon, Jun 26, 2023 at 12:00:08AM +0800, zhanchengbin wrote:
> Tune2fs does not recognize writes to the manipulated filesystem in another
> namespace, there will be two simultaneous write operations on a
> block, resulting in filesystem inconsistencies.

What you are reporting has nothing to do with namespaces, since
"tune2fs -e remount-ro /dev/sdb" is something which is allowed
regardless of whether the file system is mounted.  What reproduction
is effectively doing is trying to set up a race between when tune2fs
writes a byte to update to update the errors behavior, and when the
actual unmount of the file system happens (e.g., when the last
namespace unmounts the file system).  At that point, the kernel is
going to be updating the superblock as part of the unmount, and then
it calculates the superblock, and then it writes out the superblock.

If the tune2fs races with the unmount, it's possible for the tune2fs
update of the error beavhiour bit, and the update of the superblock
checksum, to race with the kernel's final update of the superblock,
includinig its attempt to update the checksum.

There are some workarounds to this, but ultimately, we need to replace
the ad-hoc modification of the block device by tune2fs with some
ioctls which specifically update superblock when the file system
mounted.

As far as whether or not tune2fs can detect if the file system is
mounted, what we can do is check to see if the block device is busy.
If it is mounted in some other namespace, we won't be able to see it
mounted in /proc/self/mounts, but we can see that it's not possible to
open the block device with O_EXCL.

Compare:

root@...-xfstests:~# /vtmp/tst_ismounted /dev/vdc
Device /dev/vdc reports flags 31
        /dev/vdc is apparently in use.
        /dev/vdc is mounted.
        /dev/vdc is mounted on /vdc.

and then "unshare -m" in another terminal, followed by umount /dev/vdc
in the first terminal:

root@...-xfstests:~# /vtmp/tst_ismounted /dev/vdc
Device /dev/vdc reports flags 10
        /dev/vdc is apparently in use.

... and then after we exit the last mount namespace which was keeping
/dev/vdc mounted:

root@...-xfstests:~# [ 2409.811328] EXT4-fs (vdc): unmounting filesystem bdc026fd-85a8-4ccf-94f8-961487000293.
root@...-xfstests:~# /vtmp/tst_ismounted /dev/vdc
Device /dev/vdc reports flags 00

Cheers,

						- Ted