mdcreate unit allocation (mdunits++) is unlocked and non-atomic β concurrent mdopen auto-create of the top unit can mint two md devices with the same unit number/cdev name
Summary
No global lock around mdunits++; mdopen auto-create is the only multi-threaded caller - two CPUs opening the top unit can both read mdunits==N, producing two same-named /dev/mdN cdevs, duplicate devstat entries, and double dispose at cleanup. Operator-group open-only trigger, tiny window. Serialize-creation fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4830 Β· 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1.1 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
N processes on separate CPUs loop open(/dev/md
Evidence (decisive lines)
findings/poc/DF-4830/ (this verdict)
Verdict
SMP race, low impact: sc->unit = mdunits++ at md.c:410 has no global lock - the per-unit token serializes nothing global, and mdopen's auto-create (:135-136) is the only multi-threaded caller. Two CPUs opening the top unit can both read mdunits==N, minting two md_s with the same unit/cdev name (devfs never dedups), duplicate devstat entries, and later double dispose of the shared name/minor space at cleanup. Operator-group trigger (open only), tiny window, uncertain downstream - Low. The growth aspect of auto-create was re-confirmed live on the guest (opening /dev/md0 created md1). Distinct from DF-2477/2478. Serialize-creation fix.
No comments yet.