DragonFlyBSD Kernel Audit
← triage · dashboard
DF-2982

Stale comments describe retired page-swapblk design, misdocumenting the OBJT_DEFAULT no-swap-metadata invariant that three files silently depend on

Field Value
ID DF-2982
Status new
Severity Info
CVSS 3.1 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:N
CWE CWE-1078
File sys/vm/default_pager.c
Lines 33-39, 100-104, 112-117, 125-135
Area vm
Confidence certain
Discovered 2026-09-02
Pass 2 (GLM 5.3 second pass)
Bucket base:vm
Reported pending
Known CVE none
CVE match novel

Summary

default_pager.c's header and per-function comments describe a design that no longer exists: they claim vm_page carries a '->swapblk' field for OBJT_DEFAULT pages, that the object is converted to OBJT_SWAP only 'when the page is physically freed', and that default_pager_haspage() 'just call[s] swap_pager_haspage()'. In the actual code vm_page has no swapblk field, conversion is immediate and atomic at first metadata build (swap_pager.c:2345-2347, 1606-1608), and default_pager_haspage returns FALSE unconditionally. The code is correct; the documentation is not. No direct runtime impact — the hazard is maintenance: the OBJT_DEFAULT ⇒ swblock_count==0 invariant is load-bearing for three unrelated enforcement points (default_pager_dealloc's KKASSERT, vm_fault's zero-fill-on-FAIL correctness, the DRM shims' vm_pager_has_page use), none of which is documented anywhere except these wrong comments. A future maintainer 'restoring' the documented behavior would silently break anonymous-memory data integrity or turn the dealloc KKASSERT into a user-triggerable panic. Fix: rewrite the comments (row diff). Executable code proven clean this pass.

Timeline

  • 2026-09-02 Discovered during pass-2 audit of default_pager.c (GLM 5.3).

Discussion (0)

No comments yet.