Summary

devfs_clone_bitmap_chk/set/put derive chunk = unit/64 (C truncation) and then index bitmap->bitmap[chunk] with only an upper-bound check. A negative unit produces a negative chunk that passes every guard: chk OOB-reads bitmap[-1] and evaluates 1UL << negative (UB), set OOB-WRITES by clearing a bit below the allocation, put OOB-WRITES by setting one. No in-tree caller can currently supply unit < 0 (if_name2unit clamps, if_clone_alloc_unit rejects > IF_MAXUNIT, clone-on-open uses fff-allocated units, destroy paths use make_dev-chosen units). The one semi-reachable negative value is devfs_reference_ops' id == -1 after the 255 ops-id limit (devfs_core.c:2642 continues instead of failing): on x86-64 lands in-bounds at chunk 0 with a UB shift, corrupting bitmap semantics (bit 63 falsely freed -> possible ops-id reuse) after 255+ distinct registered dev_ops. Pure hardening: any future caller that forwards a parsed or foreign unit reintroduces a kernel OOB write. Fix: reject negative units at all three entry points + fail registration instead of continuing with id -1. [VERIFIED pass2: negative-unit OOB confirmed at all three helpers; no reachable negative caller; unit-lt-0 guards compiled]