This means that for a typical implementation of a normal filesystem, there would be no reason to not support mmap.Arch/arm64/kernel/elfcore.c:110:5: warning: stack frame size (2160) exceeds limit (2048) in 'elf_core_write_extra_data' archive mirror help / color / mirror / Atom feed * arch/arm64/kernel/elfcore.c:110:5: warning: stack frame size (2160) exceeds limit (2048) in 'elf_core_write_extra_data' 10:55 kernel test robot 0 siblings, 0 replies only message in threadįrom: kernel test robot 10:55 UTC ( / raw)Ĭc: llvm, kbuild-all, Linux Memory Management List, Will Deacon, Mark Brown mmap support can then be added to such a filesystem more or less by adding `.mmap = generic_file_mmap` to the file_operations structure. wouldn't be able to execute any ELF binaries from it because that requires mapping the binaries into memory.Īlso, AFAIK the typical way filesystems are implemented on Linux is that the read and write operations just access the filesystem's page cache using shared helpers because the filesystem layer is where data is cached to avoid unnecessary disk accesses. However, I do not know of any 'proper' filesystems without mmap ops for files, and such a filesystem would be somewhat limited: I think you e.g. Yes, after 2f36db710093, using ecryptfs on top of filesystems that don't support mmap will stop working. I believe that a nice way to do it would be to put the lower kstack to sleep in a ptrace syscall entry/exit stop, let the upper kstack recurse down into the lower one, pause the upper kstack while its stack pointer points into the saved userland registers at the top of the lower kstack's stack, and then use ptrace's userland register manipulation functions on the lower thread to first overwrite the stuff the upper kstack's stack pointer points to and then perhaps even restore the saved userland registers (especially CS and SS) to sane values via ptrace.) DeleteįUSE does support mmap (which is a really nice feature, but also useful for exploitation), and layering ecryptfs on top of FUSE should still work. (Before I realized that the buddy allocator is generic and used for more things than just kstacks, I actually thought about how I would exploit an overflow of a kstack into another one.

I guess that given a kernel stack pointer leak, your approach of overflowing a kstack into another kstack would also help with exploitation of this issue, since that would eliminate the unreliable heap spray.

Linux thread kernel stack size