Dmitry Vyukov

`0x5cfe` maps to these attributes: ``` #define FS_UNRM_FL 0x00000002 /* Undelete */ #define FS_COMPR_FL 0x00000004 /* Compress file */ #define FS_SYNC_FL 0x00000008 /* Synchronous updates */ #define FS_IMMUTABLE_FL 0x00000010 /*...

Neutralizing it is the last resort, since then we won't ever test it on any filesystem. And it seems to be doing lots of complex things that are fs specific....

> This won't solve the problem of generating a perfectly valid program doing ioctl$FS_IOC_SETFLAGS() though. Exactly, so it won't solve the problem. It's even easier for the fuzzer to do...

Fun. This indeed works: ``` #include #include int main() { int fds[2]; pipe(fds); openat(fds[1], "/dev/kvm", 0, 0); sleep(1000); } ``` What is this fd? ``` $ cat /proc/890477/fdinfo/5 pos: 0...

It looks like it's just "/dev/kvm". But in today's episode of Fun With Fuzzers: `0x5cfe` returns EINVAL for this ioctl, but it looks like it passed memory mmaped from kvm...

The mmaped memory most likely has 0s (at least among values that can possibly succeed when being using as a file name in openat), but opening an empty string from...

> so the mapped CPU data contains 0x1000000002f, which is indeed treated as "/\0". This is hilarious. I don't think we can prevent all such cases, fuzzer came with other...

All of this will also reduce fuzzer's ability to find bugs (passing device mmaped memory as a file name looks like a good corner case to test), so it's a...

I think we try to avoid overlapping structs as much as possible, where it's reasonably easy to do.

> My current intent is to factor out the `./syz-tmp` bits from `namespace_sandbox_proc()` and make sure every sandbox uses them. This would be good for sandbox=none, but I am not...