alignment==0 passes the power-of-two check but means 'physical address 0' — guaranteed allocation failure after three full page-queue flush passes; plus copy-paste panic string in contigfree
| Field | Value |
|---|---|
| ID | DF-2892 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-20 Improper Input Validation |
| File | sys/vm/vm_contig.c |
| Lines | 268-269, 314, 594 |
| Area | vm |
| Confidence | likely |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:vm |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
(alignment & (alignment-1)) != 0 accepts alignment==0, but the scan
then requires (phys & (alignment-1)) == 0 == phys == 0 — never free
on real hardware. A caller passing 0 in the "no constraint" sense gets
a deterministic failure that first runs three full passes of
vm_contig_pg_clean over all 1024 inactive queues (and with M_WAITOK the
active queues — "very, very slow"), stalling every contigmalloc caller
including M_NOWAIT ones. boundary==0 is likewise accepted but harmless.
Separately contigfree's zero-size panic names the wrong function
('vm_contig_pg_kmap' at :594). No in-tree caller passes 0 (all pass
PAGE_SIZE/16/order-derived) — hardening. Fix: reject alignment==0
explicitly + fix the panic string.
Timeline
- 2026-09-02 Discovered during pass-2 audit of vm_contig.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2892 · 9 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 701 B | ↓ raw | |
| VERDICT.md | — | 1.1 KB | ↓ raw | |
| build.sh | — | 56 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 643 B | view raw | |
| manifest.json | — | 479 B | view raw | |
| run.sh | — | 87 B | view raw | |
| sourcenote.txt | — | 643 B | view raw | |
| verdict.json | — | 2.1 KB | view raw |
DF-2892 — alignment==0 stalls allocator + wrong panic string (Info-tier hardening verification)
What
alignment==0 stalls allocator + wrong panic string
Build
(source confirmation only)
Run
(source confirmation only)
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
Files
README.md VERDICT.md build.sh env.txt fix.diff manifest.json run.sh sourcenote.txt verdict.json
Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven).
Full batch context: the fix kernel contains all 41 hardening fixes of
this batch compiled together (build RC=0) and passed the complete A/B
suite plus a clean reboot.
DF-2892 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Line-accurate confirmation (runtime demo deliberately not run: alignment==0 produces a guaranteed multi-pass scan stall of ALL contigmalloc callers - a guest-wide wedge): the power-of-two check at vm_contig.c:268 'if ((alignment & (alignment-1)) != 0)' accepts alignment==0, after which the scan requires (phys & ULONG_MAX)==0 - physical page 0 - never free, so allocation deterministically fails only after three full vm_contig_pg_clean passes over all 1024 per-cpu page queues (M_WAITOK also loops through active queues 'very very slow'), stalling every contigmalloc caller including M_NOWAIT users. boundary==0 is accepted but harmless (mask ULONG_MAX never binds). contigfree's zero-size panic (:594 region) names the wrong function ('vm_contig_pg_kmap: size must not be 0'). No in-tree caller passes 0. Fix (treat alignment==0 as 1 + corrected panic string) compiled in the fix kernel.
Baseline vs fix kernel
baseline: see verdict above / run log fix: behavior changed as designed (see verdict)
Fix verification
not_testableNormalization + panic-string fix compiled and booted.
Confirmed kernel references
Detail
Evidence (decisive lines)
sourcenote.txt: arithmetic of the alignment==0 scan; fix.diff normalizes 0->1 and fixes the string
PoC changes
none (wedge risk; source-certain)
Verified recommended fix
Treat alignment==0 as 1 and fix the contigfree panic string
Verdict
Line-accurate confirmation (runtime demo deliberately not run: alignment==0 produces a guaranteed multi-pass scan stall of ALL contigmalloc callers - a guest-wide wedge): the power-of-two check at vm_contig.c:268 if ((alignment & (alignment-1)) != 0) accepts alignment==0, after which the scan requires (phys & ULONG_MAX)==0 - physical page 0 - never free, so allocation deterministically fails only after three full vm_contig_pg_clean passes over all 1024 per-cpu page queues (M_WAITOK also loops through active queues very very slow), stalling every contigmalloc caller including M_NOWAIT users. boundary==0 is accepted but harmless (mask ULONG_MAX never binds). contigfrees zero-size panic (:594 region) names the wrong function (vm_contig_pg_kmap: size must not be 0). No in-tree caller passes 0. Fix (treat alignment==0 as 1 + corrected panic string) compiled in the fix kernel.
No comments yet.