VERDICT — DF-2232 (sys/libkern/linux_idr.c idr_grow signed-overflow growth loop)

Status: REPRODUCED — impact dos (hang / panic-sized kmalloc), confidence certain. Fix authored and validated on a rebuilt kernel. No memory-unsafety path exists (analysis below); no uid=0 chain is possible from this bug.

Environment

• Guest: DragonFly 6.5-DEVELOPMENT, kernel X86_64_GENERIC (options INVARIANTS), 6 vCPU, 4 GiB RAM, QEMU/KVM. Baseline kernel: #0 Thu Jul 2 06:02:54 UTC 2026. Fixed kernel: #1 Sat Oct 17 10:36:44 UTC 2026.
• Compiler: cc 8.3 (DragonFly base); module built with kernel flags -O2 -fno-strict-overflow (signed wrap deterministic, same as kernel).
• Verbatim gate: guest /usr/src/sys/libkern/linux_idr.c sha256 22d421c35bfd7ebc7ae2df137b52b7ece0a9cf349a8f9369b440389e033a95de — equal to the audited tree; the rig includes that file byte-identical.

What was run (evidence trail)

1. Control (run.a.log): phases 1+2 — normal wants 1..1000 round-trip on the verbatim KLD copy and on the kernel's own exported KPI. Both PASSED with identical results (grow 255→1023, pre_get/get_new_above protocol settles in 2 iterations, remove/realloc reuses slot 1000). This also demonstrates the idr_maxwant poisoning protocol the attack rides on: first idr_get_new_above(sid) with a fresh higher sid returns -EAGAIN after raising idr_maxwant (linux_idr.c:327-331).

2. Giant kmalloc (run.b.log, panic.b.txt): idr_alloc(start=1<<29, end=0) through the verbatim copy. The allocator-boundary hook (outside the verbatim file) captured the request live:

[DF2232-B] ALLOCATOR BOUNDARY: kmalloc(17179869168 bytes [0x3fffffff0], M_IDR, flags 0x102) -> real allocator

17179869168 = (2^30-1) * sizeof(struct idr_node=16) — exactly the predicted ~16 GiB M_ZERO|M_WAITOK request. On the 4 GiB guest the allocation never returned (page-by-page vm_page_alloc + vm_wait() in kmem_slab_alloc, sys/kern/kern_slaballoc.c:1706-1800; the per-type limit check in _kmalloc only trips on cumulative use, not on a single first request). The hard-IRQ watchdog panicked at 15 s with the captured request size in the marker; backtrace shows it fired from systimer_intr → pcpu_timer_process_oncpu → splz_timer (interrupt context, proving the design requirement: immune to the wedge).

3. Infinite spin, verbatim copy (panic.c1.txt; repeat in panic.c1b.txt): thread A: idr_get_new_above(sid=INT_MAX) → -EAGAIN, idr_maxwant=2147483647 poisoned; then idr_pre_get → never returns (a_done=0, a_stage=2): the growth loop computed 2*INT_MAX+1 → -1 and spins forever holding the lwkt idr token. Thread B called idr_remove on the same idr and never returned (b_started=1, b_acquired=0 in run 1; in the repeat run B hung already inside its pre-spin token check) — the livelock the finding predicted. Watchdog panic at 15 s with the state flags.

4. Infinite spin, shipped binary (panic.c2.txt): identical outcome with the kernel's OWN exported idr_get_new_above / idr_pre_get (last_kmalloc_req=0: the rig's kmalloc hook is not in this path — the spinning code is the stock kernel text at 0xffffffff809d5590). This closes the "your recompile behaves differently" objection.

Root cause (line-accurate)

• sys/libkern/linux_idr.c:427-430 — nf = 2*nf+1; while (nf <= want) in signed int: want ≥ 2^29-1 drives the kmalloc size toward (2^30-1)*16 = 16 GiB; want == INT_MAX makes 2*INT_MAX+1 wrap to -1 and the predicate -1 <= INT_MAX true forever.
• sys/libkern/linux_idr.c:437-438 — the wrapped/oversized nf flows into kmalloc(nf * sizeof(struct idr_node), ..., M_ZERO|M_WAITOK).
• Reachability of want: idr_alloc start (linux_idr.c:358-375, only start < 0 rejected), idr_get_new_above sid → idr_maxwant (linux_idr.c:327-331) → idr_pre_get grow (linux_idr.c:274-275). No upper bound anywhere. In-tree callers (drm_gem start=1; amdgpu PASID 16-bit) are bounded — latent KPI hazard, hence the rig drives the exported KPI.

Why DoS and not memory corruption / privesc (team directive)

• The wrapped nf = -1 cannot escape the loop into the size computation: the do-while only exits when nf > want; exiting with negative nf requires want < -1, and every reachable want is non-negative (idr_alloc rejects negative start at :365-366; idr_maxwant only rises via max() at :328; the forced-growth want = idr_count at :303 is > 0).
• Even in the impossible case, nf * sizeof(struct idr_node) promotes nf to size_t: (size_t)(-1) * 16 = 0xFFFFFFFFFFFFFFF0 — a gigantic OVER-allocation request (allocator refuses), never an under-allocation. The subsequent bcopy at :451-452 uses the OLD idr_count, and the race guard at :441 frees the new buffer if it is not larger. There is no path to a smaller-than-needed allocation, so no heap corruption, no forged-object primitive, no uid=0 chain. Impact ceiling: kernel-mode livelock holding an lwkt token, unbounded M_WAITOK draw (memory exhaustion of every page into wired zero pages), watchdog-observable hang — DoS.

Fix validation (fix.diff, fix_run.log, fix_build.log)

fix.diff: idr_grow() becomes static int, rejecting want >= IDR_MAX_IDS ((1<<24)-1) with ENOMEM; growth loop otherwise unchanged (with the cap, max computed nf = 2^25-1 — no signed overflow is reachable); idr_pre_get maps failure to result 0 (its documented failure contract — drm-style callers then give up instead of looping), idr_alloc maps it to -ENOMEM (both grow sites, token correctly released via the existing done: path).

Cycle: guest reset to clean source → patch applied in guest /usr/src (patch -p1, 6/6 hunks) → make -j6 nativekernel KERNCONF=X86_64_GENERIC (320 s, -Werror clean) → installkernel → reboot into #1 Sat Oct 17 10:36:44. Rig rebuilt against the FIXED file (sha 1c04da32…, recorded in build.log) and all phases re-run:

• control phases: PASSED, output identical to baseline (fix/run-all.log, fix/control-fixed.log);
• phase 3: idr_alloc RETURNED -12 — and the hook proves the largest request that reached the allocator was the 4080-byte idr_init allocation: no giant kmalloc was ever issued;
• phases 4/5: pre_get RETURNED 0, a_done=1 b_acquired=1, "no spin, no livelock" — on both the fixed verbatim copy and the fixed kernel functions;
• grep -c panic fix_run.log → 0; guest stayed up throughout.

Note on rig history: the first fixed-kernel validation run completed all phases successfully but crashed AFTER success during kldunload — a defect in my first rig (systimer teardown race + a leaked idr freed the module text too early), not in the fix; corrected by keeping the module resident (EBUSY) after crash-phases and destroying the leftover idr; the second run (fix_run.log) is clean end-to-end. The crash and its analysis are part of the serial console history and were re-verified to not involve linux_idr.c code paths beyond malloc_uninit bookkeeping.

Bottom line

The finding is fully confirmed on the stock kernel, at exact byte sizes, with livelock proof, on both a verbatim recompile and the shipped binary; the one-line-bound fix eliminates both manifestations with bit-identical normal-path behavior. Class: latent-KPI kernel DoS (Medium) — no privilege-escalation potential exists for this bug.

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.