DF-2835
sys_vmspace_create violates its own ABI contract: accepts id==NULL and silently ignores type/data instead of rejecting them
| Field | Value |
|---|---|
| ID | DF-2835 |
| 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-20 Improper Input Validation |
| File | sys/vm/vm_vmspace.c |
| Lines | 146-201 (contract at :138-139) |
| Area | vm |
| Confidence | certain |
| Discovered | 2026-08-31 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:vm |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
The syscall documents "An id of NULL cannot be used. The type and data
fields must currently be 0." but the implementation never checks
uap->id, uap->type, or uap->data. A NULL id is accepted as an RB key
and type/data are ignored entirely. No memory-safety consequence today
(type is never used to index anything); contract-enforcement hardening
so a future typed-vmspace extension cannot silently mis-parse old
callers, and the documented NULL-id sentinel stays reserved. Fix:
if (uap->id == NULL || uap->type != 0 || uap->data != NULL) return
(EINVAL); at entry next to the vkernel_enable gate.
Timeline
- 2026-08-31 Discovered during pass-2 audit of vm_vmspace.c (GLM 5.3).
No comments yet.