Re: [PATCH] mm: make zeropage read-only

[Jann Horn]

On Fri, May 8, 2026 at 6:12 PM Jann Horn <jannh@xxxxxxxxxx> wrote:
> Put the zeropage in the read-only data section - nothing should ever change
> its contents. Set up a new section .rodata..page_aligned to mirror the
> existing .data..page_aligned and .bss..page_aligned sections.
>
> There have been several security bugs where the kernel grabs references to
> pages from some userspace-specified source, via GUP or splice, with
> read-only semantics; and then later on, the kernel loses track of the
> pages' read-only semantics and writes into them.
>
> I have seen such bugs in out-of-tree GPU drivers before, and recently
> upstream Linux bugs of this shape have been discovered as well.
>
> One problem with these bugs is that fuzzers and such will have a hard time
> noticing them, because the kernel has no mechanism to directly detect that
> such a bug has occurred. It would be nice if we had debug infrastructure to
> keep track of whether file pages are supposed to be writable, or such; but
> for now, the easiest way to make these bugs detectable in at least some
> cases is to make sure that writing the 4K zeropage is mapped as read-only
> in the kernel, so that attempting to write into it immediately crashes
> (unless the write happens through a vmap mapping or such).
>
> This patch might increase the size of vmlinux by 4K since .rodata is stored
> in the ELF file while .bss is not; but the compressed kernel image size
> shouldn't change much, since it's compressed.
>
> I have tested that with this patch applied, calling
> `get_user_pages_fast(address, 1, 0, &page)` on a freshly-created anonymous
> VMA and writing into the page with
> `*(volatile char *)page_address(page) = 0` will cause an oops.
>
> Signed-off-by: Jann Horn <jannh@xxxxxxxxxx>
> ---
>  include/asm-generic/vmlinux.lds.h | 1 +
>  include/linux/linkage.h           | 1 +
>  mm/mm_init.c                      | 2 +-
>  3 files changed, 3 insertions(+), 1 deletion(-)

Seth pointed out that this is more or less a duplicate of Ard's
<https://lore.kernel.org/all/20260427153416.2103979-19-ardb+git@xxxxxxxxxx/>.

So this patch is redundant; sorry for the noise.