Summary

vm_fault_object() unconditionally executes vm_page_zero_fill(fs->mary[0]) at the zero-fill-on-no-backing-store epilogue of the backing-chain walk. For an OBJT_MGTDEVICE object at fs->first_ba, mary[0] is explicitly NULL'd at line :2033 before jumping to readrest; if the device pager then returns VM_PAGER_FAIL, the FAIL branch at :2194 only frees mary[0] for non-first_ba and falls through goto next, where line :2299 sets first_m = mary[0] = NULL and the no-backing-store branch reaches vm_page_zero_fill(NULL) at :2327. pmap_zero_page(VM_PAGE_TO_PHYS(NULL)) dereferences NULL, panicking the kernel.

Root cause

The page-acquisition block at vm_fault.c:1975-2063 special-cases OBJT_MGTDEVICE at line :2032-2034:

fs->mary[0] = NULL;
if (fs->ba->object->type == OBJT_MGTDEVICE)
    goto readrest;

This skips the allocation that every other object type performs, leaving mary[0] NULL and relying on vm_pager_get_page() (called at :2162) to supply a page. The subsequent failure handling at :2194-2201 only handles the non-first_ba case explicitly:

if (rv == VM_PAGER_FAIL) {
    if (fs->ba != fs->first_ba) {
        if (fs->mary[0]) { vm_page_free(fs->mary[0]); fs->mary[0] = NULL; }
    }
    goto next;
}

For ba == first_ba (the MGTDEVICE case), mary[0] stays whatever the pager left it (NULL on failure) and control falls to next: at :2290. Line :2299-2300 then does if (fs->ba == fs->first_ba) fs->first_m = fs->mary[0]; — propagating the NULL into first_m. MGTDEVICE objects normally have backing_ba == NULL, so the if (next_ba == NULL) block at :2310 is entered. Since ba == first_ba, the inner restoration block at :2315-2321 is skipped, mary[0] is still NULL, and vm_page_zero_fill(fs->mary[0]) at :2327 dereferences it.

The sibling VM_PAGER_ERROR path at :2216-2251 handles this correctly by returning KERN_FAILURE; the VM_PAGER_FAIL path was simply not audited for the MGTDEVICE NULL-mary case.

Threat model & preconditions

• Attacker position: Any user with access to a GPU/render node (/dev/dri/card*, /dev/dri/renderD*) or, on platforms with ENABLE_EFI, via the EFI runtime mapping.
• Privileges gained or impact: Kernel panic (NULL dereference) — local DoS.
• Required config or capabilities: A VM_MAPTYPE_NORMAL mapping backed by an OBJT_MGTDEVICE object whose cdev_pg_fault handler returns VM_PAGER_FAIL on a fault at a pindex where first_ba has no backing_ba.
• Reachability: Currently latent — today's in-tree MGTDEVICE fault handlers (i915_gem_fault, ttm_bo_vm_fault, amdgpu_ttm_fault, radeon_ttm_fault, efi_pg_fault) return only VM_PAGER_OK or VM_PAGER_ERROR, never VM_PAGER_FAIL. The bug becomes a live unprivileged DoS the moment any MGTDEVICE driver returns VM_PAGER_FAIL (a one-line change in any DRM driver's error mapping, or a third-party/loadable DRM driver). The author of vm_fault.c clearly did not contemplate this combination: the MGTDEVICE special case and the FAIL path were written independently.

Proof of concept

No exploit is possible against the in-tree tree today because no MGTDEVICE driver returns VM_PAGER_FAIL. To prove the defect end-to-end, build a throwaway kld module that registers a /dev/faulty_mgt cdev whose cdev_pg_fault returns VM_PAGER_FAIL on the second call, mmap it, and touch the mapping twice. For site verification without building a kld, a maintainer can temporarily change one of the in-tree DRM fault handlers' ret = VM_PAGER_ERROR; to ret = VM_PAGER_FAIL; and exercise the driver from user space.

Expected output

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x...
...
pmap_zero_page(...)    at pmap_zero_page+0x...
vm_page_zero_fill(...) at vm_page_zero_fill+0x...
vm_fault_object(...)   at vm_fault_object+0x...
vm_fault(...)          at vm_fault+0x...
trap_pfault(...)       at trap_pfault+0x...
trap(...)              at trap+0x...

Impact

Kernel panic — local DoS when triggered. Currently latent; becomes live if any MGTDEVICE driver returns VM_PAGER_FAIL.

Recommended fix

Defend the zero-fill epilogue against an unexpectedly NULL page:

--- a/sys/vm/vm_fault.c
+++ b/sys/vm/vm_fault.c
@@ -2318,6 +2318,16 @@ vm_fault_object(struct faultstate *fs, vm_pindex_t first_pindex,
                pindex = first_pindex;
                fs->mary[0] = fs->first_m;
            }
            fs->first_m = NULL;
+
+           /*
+            * A NULL page here means the pager was asked to provide
+            * a page (e.g. OBJT_MGTDEVICE, which does not pre-
+            * allocate) and returned VM_PAGER_FAIL without supplying
+            * one.  Do not try to zero-fill a NULL page.
+            */
+           if (fs->mary[0] == NULL) {
+               vm_object_pip_wakeup(fs->first_ba->object);
+               unlock_things(fs);
+               return (KERN_PROTECTION_FAILURE);
+           }

            /*
             * Zero the page and mark it valid.

References

• sys/vm/vm_fault.c:2032-2034 — MGTDEVICE special case that sets mary[0] = NULL.
• sys/vm/vm_fault.c:2194-2201 — VM_PAGER_FAIL branch that doesn't handle the first_ba + NULL case.
• sys/vm/vm_fault.c:2216-2251 — the VM_PAGER_ERROR sibling path that handles it correctly.

Timeline

• 2026-07-05 Discovered during automated audit.
• pending Reported to DragonFlyBSD security contact.