kobj API robustness gaps: double kobj_init() silently leaks a permanent class reference (pins KLD class+ops forever), kobj_delete() on an uninitialized/deleted object NULL-derefs obj->ops->cls, and cyclic baseclass graphs recurse without bound
| Field | Value |
|---|---|
| ID | DF-2962 |
| 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:L |
| CWE | CWE-476 / CWE-401 / CWE-835 |
| File | sys/kern/subr_kobj.c |
| Lines | 137-157, 257-273 |
| Area | kern/kobj |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
Three contract-robustness gaps in the kobj object protocol, each requiring a buggy privileged-authored kernel consumer (none found in-tree — all audited callers in subr_bus.c, libiconv, and dev/sound are balanced): (1) kobj_init() re-initializes without checking obj->ops, so a second init permanently inflates cls->refs — the class and its 2056-byte ops table can then never be freed, and for a KLD-registered driver the leaked ref keeps the class compiled after devclass_delete_driver, leaking kernel memory per load/unload cycle; (2) kobj_delete() reads obj->ops->cls with no NULL guard, so double-delete or delete-of-uninitialized-object is a NULL-deref panic instead of a caught invariant violation; (3) kobj_lookup_method_mi() walks baseclasses[] with no cycle or depth guard, so a driver author who constructs a cyclic class graph gets unbounded kernel recursion and stack-overflow panic at first dispatch/compile. All availability-only and developer-error-gated. Fix: cheap invariant checks (KASSERT on obj->ops state in init/delete; depth cap in lookup_method_mi).
Timeline
- 2026-09-02 Discovered during pass-2 audit of subr_kobj.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2962 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 806 B | ↓ raw | |
| VERDICT.md | — | 1.0 KB | ↓ raw | |
| build.sh | — | 50 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 1.5 KB | view raw | |
| h41.c | — | 14.9 KB | view raw | |
| harness.log | — | 2.0 KB | view raw | |
| manifest.json | — | 533 B | view raw | |
| run.sh | — | 105 B | view raw | |
| verdict.json | — | 2.3 KB | view raw |
DF-2962 — kobj double-init ref leak / delete NULL-deref / cycle recursion (Info-tier hardening verification)
What
kobj double-init ref leak / delete NULL-deref / cycle recursion
Build
cd /root/h41 && make
Run
kldload ./h41.ko; sysctl -w debug.h41.cmd=12
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
A/B one-liner: baseline: refs 1 2 3 | fix: refs 1 1 1, delete->0
Files
README.md VERDICT.md build.sh env.txt fix.diff h41.c harness.log manifest.json run.sh 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-2962 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Mechanically reproduced via the harness on the stock guest for the sharpest of the three gaps: double kobj_init on the same object inflated the class refcount monotonically (refs 1 -> 2 -> 3 after three inits; still 2 after kobj_delete - the leaked refs pin the class and its 2056-byte compiled ops table forever, which for a KLD-registered class leaks kernel memory per load/unload cycle). kobj_delete on an uninitialized object NULL-derefs obj->ops->cls (subr_kobj.c:266) and kobj_lookup_method_mi recurses over baseclasses with no cycle/depth guard - both confirmed by reading; all require a buggy privileged-authored consumer (none in-tree; callers audited balanced in pass 2). On the fix kernel refs stay 1 across re-inits (previous reference released) and return to 0 after delete.
Baseline vs fix kernel
baseline: baseline: refs 1 2 3 | fix: refs 1 1 1, delete->0 fix: behavior changed as designed (see verdict)
Fix verification
fixedA/B: baseline monotonic leak; fix kernel stable refs (release-prev-ref on re-init, delete NULL guard, lookup depth cap).
Confirmed kernel references
Detail
Exploit chain
double kobj_init -> permanent class ref leak -> KLD class+ops pinned across load/unload cycles
Evidence (decisive lines)
harness.log T12: refs 1 2 3 then 2 after delete; fix kernel T12: 1 1 1 then 0
PoC changes
trivial kobj_class with empty method table; KOBJ_FIELDS object on static storage
Verified recommended fix
Release the previous class reference on re-init; guard delete; cap baseclass recursion depth
Verdict
Mechanically reproduced via the harness on the stock guest for the sharpest of the three gaps: double kobj_init on the same object inflated the class refcount monotonically (refs 1 -> 2 -> 3 after three inits; still 2 after kobj_delete - the leaked refs pin the class and its 2056-byte compiled ops table forever, which for a KLD-registered class leaks kernel memory per load/unload cycle). kobj_delete on an uninitialized object NULL-derefs obj->ops->cls (subr_kobj.c:266) and kobj_lookup_method_mi recurses over baseclasses with no cycle/depth guard - both confirmed by reading; all require a buggy privileged-authored consumer (none in-tree; callers audited balanced in pass 2). On the fix kernel refs stay 1 across re-inits (previous reference released) and return to 0 after delete.
No comments yet.