This reminds me, including files from sysfs and procfs in compilers can cause problems because gcc and clang use stat() to find the #include file size, and stat() returns incorrect information for sysfs and procfs file systems.
I always wondered if these bugs could be exploited somehow, perhaps in one of these remote execution environments, especially since they mmap() the files using the wrong stat() reported filesize.
sad to say these bugs still seem present in current compilers… Well, gcc isn’t segfaulting anymore, but clang still is reading a bunch of 0 bytes from the rest of the page the file is mapped to. It would probably also be worth trying to see if #include will have issues on other special files on Linux: pipes, sockets, dev files, etc.
This reminds me, including files from sysfs and procfs in compilers can cause problems because gcc and clang use stat() to find the #include file size, and stat() returns incorrect information for sysfs and procfs file systems.
I always wondered if these bugs could be exploited somehow, perhaps in one of these remote execution environments, especially since they mmap() the files using the wrong stat() reported filesize.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66909 https://bugs.llvm.org/show_bug.cgi?id=24168
sad to say these bugs still seem present in current compilers… Well, gcc isn’t segfaulting anymore, but clang still is reading a bunch of 0 bytes from the rest of the page the file is mapped to. It would probably also be worth trying to see if #include will have issues on other special files on Linux: pipes, sockets, dev files, etc.