Research: Possible bug while scanning unlinked dirents

[twiggler]

Introduction

1. Each node in Jffs2 has multiple versions.
2. Unlinking an inode is accomplished by setting the ino of the corresponding dirent nodes to zero.
3. When mounting, we do a linear scan if the nodes on the jffs filesystem.
4. We associate a list of version of a dirent with (parent inode, filename of the dirent).
5. When we encounter a dirent version with ino=0, we remove all versions of that dirent and consider the file lost & found.

Potential problem

I have been unable to find a guarantee that the nodes are ordered by version on disk, especially after a garbage collection cycle or wear leveling operations.

Consider the following layout on disk, where the latest version comes first

entry1          (dirent version=2 ino=0)     # Unlink
entry2          (dirent version=1 ino=3)     # Hardlink

Here, we first delete all versions of the dirent (there are none), but then erroneously recreate the mapping when we scan entry2.
The recreation is invalid because the version of the node (1) is older than the most recent one (2).

Reproduction

I have not been able to reproduce it because it is yet unclear how to force the ordering of nodes.
This report is solely based on code inspection.

Possible solution

Instead of deleting all dirents, keep the entry with ino=0 and prune later on.

***Uknown* ****: Can there be new versions of a dirent after an unlink operation?

[Schamper]

Best way to reproduce this is probably to manually massage a filesystem file to look like this. Then mount with Linux and see what the expected mount looks like.

[twiggler]

@Schamper

It is possible to create a jffs2 image where the tombstone dirent wheretarget_file is removed by setting the inode to zero comes before the old dirent (see bold lines):

Inode node at 0x07f44000, totlen 0x00000044, #ino 4, version 1, isize 0, csize 0, dsize 0, offset 0
Dirent node at 0x07f44044, totlen 0x00000031, #pino 1, version 4, #ino 4, nsize 9, name wrap_file
Inode node at 0x07f44078, totlen 0x00000049, #ino 4, version 2, isize 5, csize 5, dsize 5, offset 0
Padding node at 0x07f440c4, totlen 0x0000013c
Dirent node at 0x07f44200, totlen 0x00000033, #pino 1, version 5, #ino 0, nsize 11, name target_file
Padding node at 0x07f44234, totlen 0x000001cc**
Empty space found from 0x07f44400 to 0x07f48000
Inode node at 0x07f48000, totlen 0x00000aa0, #ino 2, version 215, isize 708608, csize 2652, dsize 2652, offset 705956
Inode node at 0x07f48aa0, totlen 0x00001044, #ino 2, version 216, isize 712704, csize 4096, dsize 4096, offset 708608
Inode node at 0x07f49ae4, totlen 0x00001044, #ino 2, version 217, isize 716800, csize 4096, dsize 4096, offset 712704
Inode node at 0x07f4ab28, totlen 0x00001044, #ino 2, version 218, isize 720896, csize 4096, dsize 4096, offset 716800
Padding node at 0x07f4bb6c, totlen 0x00000094
Inode node at 0x07f4bc00, totlen 0x00000044, #ino 3, version 1, isize 0, csize 0, dsize 0, offset 0
Dirent node at 0x07f4bc44, totlen 0x00000033, #pino 1, version 2, #ino 3, nsize 11, name target_file
Inode node at 0x07f4bc78, totlen 0x00000084, #ino 3, version 2, isize 64, csize 64, dsize 64, offset 0
Padding node at 0x07f4bcfc, totlen 0x00000104
Dirent node at 0x07f4be00, totlen 0x00000033, #pino 1, version 3, #ino 0, nsize 11, name filler_file

The tricky thing is that for example the linux kernel only places these tombstones on certain devices, specifically NAND.
(see https://github.com/torvalds/linux/blob/6146a0f1dfae5d37442a9ddcba012add260bceb0/fs/jffs2/write.c#L556)

However, I don´t think dissect can read NAND images because there is JFFS2 metadata in the OOB area?

[Schamper]

If you make a direct chip-off dump of the NAND, does that still matter?

[twiggler]

If you make a direct chip-off dump of the NAND, does that still matter?

Not sure; I think the main memory and OOB data are physically interleaved?

I did some more research and it seems the only data JFFS2 stores OOB are clean markers. I think we skip those nodes anyway.

In that case I would have expected a dump created by nanddump while omitting OOB data to result in a valid image, given that there are no bad sectors. Perhaps there is another issue.

[Schamper]

Does any of this matter? What just happens if you try to mount a handcrafted filesystem image with this, just mimick (or improve upon) that behavior and call it a day?

[twiggler]

Does any of this matter?

That depends. This issue of zombie dirents occurs on NAND devices, but JFFS2 fails on on a more fundamental level because it can't read NAND images at all. So in that sense this bug doesn´t matter.

I figured out why it cannot read those images; the first node is a CLEANMARKER, which gets written to OOB. But the main data area of that node was left as 0xFFFFFFFF, which is not the magic number.

I will create a ticket for this issue then and call it a day (#20).
I think (#20) has higher priority