New Blog Post: Seth Jenkins broke kASLR by doing … nothing 😩

https://googleprojectzero.blogspot.com/2025/11/defeating-kaslr-by-doing-nothing-at-all.html

@buherator @natashenka https://googleprojectzero.blogspot.com/2025/11/defeating-kaslr-by-doing-nothing-at-all.html

@buherator thanks, fixed

@natashenka omg Linux is so easy 😭

@natashenka @gsuberland >Given that the maximum amount of theoretical physical memory is far larger than the entire possible linear map region range

I feel like I'm missing some prerequisite... how can physical memory be larger than the entire possible linear map range? Why wouldn't phys memory always be a subset of linear map range?

@cr1901 @natashenka the linear mapping region is for kernel lowmem only.

@cr1901 @natashenka there's a good diagram here, search "lowmem" to find the section: https://cs4118.github.io/www/2023-1/lect/21-linux-mm.html

@gsuberland Alright, that helps. But 39 bits of virtual address space still exceeds the 256GiB total theoretical physical memory? So what am I still missing?

Even kernel docs says the kernel has 512GiB of virtual address at its disposal: https://www.kernel.org/doc/Documentation/arm64/memory.txt

@cr1901 the way I understand it (Linux internals isn't my thing) if you've got 256GiB of RAM installed then the 39-bits of VA can be split into two 38-bit groups that can each address up to 256GiB of physmem, allowing both userspace and kernelspace VAs to address all physmem with a 1:1 split. on such a system you have *zero* space to move the kernel linear region's VA, because it can only be mapped at the very lowest possible address. if you map it elsewhere you can't address all your RAM.

@gsuberland cc: @jenkins Did you by any chance mean 256TiB of physical memory? What is the value of CONFIG_ARM64_*P*A_BITS in your demonstration?

@cr1901 previously they'd look at how much RAM you have at boot, split your VA space up between userspace and kernelspace with whatever ratio, then randomise the base VA of the linear region within the address range that you've given to the kernel. so in a scenario where you've got 64GiB of RAM and a 3:1 user/kernel VA split (3:1 is probably outdated, idk), that's 128GiB of VA space for the kernel, so you can move the 64GiB linear region around anywhere within that. so KASLR is easy.

@cr1901 but then memory hotplug became a thing. so now, even if you've only got 1GiB of RAM at boot, you might have 256GiB later. so you have to place the base of your linear region somewhere that allows it to expand to 256GiB. and there's only one address where you can do that, i.e. the lowest possible mapping address, so KASLR isn't feasible with this design.

@gsuberland >3:1 is probably outdated, idk

Yea, all the aarch64 splits seem to be 1:1. The 39-bit VA option seems to be the one where you get most screwed by KASLR. The link you showed me suggests that 64 bit targets don't bother with highmem. Guess it's not worth bringing back.

That said, note that I can't find a value for CONFIG_ARM64_PA_BITS lower than 48 from a Google search*. So I guess needing highmem w/ 39-bit VA is theoretically possible.

* Not that that means much.

@cr1901 yeah I think, having read a bit, they just do 1:1 these days for anything 64-bit.

the CONFIG_ARM64_PA_BITS value probably isn't super relevant here because CONFIG_ARM64_VA_BITS ends up being the limiting factor anyway. and my guess is 39-bit VAs were chosen for paging reasons (hardware address translation limits?), although that's just an educated guess.

@gsuberland I still think it's possible the author meant 256TiB, because he mentions "Given that the maximum amount of theoretical physical memory is far larger than the entire possible linear map region range".

AFAIK, 256GiB is not much bigger than... 256GiB :P.

Your explanation is extremely helpful all the same :D!

@cr1901 @gsuberland
If you're not just talking about the linear map, virtual address space significantly larger than the maximum physical memory has been commonplace since the origin of virtual memory (Manchester Atlas, 1962), and it has often proven quite useful. It was only with the advent of 32-bit microprocessors (Motorola MC68020, Intel 80386) and high-capacity DRAM chips that there was a period of equal sized virtual and physical address spaces, until Intel PAE and 64-bit microprocessors.

@brouhaha @gsuberland Yea, that is what I would expect to be the common case. But seems that for quicker access, 39 bits of virtual address is common in arm64 world, and it's theoretically possible that one day phys size and virt size could be equal. So that explains the kernel devs rationale.

My confusion is with the sentence I linked here (I think they meant 256TiB, 48 bits of phys. Just so happens that 256GiB is where the 1:1 split breaks down.): https://mastodon.social/@cr1901/115488316628194668

@cr1901 @brouhaha I think they do mean 256GiB, but the phrasing is just a bit awkward.

the sentence fragment "the kernel places the linear map at the lowest possible virtual address so it can theoretically be prepared to handle exorbitant (up to 256GB) quantities of hypothetical future hot-plugged physical memory" is, on its own, exactly correct. it organises the VA space so you get 256GiB VA for user- and kernelspace each.

@cr1901 @brouhaha the first part of the sentence - i.e. "given that the maximum amount of theoretical physical memory is far larger than the entire possible linear map region range" - is the somewhat confusing part. my guess is it was either intended to be talking about 512GiB from the full 39-bit space, or limitations on the size of the linear region with VM memory sharing, or just an awkwardly put point about the delta between reality (phone has <<256GiB RAM) vs. the theoretical (256GiB RAM).

@cr1901 @gsuberland
Quicker access? Per access, or just on a page fault needing a page table walk?

@brouhaha @cr1901 yeah, you don't have to walk as far down PTEs with 3-level as you do with 4-level, and 4-level would be overkill for phones anyway given that 3-level gets you 512GiB of VA space anyway.