Translation table size never validated: heap OOB read and NULL-deref panic via undersized/NULL d_table

Summary

iconv_xlat_conv indexes dp->d_table[(u_char)*src] across full 0..255 range (iconv_xlat.c:99) and iconv_xlat_open blindly trusts csp->cp_data (iconv_xlat.c:61) with zero validation table is 256 bytes. Only registration-layer check is upper bound (iconv.c:410 ia_datalen<=ICONV_CSMAXDATALEN=266240) no lower bound no equality check. cspair registered with ia_datalen==0 yields cp_data==NULL (allocation skipped iconv.c:426) first conversion dereferences NULL+offset panics. cspair with 0<ia_datalen<256 reads up to (256-ia_datalen) bytes past kmalloc table object writes into caller output buffer kernel-heap info leak. struct iconv_cspair does not carry data length converter cannot defend itself at open time. Legitimate kiconv_add_xlat_table always passes 256. Attacker: host root kern.iconv.add sysctl requires SYSCAP_NOSYSCTL_WR OID lacks CTLFLAG_PRISON jailed root blocked. Defense-in-depth/hardening gap becomes real primitive if sysctl exposed to confined-privileged context. [VERIFIED pass2: datalen 0 pair NULL-derefs at VA 0x42, 64-byte table sweeps 192 of 192 output bytes past the allocation with stable pointer-like heap content across 3 boots; cp_datalen equals 256 validation fix-validated EINVAL]