# DF-5711 — netmap_vale bridge-name clamp off-by-one leaves `bdg_basename` unterminated (Info, hardening)

- **File (audit target):** `sys/libkern/strncpy.c` (pass 2, consumer census)
- **Defect location:** `sys/net/netmap/netmap_vale.c:331-332` + `:352`
- **Severity:** Info — latent non-termination; **no live consumer in release
  builds** (only `ND()`/`D()` debug prints, which are no-ops per
  `netmap_kern.h:80-81`); filed as hardening.

## Reproduce

Build with the shared rig (`findings/poc/DF-5710/build.sh` compiles the kernel
`strncpy.c` unmodified; this harness is part of it), then:

```
./harness_netmap_clamp
```

Expected:

```
bdg_basename has NUL within [0,16)? -> NO (index -1)
strlen(bdg_basename) (what any %s consumer reads): 47
```

A bridge name of ≥16 chars (clamped `namelen = IFNAMSIZ`, `strncpy` of
exactly 16 non-NUL bytes into `char bdg_basename[IFNAMSIZ]` at
`netmap_vale.c:198/352`) leaves the array with no NUL: any future consumer
that treats it as a C string reads past the array (demonstrated: strlen 47
through the adjacent canary).

## Fix

`fix.diff`: force `b->bdg_basename[IFNAMSIZ - 1] = '\0'` after the copy.
Deliberately does NOT change the `IFNAMSIZ` clamp, because `bdg_namelen`
feeds the `strncmp`-based bridge matching (`netmap_vale.c:342-344`) —
terminating the stored copy fixes the string without altering lookup
semantics. Applies clean to guest `/usr/src`.