# DF-2766 — VERDICT

**Status: reproduced (exact accounting match), fix validated.**

## Baseline (stock kernel)
5 x (mount tmpfs; mountctl -a; umount) cycles:

    journal    0  0     ->  5  5.00K   (in-use after 5 cycles)
    journal-fifo 0      ->  0          (membase properly freed)

5.00K = 5 x 1024 B = JREC_STREAMID_JMAX/8 = the leaked mnt_jbitmap
blocks (M_JOURNAL). Only journal_detach() (vfs_jops.c:251) frees them,
and journal_remove_all_journals() (vfs_jops.c:422-430, called from
dounmount vfs_syscalls.c:1037) never calls it — unlike the
MOUNTCTL_REMOVE path (:208-209). Nothing in the mount destructor
(vfs_mount.c:403 kfree(mp)) touches mnt_jbitmap. run.log.

## Fix (validated on kernel #2)
journal_remove_all_journals() now calls journal_detach() when the list
drains (fix.diff hunk 3; journal_detach made idempotent by the DF-2763
hunks; dounmount already holds mnt_token). Post-fix, the same 5-cycle
run leaves `journal` in-use at **0** (alloc count 255->265, all freed).
run_fixed.log.

## Impact
1 KB leak per journaled mount/unmount cycle, unbounded across mount-loop
workloads. Root-gated (journal install), no memory-safety consequence.
Severity Low (CWE-401).