[hinkley]

I don’t know if it’s still a thing but there used to be debugging tools that would put a page of memory marked as either read only or unreadable in front of every malloc call so that any pointer arithmetic with a math error would trigger a page fault which could be debugged. It worked in apps that didn’t use too much of total memory or too many fine grained allocations. I mean obviously turning every 8 byte pointer into a whole memory page could consume all of memory very quickly. But in front of arrays or large data structures that could work.

[saagarjha]

In this case the write bypassed page protections

[dwattttt]

It shouldn't bypass page protections, that would be a kernel bug. And quite a bit harder to achieve too, since the kernel would still be using the same virtual address mapping as user space there.

[saagarjha]

They made the pages read-only for themselves; the kernel has the ability to write through that.

[dwattttt]

Sure, but only by either changing the page permissions on the page that virtual address is on, or by remapping it elsewhere as writable; both of those are heavy handed operations, and neither would be in the "report the result of an IO operation" path.

x86 page table entries can't express "user read only, kernel read/write"

[jcalvinowens]

The user mapping may be read only, but the kernel will likely use other writable mappings to the same page.

Linux for example maintains a big writable linear mapping of all RAM at all times (on 64-bit), you can corrupt read-only user pages through it all day and never fault. Code running in the kernel generlly uses virtual addresses from that mapping.

[dwattttt]

By policy, asking the Windows kernel to write to an address happens within an SEH try/catch, and a failure will result in the kernel returning an error code.

The kernel has no reason to be trying to bypass page protections; what if you asked it to write to a shared read-only page?