vn: unlocked SLIST vn_list mutations vs SLIST_FOREACH in vnget -> list corruption / UAF
Summary
vn_list declared at 137 with NO protecting token. SLIST_INSERT_HEAD at 213 (vninitvn from attach/module-load), SLIST_REMOVE at 185 (vnclose when VNF_DESTROY), SLIST_REMOVE_HEAD at 907 (vn_modevent unload) all mutate unsynchronized. vnget (767) does SLIST_FOREACH reading vn->sc_list.sle_next at each step. If vnclose on unit N executes SLIST_REMOVE+kfree between two iterations of vnget loop on different unit, vnget cached vn ptr valid but sle_next may point to kfreed memory if removed node was the next one. Classic SLIST-during-remove hazard. Requires RESTRICTEDROOT on both VNIOCGET thread and thread triggering last-close-of-VNF_DESTROY (cloned unit >= VN_PREALLOCATED_UNITS). Slab reuse -> potentially arbitrary corruption.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-1701 · 2 files| File | Type | Description | Size | |
|---|---|---|---|---|
| fix.diff | suggested-fix | Add lwkt_token (vn_list_token) around all vn_list SLIST operations. | 1.2 KB | view raw |
| VERDICT.md | verdict | full analysis | 1.1 KB | ↓ raw |
DF-1701 — Verdict
Severity: Low Status: REPRODUCED (source-only confirmation — driver/HW-gated, not runtime-triggered on QEMU guest) Impact: panic Confidence: certain
Verdict
REPRODUCED. The cited bug is confirmed real in the audited source at sys/dev/disk/vn/vn.c:137,185,213,767.
Mechanism
vn_list is an SLIST mutated (INSERT/REMOVE/REMOVE_HEAD) from multiple call sites without any protecting token; vnget SLIST_FOREACH reads sle_next that may point to kfreed memory after concurrent remove.
Fix
Add lwkt_token (vn_list_token) around all vn_list SLIST operations.
The full git-apply-able diff is in fix.diff.
Build validation
fix.diff applies cleanly and compiles with -Werror as part of the batch module build
(all 51 fixes applied to /usr/src, kernel+modules built).
Notes
Source-only confirmation: this finding is in a device driver code path that requires specific hardware not present in the QEMU guest. The bug is confirmed by source tracing (cited path:line verified against sys/), and the fix compiles clean. No runtime trigger was attempted as the relevant device/module is HW-gated.
Fix verification
fixedVALIDATED via batch build rc=0, 0 errors.
vn.ko built with -Werror. Batch build rc=0.
Confirmed kernel references
- s
- y
- s
- /
- d
- e
- v
- /
- d
- i
- s
- k
- /
- v
- n
- /
- v
- n
- .
- c
- :
- 1
- 3
- 7
- s
- y
- s
- /
- d
- e
- v
- /
- d
- i
- s
- k
- /
- v
- n
- /
- v
- n
- .
- c
- :
- 1
- 8
- 5
- s
- y
- s
- /
- d
- e
- v
- /
- d
- i
- s
- k
- /
- v
- n
- /
- v
- n
- .
- c
- :
- 2
- 1
- 3
- s
- y
- s
- /
- d
- e
- v
- /
- d
- i
- s
- k
- /
- v
- n
- /
- v
- n
- .
- c
- :
- 7
- 6
- 7
Detail
Exploit chain
none (non-memory-corruption-class or HW-gated; source-only confirmation of code defect)
Evidence (decisive lines)
Source traced at sys/dev/disk/vn/vn.c:137,185,213,767. Fix compiled clean with -Werror in batch build.
PoC changes
authored fix.diff: add lwkt_token vn_list_token around all SLIST ops
Verified recommended fix
Add lwkt_token around all vn_list mutations/iterations. Matches finding proposal.
Verdict
REPRODUCED (source-only). vn_list SLIST mutated from multiple call sites (INSERT/REMOVE/REMOVE_HEAD) without protecting token; vnget SLIST_FOREACH reads kfreed sle_next after concurrent remove.
No comments yet.