linux-ext4 - [Bug 202485] New: chmod'ed permission not persisted upon fsync

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: <bug-202485-13602@https.bugzilla.kernel.org/>
Date:   Fri, 01 Feb 2019 20:10:18 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 202485] New: chmod'ed permission not persisted upon fsync

https://bugzilla.kernel.org/show_bug.cgi?id=202485

            Bug ID: 202485
           Summary: chmod'ed permission not persisted upon fsync
           Product: File System
           Version: 2.5
    Kernel Version: 4.18~Latest
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@...nel-bugs.osdl.org
          Reporter: seulbae@...ech.edu
        Regression: No

Created attachment 280919
  --> https://bugzilla.kernel.org/attachment.cgi?id=280919&action=edit
Proof of Concept

[Kernel version]
This bug can be reproduced on
kernel 4.18 ~ 4.20.0+(kernel 645ff1e8e704c4f33ab1fcd3c87f95cb9b6d7144)

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

2. Mount image
$ mkdir /tmp/ext4
$ sudo mount -o loop ext4-00.image /tmp/ext4

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

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

2. Check inconsistency
$ stat /tmp/ext4/foo/bar/fifo
-> Access: (0644/prw-r--r--)

[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

foo/bar/fifo is a FIFO file.
The PoC basically
1. changes its permission,
(line 26) syscall(SYS_chmod, "foo/bar/fifo", 0400);
2. opens it,
(line 27) syscall(SYS_chmod, "foo/bar/fifo", 0400);
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");

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/bar/fifo's mode is changed to 0400.

However, the file still has its old mode, 0644.

Reported by Seulbae Kim (seulbae@...ech.edu) from SSLab, Gatech

-- 
You are receiving this mail because:
You are watching the assignee of the bug.