On 25/12/25(Thu) 08:52, Theo de Raadt wrote:
> How big is the region that this wiring attempt happens on?

It depends on the arguments passed to sysctl(8).  That's where the bug
is coming from.

I don't have more visibility since syzkaller didn't generates a
reproducer yet.

> I am going to guess it is always 1 page, or maybe 2 or 3.
> 
> Is there an off-by-one that causes uvm_map_pageable to be called?

That's a plausible guess.

> Is it related to guard page creation, or later de-allocation of a single
> page which has had guard pages next to it?

I don't know.

> The code around pmem_range to do guard pages was very difficult.  During
> development guard pages were first included in the object but this created
> problems, so later it was moved to being not a part of the object.  Maybe
> some off-by-one is created by the history of the code.
> 
> Can you duplicate the loop and the wired_count == 1 check upwards into
> uvm_map_pageable, where you have more variables available for inspection
> to determine what the bad condition is that causes uvm_map_pageable_wire
> to be called?  The goal would be not to avoid the uvm_fault_wire, but to
> log it.  You don't want to crash or assert, because then you only capture
> one failure and if people don't visually see it (like, the problem might
> be related to drm code, and crashing to non-X console is not 100% reliable).

Problem is that only Syzkaller triggers the panic reliably and I need to
call panic() to get a report.  I'm afraid logging won't help with this
tool.