contigmalloc_map silently ignores its map argument — kmap always allocates from kernel_map; a caller freeing via its own map corrupts the wrong vm_map
| Field | Value |
|---|---|
| ID | DF-2891 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-628 Function Call with Incorrectly Specified Arguments |
| File | sys/vm/vm_contig.c |
| Lines | 527, 563, 577 |
| 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
contigmalloc_map(..., vm_map_t map) forwards map to
vm_contig_pg_kmap, which never uses it — KVA is unconditionally taken
from kernel_map (:527); the doc comment admits the contract. A future
caller passing a non-kernel map (the exported API shape invites it)
will kmem_free() an address from a map with no entry for it — vm_map
entry corruption/panic — while the real entry leaks in kernel_map. No
current in-tree caller passes a different map — latent API trap. Fix:
KKASSERT(map == kernel_map) (and long-term drop the parameter).
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-2891 · 9 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 683 B | ↓ raw | |
| VERDICT.md | — | 800 B | ↓ raw | |
| build.sh | — | 56 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 495 B | view raw | |
| manifest.json | — | 479 B | view raw | |
| run.sh | — | 87 B | view raw | |
| sourcenote.txt | — | 560 B | view raw | |
| verdict.json | — | 1.8 KB | view raw |
DF-2891 — contigmalloc_map ignores its map argument (Info-tier hardening verification)
What
contigmalloc_map ignores its map argument
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-2891 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Line-accurate confirmation: vm_contig_pg_kmap (vm_contig.c:527 region) allocates KVA exclusively from kmem_alloc_pageable(kernel_map, ...) - the 'map' parameter forwarded by contigmalloc_map (:559-581) is never used, and the comment above contigmalloc_map documents the kernel_map-only contract. A future caller passing its own map and freeing through it would kmem_free an address from a map with no entry for it (entry corruption/panic) while the real kernel_map entry leaks. No current caller passes a different map (rg). Fix (KKASSERT map == kernel_map) 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_testableAssert compiled and booted; no contigmalloc caller regressed (guest DMA drivers ran through the A/B suite).
Confirmed kernel references
Detail
Evidence (decisive lines)
sourcenote.txt: unused-parameter analysis; fix.diff asserts the contract
PoC changes
none
Verified recommended fix
KKASSERT(map == kernel_map) or drop the parameter
Verdict
Line-accurate confirmation: vm_contig_pg_kmap (vm_contig.c:527 region) allocates KVA exclusively from kmem_alloc_pageable(kernel_map, ...) - the map parameter forwarded by contigmalloc_map (:559-581) is never used, and the comment above contigmalloc_map documents the kernel_map-only contract. A future caller passing its own map and freeing through it would kmem_free an address from a map with no entry for it (entry corruption/panic) while the real kernel_map entry leaks. No current caller passes a different map (rg). Fix (KKASSERT map == kernel_map) compiled in the fix kernel.
No comments yet.