Re: kern/60377: x86 cpu_uarea_alloc: pmap_update before freeing redzone pages

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60377; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Kevin Bowling <kevin.bowling%kev009.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost, skrll%NetBSD.org@localhost,
	thorpej%NetBSD.org@localhost
Subject: Re: kern/60377: x86 cpu_uarea_alloc: pmap_update before freeing redzone pages
Date: Sun, 28 Jun 2026 18:32:03 +0000

 I'm confused by this one.
 
 The logic here, condensed and paraphrased, is:
 
 1. allocate [va1, ..., vaN] and [pa1, ..., paN] with uvm_km_alloc
 2. pmap_kremove the vaN->paN mapping (but keep 1 through N-1)
 3. free paN
 4. pmap_update
 
 (The purpose is to make vaN a guard page to catch kernel bugs.)
 
 Note that there is no question about freeing or reusing _virtual_
 addresses -- only about freeing and potentially reusing _physical_
 addresses.
 
 If I understand correctly, the idea of moving pmap_update earlier is
 to ensure that any loads or stores prior to pmap_kremove won't
 accidentally read or write data in paN _after_ it has been repurposed
 for something else, leaking or corrupting a kernel data structure.
 
 But I don't see how it could be possible -- barring critical bugs
 elsewhere in the kernel -- for any other CPUs or threads or interrupt
 handlers to load from or store to vaN.  And we certainly don't load
 from or store to vaN in this function.
 
 So what's the harm in freeing paN before pmap_update?  We've made a
 page table entry that we break, but nobody can possibly be using vaN,
 so the physical page shouldn't be affected by any of this.