> I'm wondering because I thought just knowing the layout isn't enough to attack the kernel. Don't you need other vulnerabilities too, that let you actually acc

> I'm wondering because I thought just knowing the layout isn't enough to attack the kernel. Don't you need other vulnerabilities too, that let you actually access the memory? NB: My understanding of this is purely arm's-length. I've never actually done exploit development. Short version: you need to know the layout of the code in order to actually exploit those other vulnerabilities. Longer version: Attackers: We can inject machine code into the stack and execute it [1]. Developers: Not anymore; stack pages aren't executable [2]. Attackers: We can turn your own code against you by manipulating the stack to "return" to an arbitrary sequence of pre-existing functions with arguments of our choosing [3]. Developers: Not anymore; we randomize the address space every time we load the code, so now you don't know where those functions are. You could guess, but you're going to be wrong and just crash the system almost all of the time [4]. Attackers: For the kernel on x86/amd64 systems, we have a way of reading the page table from an exploited user process, which we can then parse to discover where you located those functions. <---- you are here [1] https://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiting_stack_buffer_overflows https://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiti... [2] https://en.wikipedia.org/wiki/NX_bit https://en.wikipedia.org/wiki/NX_bit [3] https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming [4] https://en.wikipedia.org/wiki/Address_space_layout_randomization https://en.wikipedia.org/wiki/Address_space_layout_randomiza...