Bug 202637

Created attachment 281251 [details]
Proof of Concept

[Kernel version]
This bug can be reproduced on
kernel 5.0.0-rc7.

[Reproduce] * Use a VM, since our PoC simulates a crash by triggering a SysRq!
1. Download base image
$ wget https://gts3.org/~seulbae/fsimg/f2fs-10.image

2. Mount image
$ mkdir /tmp/f2fs
$ sudo mount -o loop f2fs-10.image /tmp/f2fs

3. Compile and run PoC
$ gcc poc.c -o poc
$ sudo ./poc /tmp/f2fs
(System reboots)

[Check]
1. Re-mount the crashed image
$ mkdir /tmp/f2fs
$ sudo mount -o loop f2fs-10.image /tmp/f2fs

2. Check inconsistency
$ stat /tmp/f2fs/foo
-> Access: (0755/drwxr-xr-x)


[Description]
In the base image, 2 directories and 7 files exist.

0: 0755 (mount_point)
+--257: 0755 foo
   +--258: 0755 bar
      +--259: 0644 baz (12 bytes, offset: {})
      +--259: 0644 hln (12 bytes, offset: {})
      +--260: 0644 xattr (0 bytes, offset: {})
      +--261: 0644 acl (0 bytes, offset: {})
      +--262: 0644 æøå (4 bytes, offset: {})
      +--263: 0644 fifo
      +--264: 0777 sln -> mnt/foo/bar/baz

The PoC basically
1. opens directory "foo",
(line 26) fd = syscall(SYS_open, "./foo", O_DIRECTORY, 0);
2. changes the permission of it to 0666,
(line 27) syscall(SYS_chmod, "./foo", 0666);
3. flushes its metadata, and then
(line 28) syscall(SYS_fsync, fd);
4. simulates a crash by rebooting right away without unmounting.
(line 30) system("echo b > /proc/sysrq-trigger");

As we run fsync operation on "foo",
we expect that the metadata regarding
the new permission is successfully flushed to disk,
and when we remount the crashed image,
we will see that "foo"'s mode is changed to 0666.

However, the directory still has its old mode, 0755.