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).
No comments yet.