# DF-2904 (speculative) — int `slice` counter overflow in mbr_extended → OOB slice write

## What
`mbr_extended()` (sys/kern/subr_diskmbr.c:423-501) counts accepted logical
slices in a signed `int slice` seeded from `ssp->dss_nslices` (u_int) and
incremented once per accepted non-extended EBR entry, with the array bound
guarded only by `if (slice >= MAX_SLICES)` (subr_diskmbr.c:490).  If the
counter ever wraps past INT_MAX it becomes negative, `slice >= MAX_SLICES`
is then FALSE, and `sp = &ssp->dss_slices[slice]` (subr_diskmbr.c:495)
indexes far before the allocation — `mbr_setslice()` then writes
attacker-controlled `ds_offset`/`ds_size` (from dp_start/dp_size) at
`&ssp->dss_slices[negative]`, an out-of-bounds kernel write with
attacker-chosen 64-bit values at a (coarsely) attacker-chosen negative
offset.

## Why speculative / not PoC'd
Reaching 2^31 accepted entries requires ≥ 2.1 billion successful synchronous
EBR reads inside ONE probe run.  The EBR recursion depth cap (`level >= 16`,
subr_diskmbr.c:427) bounds the tree at Σ 4^i (i=1..16) ≈ 5.7G potential
entries, so the count is reachable in principle (a malicious device answers
instantly), but at realistic DragonFly sync-I/O round-trip cost the probe
must first sustain a multi-day wedge — during which the system is already
effectively dead from the DF-0133 exponential-read blowup (this is the same
recursion).  The OOB write is therefore a latent memory-corruption
consequence layered on the known algorithmic DoS, not an independently
practical exploit; it is recorded because the guard is type-broken and the
fix is one line.

## Fix
Use an unsigned/64-bit counter or clamp the running count (e.g. track
`slice` as `u_int` and additionally test `slice >= MAX_SLICES` after
increment, or bound `ssp->dss_nslices` at MAX_SLICES inside the loop).