twofish_set_key performs no key-length validation enabling stack/struct OOB writes and mk_tab corruption on out-of-range key_len_bits

Summary

twofish_set_key derives ctx->k_len=key_len_bits/64 with no check key_len_bits is {128 192 256}. For oversized key_len_bits (k_len>=5) key-expansion loop writes past size-4 stack arrays me_key[]/mo_key[] and past s_key[4] into mk_tab[] and reads past caller key buffer. For key_len_bits<=0 loop skipped gen_mk_tab switch falls through leaving mk_tab uninitialised (heap info-leak source). Code defect is genuine memory-corruption primitive currently NOT reachable from any unprivileged syscall because every in-kernel caller (twofish_cbc_setkey twofish_xts_setkey) whitelists key length before calling. Latent/defense-in-depth gap becomes High-severity corruption if future caller forgets to validate. Related to DF-0965. [VERIFIED pass2: reproduced - key_len_bits 320 writes s_key 4 into mk_tab 0 and leaves schedule stale, 0 keeps previous key active, userspace twin SIGSEGVs on in_key guard page and smashes callee frame at k_len 16; length-refusal fix-validated, all in-tree callers pre-validate]