linux-ext4 - Directory unremovable on ext4 no

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

Message-ID: <CA+EzBbCXWZZiP2jBnUQSn8LeTkav0tEJ-ra60GiVNxZK8zhLmg@mail.gmail.com>
Date:   Mon, 9 Apr 2018 19:08:13 -0500
From:   Jayashree Mohan <jayashree2912@...il.com>
To:     linux-ext4@...r.kernel.org, fstests <fstests@...r.kernel.org>
Cc:     Vijaychidambaram Velayudhan Pillai <vijay@...utexas.edu>
Subject: Directory unremovable on ext4 no_journal mode

Hi,

We stumbled upon what seems to be a bug that makes a “directory
unremovable”,  on ext4 when mounted with no_journal option.

A sequence of operations described below led to the following state :
“A directory that was renamed, was persisted in both parent and target
directories, with the same inode number. This also means the rename
was non-atomic on storage. In addition, the renamed directory becomes
unremovable on the target with FS-error logged in dmesg.”

Here are more details of the workload and the corresponding failure.

Workload :

mkdir /mnt/test/X and /mnt/test/Y
mkdir X/Z
sync()
rename X/Z   Y/Z
fsync Y
—-Crash now—-
Remount
ls X and Y (You will see Z is present in both directories X and Y, and
has same inode)
rmdir test_dir/X/Z  (This succeeds)
rmdir test_dir/Y/Z  (This fails with a FS error logged in dmesg)

Results:

rmdir: failed to remove '/mnt/test/Y/Z': Structure needs cleaning

The corresponding dmesg log has the following error message :
[66799.504124] EXT4-fs error (device cow_ram_snapshot1_0):
ext4_lookup:1576: inode #12: comm rmdir: deleted inode referenced: 14
[66799.504131] EXT4-fs (cow_ram_snapshot1_0): Remounting filesystem read-only

The sequence of operations listed above is making dir Z unremovable
from dir Y, which seems like unexpected behavior. Could you provide
more details on the reason for such behavior? We understand we run
this on no_journal mode of ext4, but would like you to verify if this
behavior is acceptable.

Do let us know if we are missing any detail here.

Thanks,
Jayashree Mohan