DF-2220 — kobject_release() leaks kobj->name allocated by kobject_init_and_add()

Status: REPRODUCED (verbatim-code, kernel-compiled rig) — impact class: slow unbounded kernel memory growth (M_DRM) = availability only, root-gated triggers. Fix: A/B-validated in the same harness kernel (fix.diff, name saved before the release callback and kfreed after — mirroring upstream kobject_cleanup).

Part of the DF-22X batch (DF-2216 / DF-2220 / DF-2223 / DF-2224) verified in ONE harness kernel; this pack documents the DF-2220 section.

What this pack contains

Same layout as the DF-2216 pack (shared rig sources rig_head.c/rig_mid.c/ rig_tail.c, build.sh, run.sh, env.txt, full logs); finding-specific: fix.diff (against sys/dev/drm/linux_kobject.c), run_section.log (DF-2220 lines), run.first_meterbug.log (meter engineering record).

How to reproduce

Identical to the DF-2216 pack (same batch build + run); see that README or build.sh / run.sh headers.

Provenance

1. guest tree linux_kobject.c sha256 50b635ee... == audited tree.
2. kobject_init_and_add / kobject_release compiled into the kernel verbatim via #include <dev/drm/linux_kobject.c>; the kvasprintf they call is the verbatim drm_dragonfly.c:67-84 body (kvasprintf_verbatim.c sha256 12efc1be...) — the symbol lives in the drm module, which is not (and cannot be) loaded on this guest.
3. kobject_release_fixed = same bytes + fix.diff, def renamed (fixed_kobject.c sha256 c53ad2be...).
4. the kobject_put → kref_put → kobject_release chain is the real header inline chain (linux/kobject.h), not a re-implementation.

Expected output (baseline = unmodified production code)

DF2220 CONTROL  paired kmalloc/kfree x16384: memuse delta=0 (expect 0)
DF2220 BASELINE kobject_init_and_add+kobject_put x16384: memuse delta=655360 kmalloc-calls delta=32768 releases=16384 leaked-bytes-per-cycle=40
DF2220 BASELINE init:+32 after_release:+32 name ptr still valid, content=[leaked_name_probe_0123456789] len=28 (allocation SURVIVED release)
DF2220 FIXED    init:+32 after_release_fixed:+0 (name freed by the patch)
DF2220 FIXED    init+release_fixed x16384: memuse delta=0 kmalloc-calls delta=32768 releases=16384
DF2220 VERDICT: baseline leaked 655360 bytes in 16384 cycles (control 0, fixed 0) -> LEAK CONFIRMED, FIX VALID

• CONTROL proves the meter returns to zero for correctly paired alloc/free.
• BASELINE cycles are production-shaped: container kmalloc (freed by the release callback, like ttm_bo_global_kobj_release), name via the verbatim kvasprintf (linux_kobject.c:39), teardown through the real kobject_put chain. releases=16384 proves the release path executed.
• The single-shot probe shows the name allocation still live and intact AFTER kobject_release() returned — the pointer is simply lost with the container.

Attacker input / reachability

In-tree callers: ttm_bo.c:1565 (ttm_bo_global_init), ttm_memory.c:257/300/321 (zones + global), ttm_page_alloc.c:838, ttm_page_alloc_dma.c:1177 — every drm subsystem lifecycle creates ~5-7 kobjects and destroys them via kobject_put. Trigger = drm module load/unload cycles (root kldload/kldunload) or GPU attach/detach; ~40 bytes leaked per release. No UAF (buffer never re-accessed), no corruption, no info disclosure → no privesc route; ceiling is unbounded slow kernel memory growth (DoS).

DF-2220 — VERDICT

REPRODUCED — verbatim-code, kernel-compiled rig; leak quantified per cycle with the kernel's own malloc accounting; fix A/B-validated in the same kernel. Impact: slow unbounded kernel memory growth (M_DRM) — availability only, root-gated triggers. No privesc route (see below).

Rig class and why

Same batch harness kernel as DF-2216 (DFV22X); the production sys/dev/drm/linux_kobject.c is #included verbatim (sha-gated 50b635ee...). kobject_init_and_add/kobject_release in the kernel are the production functions. The kvasprintf() they call lives in the drm module (drm_dragonfly.c:67-84), which cannot be loaded on this guest — so the rig carries that body verbatim too (kvasprintf_verbatim.c, sha 12efc1be..., extracted+hashed by build.sh). The teardown chain kobject_put → kref_put → kobject_release is the real header inline chain (linux/kobject.h:85-90), not a re-implementation.

Line-accurate confirmation

linux_kobject.c:39: kobj->name = kvasprintf(M_WAITOK, fmt, ap) — a separately-malloc'd string (kmalloc size+1, M_DRM, drm_dragonfly.c:76). linux_kobject.c:45-51: kobject_release() invokes kobj->ktype->release(kobj) and nothing else — kobj->name is never freed. Upstream Linux frees it in kobject_cleanup() (kfree_const(kobj->name) after the type release). The in-tree release callbacks (ttm_bo_global_kobj_release, ttm_mem_zone_kobj_release, ttm_mem_global_kobj_release, ttm_pool_kobj_release ×2, ttm_drm_class_device_release) all kfree() the container embedding the kobject, so the name pointer dies with the container on every release. No UAF: the buffer is simply lost.

Mechanical reproduction (decisive run, run.log)

40 = slab-chunk-quantized 33-byte name ("rig_kobj_%06d_aaaa..." → 32 chars + NUL). Both return-shape and accounting prove the leak and its elimination.

Fix validation (A/B, same kernel)

fix.diff saves kobj->name into a local before the release callback (the callbacks free the container — saving after would be a UAF; this mirrors upstream kobject_cleanup ordering exactly), then kfree(name, M_DRM) after it, with MALLOC_DECLARE(M_DRM) added (the type is kernel-resident, kern_slaballoc.c:202). Extracted-from-patched-bytes kobject_release_fixed in the same kernel: loop delta 0, releases still 16384, identical container lifetimes. fix_status: fixed.

Reachability (who can actually trigger this)

In-tree creators: ttm_bo.c:1565 (ttm_bo_global_init), ttm_memory.c:257/300/321 (memory zones + global), ttm_page_alloc.c:838, ttm_page_alloc_dma.c:1177 — ~5-7 kobjects per drm subsystem lifecycle, each torn down via kobject_put. Trigger requires drm module load/unload cycles (root kldload/kldunload) or GPU attach/detach events: ~40 B per release, ~100-200 B per full lifecycle. Root-gated, slow-growth availability issue — matches the filed Low severity (AV:L/AC:H/PR:H).

Privesc assessment (standing directive)

None. Pure allocation leak; the lost buffer is never re-accessed (no UAF window), nothing is copied to userspace, no length or bounds is ever wrong. No primitive → no escalation chain.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.