Created attachment 303841 [details]
A sample file system image

Hello.

The ntfs3 driver supports orphan inodes (files and directories deleted while in-use). Currently, such an inode has its reference removed from the $INDEX_ROOT/$INDEX_ALLOCATION attribute of its parent directory and, after the last handle is closed, the associated file record and file data are deallocated.

However, if the file system isn't unmounted cleanly (and the last handle wasn't closed before), the file record and clusters containing file data aren't deallocated. This leaves an allocated file record which is unreachable from the directory tree. Such residual orphan inodes waste the file system space.

Currently, these residual orphan inodes are never removed during the mount operation. Tools like ntfsfix can't handle them too.

When checking the file system in the Windows operating system (using the chkdsk tool), such an orphan file record is attached back to the file system. This "resurrects" data which was believed to be deleted (this is not a vulnerability, because the chkdsk tool preserves security descriptors of orphan file records; moreover, the chkdsk tool must be executed with privileges high enough for the raw access to the file system).

Some possible solutions are:
a. detect and cleanup such orphan inodes during the mount operation;
b. assign a temporary name to the orphan file instead of unlinking it from the parent directory (just like the ntfs-3g driver and the current Windows driver do), so the file remains reachable from the directory tree (and, thus, it remains deletable);
c. provide a userspace tool (fsck.ntfs) to detect and cleanup such orphan inodes.

I attached a sample file system image (gzipped).