Camellia derived key material (subL/subR schedule words, setup192's kk[32] 256-bit folded key, Encrypt/DecryptBlock tmp[4] block data) left unzeroed on the kernel stack; keyBitLength validated only by KASSERT, so production kernels would run on an uninitialized subkey schedule if a non-{128,192,256} length ever reached these entry points (latent: no in-tree callers)

Summary

camellia_setup128/256 compute the full subkey schedule into stack arrays and return without clearing them; setup192 additionally stages the RFC-3713 256-bit folded key in kk[32]; Encrypt/DecryptBlock leave plaintext/ciphertext in tmp[4]. Same class as DF-0966/DF-0967/DF-2363, but camellia.c has zero in-tree consumers (cryptoapi includes only aesni/rijndael/serpent/twofish), so the residue is unreachable today - filed as hardening. Separately, Ekeygen/EncryptBlock/DecryptBlock validate keyBitLength only via KASSERT (no-op in production): an out-of-tree or future caller with an odd length gets silent garbage encryption instead of an error (DF-2368 class, latent). Correctness of the primitive FULLY VERIFIED in the same run: all 4x256 sp* tables equal RFC 3713 SBOX compositions; RFC 3713 Appendix-A KATs pass encrypt+decrypt 128/192/256; 96/96 random vectors bit-identical to OpenSSL 3.0.20 camellia-ecb; key-schedule write coverage exact; all rotations/shifts defined-behavior; setup192 folding endianness-neutral. Table-based S-box lookups are data-dependent (cache-timing, DF-2367 class) but unreachable in-tree - noted, not filed.