vm_contig_pg_clean color-queue validation is provably wrong: reclaims only color-0 pages, skipping 1023/1024 page queues — contigmalloc reclaim flush is ~99.9% ineffective
| Field | Value |
|---|---|
| ID | DF-2889 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-670 Always-Incorrect Control Flow |
| File | sys/vm/vm_contig.c |
| Lines | 194 (callers :339-343, :355-361) |
| 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
After busying a page, vm_contig_pg_clean re-validates with
if (m->queue - m->pc != queue). Pages are always enqueued on
PQ_base + m->pc with m->pc &= PQ_L2_MASK, so for any page on queue
PQ_INACTIVE+q, m->queue - m->pc == PQ_INACTIVE — which equals queue
(PQ_INACTIVE + q) only when q==0. The intended check was
m->queue != queue (correctly asserted at :176). Net effect: both
callers loop q=0..1023 but every queue with q>0 is walked page-by-page
(spinlocks + busy_try + wakeup per page) with ZERO pages reclaimed —
only color-0 pages are ever cleaned. Large contigmalloc allocations
(DRM/agp/netmap/nvmm) fail far more often than designed; each failed
pass still performs the full slow walk of every page in every queue
("very, very slow" per the code's own comment), stalling all
contigmalloc callers three times including M_NOWAIT ones — a local
availability amplification for any user-reachable contigmalloc path
(netmap/GPU ioctls). Fix: m->queue != queue (one-line, row diff).
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-2889 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 726 B | ↓ raw | |
| VERDICT.md | — | 2.0 KB | ↓ raw | |
| build.sh | — | 61 B | view raw | |
| dfv_safe.c | — | 21.8 KB | view raw | |
| env.txt | — | 401 B | view raw | |
| fix.diff | — | 831 B | view raw | |
| manifest.json | — | 657 B | view raw | |
| run.log | — | 931 B | view raw | |
| run.sh | — | 137 B | view raw | |
| verdict.json | — | 2.1 KB | view raw |
DF-2889 PoC evidence pack
What
vm_contig_pg_clean re-validation predicate is wrong: colored page queues never contribute pages to contigmalloc reclaim.
Build
make -C rig (KMOD dfv_safe)
Run
kldload smbfs; kldload dfv_safe.ko; sysctl -w dfv.q2889=1; dmesg | grep DF2889
Expected
dmesg: colored queues q=1..1023 hold N pages, buggy predicate passes 0, fixed predicate passes N
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 All logs are full untrimmed captures unless noted. fix.diff is the git-apply-able verified fix (authored after verification; never applied to the audit tree).
DF-2889 - verification verdict
Status: reproduced | reproduced: 1 | impact: denial_of_service | confidence: certain
Proven on the live kernel by walking the real colored page queues with the exact marker protocol vm_contig_pg_clean itself uses. For PQ_INACTIVE+q, q=1..1023: 2566 pages across 1023 non-empty queues; the buggy :194 predicate (m->queue - m->pc != queue) passes for ZERO of them (m->queue - m->pc is always PQ_INACTIVE for any page in a colored queue, so the predicate reduces to q != 0 and skips every page); the intended predicate (m->queue != queue) passes for all 2566. Control q=0: buggy predicate passes 2/2. Contigmalloc reclaim flush is therefore exactly as ineffective as claimed (colored queues contribute nothing), and each failed pass still walks every queue - the availability amplifier for user-reachable contig paths.
Evidence pointers
run.log DF2889 line: 2566 pages in 1023 queues; buggy predicate passes 0; fixed passes 2566; q=0: 2/2
Kernel references
PoC changes vs the filing sketch
harness module replicates the kernel loop read-only against live queues
Fix
recommendation: one-line fix: if (m->queue != queue)
fix status: not_testable
fix compiled in fix-all kernel; harness proves old predicate mathematically wrong and new predicate correct against the same live queues (both kernels read identical data); end-to-end contigmalloc-under-pressure behavior not additionally driven
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.
Fix verification
not_testablefix compiled in fix-all kernel; harness proves old predicate mathematically wrong and new predicate correct against the same live queues (both kernels read identical data); end-to-end contigmalloc-under-pressure behavior not additionally driven
Confirmed kernel references
Detail
Evidence (decisive lines)
run.log DF2889 line: 2566 pages in 1023 queues; buggy predicate passes 0; fixed passes 2566; q=0: 2/2
PoC changes
harness module replicates the kernel loop read-only against live queues
Verified recommended fix
one-line fix: if (m->queue != queue)
Verdict
Proven on the live kernel by walking the real colored page queues with the exact marker protocol vm_contig_pg_clean itself uses. For PQ_INACTIVE+q, q=1..1023: 2566 pages across 1023 non-empty queues; the buggy :194 predicate (m->queue - m->pc != queue) passes for ZERO of them (m->queue - m->pc is always PQ_INACTIVE for any page in a colored queue, so the predicate reduces to q != 0 and skips every page); the intended predicate (m->queue != queue) passes for all 2566. Control q=0: buggy predicate passes 2/2. Contigmalloc reclaim flush is therefore exactly as ineffective as claimed (colored queues contribute nothing), and each failed pass still walks every queue - the availability amplifier for user-reachable contig paths.
No comments yet.