Found one, now what? about triforcelinuxsyscallfuzzer

[sokoow]

Oh, so it's as simple as running this on bare metal right?

#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>


int main(void) {

        madvise((void*)0x40001d, 0x6400000707000000, (int)0x1d00640000000064);

        return 0;
}

and I got:

# ./a.out 
Bus error
# ./a.out 
bash: ./a.out: cannot execute binary file: Exec format error

dmesg:

[90727.774210] Injecting memory failure for page 0x39185 at 0x40001d
[90727.774387] MCE 0x39185: recovery action for dirty LRU page: Recovered
[90727.774424] MCE: Killing a.out:19423 due to hardware memory corruption fault at 400543
[90761.017705] JBD2: Detected IO errors while flushing file data on dm-0-8
[91341.599164] Injecting memory failure for page 0x1914bb at 0x40001d
[91341.599348] MCE 0x1914bb: recovery action for dirty LRU page: Recovered
[91341.599389] MCE: Killing a.out:19975 due to hardware memory corruption fault at 400543

[timnewsham]

Oh, so it's as simple as running this on bare metal right?

You could also have taken the input file and run "./driver -tv < filename" on bare metal or inside the emulated environment. There are some notes on debugging in the readme that comes with the linux fuzzer.
We've run across this particular crash ourselves and observed that this one is caused by madvise() triggering a fake memory corruption issue (it’s a feature of madvise that I wasn’t aware of!) that is causing /bin/driver to get killed (not just the driver, but also the parent of the driver which is acting as a watchdog!). If you look at the root template's "init" file, after the driver runs, init finishes and when init dies, the kernel panics. That’s why you see error messages when running it on bare metal but you don't get the panic (because init didn’t get killed and didn’t exit).

This is the madvise flag that is being used:

   MADV_HWPOISON (Since Linux 2.6.32)
          Poison  a  page and handle it like a hardware memory corruption.
          This operation is available only for privileged  (CAP_SYS_ADMIN)
          processes.   This  operation  may  result in the calling process
          receiving a SIGBUS and the page being unmapped.  This feature is
          intended for testing of memory error-handling code; it is avail‐
          able only if the kernel was configured with  CONFIG_MEMORY_FAIL‐
          URE.

It requires a capability in the original namespace that only the "real" root has.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[sokoow]

What's actually interesting is the behavior of C program, so this:

[90761.017705] JBD2: Detected IO errors while flushing file data on dm-0-

It actually manages to damage the executable on disk, I can't run it anymore even after a reboot. So is this the case that it poisons page-cache somehow, and then that page gets written back to disk?