brk/sbrk mappings are created RWX (VM_PROT_ALL as both prot and max_protection) β executable heap defeats future W^X policy
| Field | Value |
|---|---|
| ID | DF-2965 |
| 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-732 |
| File | sys/vm/vm_unix.c |
| Lines | 137-141, 223-227 |
| 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
Both sys_sbrk and sys_obreak pass VM_PROT_ALL (RWX) as both the protection and max_protection arguments to vm_map_find, so every page of the malloc/brk heap is mapped read-write-execute. On amd64 the pmap honors VM_PROT_EXECUTE via the NX bit, so heap memory is genuinely executable. This is historical BSD behavior (FreeBSD's obreak does the same) and adds no exposure beyond what an unprivileged process already gets from mmap(PROT_READ|PROT_WRITE|PROT_EXEC); filed as defense-in-depth so the heap is not an implicit W^X escape hatch the day W^X enforcement lands β and so shellcode stashed by a memory-corruption bug can run directly from the heap without a second mprotect step. Fix: VM_PROT_RW (optionally keep max_protection=ALL as a compat escape hatch).
Timeline
- 2026-09-02 Discovered during pass-2 audit of vm_unix.c (GLM 5.3). DF-0961/0962 re-verified still present, not re-reported.
No comments yet.