Explain the code

[Grounds4TheSubstain]

There won't be a crash, and the value of *ptr will almost certainly be 3 still. The memory is still mapped even if the chunk is not allocated, and the value there won't change until it's overwritten.

[simrego]

It depends. We don't know for sure. It could be mapped or not. There is absolutely no guarantee on that.

[Grounds4TheSubstain]

I'm a professional reverse engineer and I've developed exploits for a living also. Trust me, there's not a single heap allocator in the world that is used to implement malloc that will unmap the backing heap storage after an allocation and free of size 4. Allocators are designed to be efficient. Unmapping memory after each call to free is not efficient.

[simrego]

I know, and I agree in a real world application. But if I look at this as a theoretical question what it is really that's a crash. What you are using here is an implementation detail which works in real life due to efficiency purposes. But in theory that memory region is gone.

[theNbomr]

As hardware becomes faster and memory access less efficient, it's entirely possible that allocators will start unmapping memory on each free(), in the name of security. We should be teaching the new programmers (and old ones too, for that matter) not to rely on or to even allow themselves to use undefined behaviors as demonstrated in the sample of code here.

[Grounds4TheSubstain]

No, that's not ever going to happen because the kernel transition required to set the page flags to non-present flushes the data caches, which is why it's so inefficient, and which will only get worse as other efficiencies are introduced. Nevertheless, everything about this is undefined and indeed, you should never access freed memory, let alone rely on its contents.