DF-2368 — rijndael key-size validation is a no-op KASSERT (Nr=0 -> runaway round loop / OOB read)

File: sys/crypto/rijndael/rijndael-alg-fst.c (+ wrapper sys/crypto/rijndael/rijndael-api.c)

Verdict (see VERDICT.md for the full narrative)

REPRODUCED on the stock INVARIANTS guest kernel (impact: panic / latent kernel DoS; confidence: certain). Both halves of the finding were demonstrated through the REAL kernel functions:

1. panic: Invalid key size (0) — rijndael_set_key(bits=0) reaches the KASSERT at rijndael-alg-fst.c:738, the ONLY validation. On production (non-INVARIANTS) kernels this compiles to do {} while (0) and rijndaelKeySetupEnc returns 0 at line 814, so the wrapper stores ctx->Nr = 0 with a partially-written schedule (rk[0..7] written unconditionally, lines 740-743/762-763/784-785).
2. The Nr=0 consequence: the round loop (r = Nr >> 1; for(;;){ ... rk += 8; if (--r == 0) break; ... }, lines 951-1007) never terminates (--r runs -1, -2, ...) and walks rk forward 32 bytes per iteration, reading far past ek/dk. Demonstrated: 4128 bytes past the end of the 488-byte rijndael_ctx, fatal kernel-mode read fault at rijndaelEncrypt+0x1d9.

NOT reachable by an unprivileged user today: every in-tree caller pre-validates the key size (see VERDICT.md reachability section). This is a latent landmine for any future/unprivileged-fed caller — hence the original Low severity, which this verification confirms.

Fix validated A/B (fix.diff): invalid sizes rejected with zeroed schedules, Nr=0 encrypts return immediately, and all 16 FIPS-197 / SP800-38A / OpenSSL-derived KATs remain bit-identical.

Rig

Kernel-compiled harness (runtime kldload GPFs on this guest) driving the REAL rijndael_set_key / rijndael_encrypt / rijndaelKeySetupEnc through sysctl kern.rijnh.test. Build/run below; all ops log with the RIJNH: tag (dmesg).

Build

On the guest (as root, from this directory):

./build.sh              # installs rig into /usr/src, nativekernel build + install
                        # (buildkernel fails: "You must buildworld before
                        #  buildkernel" on this snapshot; nativekernel is the
                        #  documented native-tools path, same obj tree)
reboot

Run

./run_kat.sh                    # control: 16/16 KAT PASS + twin validation
./run_setkey.sh 0               # DEMO A: panic "Invalid key size (0)"
./run_poison.sh poison          # DEMO B: fatal trap 12, OOB read walk
./run_poison.sh direct          # DEMO B via raw rijndaelEncrypt
./run_idx.sh                    # DF-2367 side-channel evidence (shared rig)

After a panic the guest sits in DDB: recover with vm.sh reset harness-kernel (snapshot taken right after the rig kernel was installed).

Fix validation: patch -p1 < fix.diff in /usr/src, rebuild, reboot, re-run the same commands — see VERDICT.md for the recorded A/B.

Expected output (stock kernel)

• run_kat.sh: RIJNH: KAT summary 16 pass 0 fail of 16 vectors, twinval 600 vectors, 0 mismatches, guest stays up.
• run_setkey.sh 0: kernel panic, ssh dies; serial console shows panic: Invalid key size (0). + backtrace rijndaelKeySetupEnc <- rijndael_set_key <- rijnh_run_setkey (panic.setkey0.txt).
• run_poison.sh poison|direct: Fatal trap 12: page fault while in kernel mode, fault virtual address = 0x800475000, Stopped at rijndaelEncrypt+0x1d9: xorl -0x8(%rdi),%ecx (panic.poison.txt, panic.direct.txt).

Expected output (fixed kernel, fix.diff applied)

• run_setkey.sh 0|1|127|257: no panic; ctx.Nr=0 ek[0]=00000000 ... dk[0]=00000000 (rejected, schedules zeroed).
• run_poison.sh poison|direct: RIJNH: poison: SURVIVED Nr=0 encrypt; ct=00000000.
• run_kat.sh: 16 pass 0 fail — bit-identical to baseline (fixrun_dmesg.txt vs kat_baseline_dmesg.txt).

Artifacts

• rijndael_harness.c / rijndael_twin_tables.h — kernel rig (twin tables are a verbatim copy of the Te tables from rijndael-alg-fst.c lines 56-386,718-722)
• rijnh.c — userland driver (mmaps the guard-page layout for DEMO B)
• build.sh, run_*.sh — exact commands
• build_baseline.log / build_fixed.log / install_*.log — full kernel build logs
• kat_baseline_dmesg.txt — stock-kernel KAT + twinval control (16/16, 600/600)
• panic.setkey0.txt / panic.poison.txt / panic.direct.txt — serial-console panics
• idx_dmesg.txt / idx_run.out / idx_analysis*.txt — DF-2367 evidence (shared)
• fixrun_dmesg.txt — fixed-kernel A/B log
• fix.diff — git-apply-able fix (validated on guest; never applied to sys/ here)
• env.txt, ttables.txt — guest environment, T-table kernel addresses

DF-2368 VERDICT — no-op keyBits validation -> Nr=0 -> runaway round loop / OOB read

Status: REPRODUCED (impact: panic — kernel DoS landmine; confidence: certain) Rig: DragonFly 6.5-DEVELOPMENT x86_64, stock X86_64_GENERIC with options INVARIANTS (config line 56) and device crypto (line 299), QEMU/KVM, kernel-compiled sysctl harness (runtime kldload GPFs on this guest). Guest: DragonFly dfbsd 6.5-DEVELOPMENT #1/#2 ... x86_64 (env.txt).

What the finding claims and what was proven

Claim 1 — validation is KASSERT-only (CWE-617)

rijndaelKeySetupEnc (rijndael-alg-fst.c:734-815) validates keyBits only via KASSERT(keyBits == 128 || keyBits == 192 || keyBits == 256, ...) at lines 738-739. The public kernel KPI wrapper rijndael_set_key (rijndael-api.c:37-43) passes bits through with no check of its own.

REPRODUCED on the stock INVARIANTS kernel (kernel #1 + rig):

RIJNH: cmd="setkey 0"
RIJNH: setkey: calling real rijndael_set_key(bits=0) now (ctx pre-zeroed)
panic: Invalid key size (0).
rijndaelKeySetupEnc() at rijndaelKeySetupEnc+0x3ed
rijndaelKeySetupEnc() at rijndaelKeySetupEnc+0x3ed
rijndael_set_key() at rijndael_set_key+0x1f
rijnh_run_setkey() ... rijnh_sysctl() ...
Debugger("panic")                                    (panic.setkey0.txt)

The panic IS the assertion firing — proof that the assert is the only gate. On a production (INVARIANTS-free) build the same call path compiles the KASSERT to do { } while (0) and falls through: none of the three if (keyBits == ...) branches is taken (lines 744/764/786) and the function returns 0 at line 814. The wrapper stores ctx->Nr = 0. Note rk[0..7] are written unconditionally before the branches (lines 740-743, 762-763, 784-785), so the stored state is a partially-written schedule with Nr=0. (rijndaelKeySetupDec has the same KASSERT-only shape and inherits the fix through rijndaelKeySetupEnc.)

Claim 2 — Nr=0 makes the round loop run away and read OOB

rijndaelEncrypt (line 862) compiles the #else /* !FULL_UNROLL */ path (FULL_UNROLL is defined nowhere in the tree — verified): the loop

r = Nr >> 1;                       /* line 951: 0 when Nr==0 */
for (;;) {
    ... 4 lookups x 4 words ...    /* reads rk[4..7] */
    rk += 8;                       /* line 978: +32 bytes per iteration */
    if (--r == 0) break;           /* line 979: r was 0 -> -1, -2, ... */
    ... reads rk[0..3] ...
}

never breaks (--r starting at 0 goes negative; it would need 2^32-1 decrements to wrap to 0 again) and walks rk forward 32 bytes per iteration, past the 60-word ek/dk schedules.

REPRODUCED — the rig builds a REAL rijndael_ctx with a valid 128-bit rijndael_set_key at the end of a mapped (pre-faulted) user page followed by an unmapped page, forces ctx->Nr = 0 (byte-identical to the state the broken rijndael_set_key stores), and calls the real rijndael_encrypt (rijndael-api.c:53-57) — i.e. the full public API, not a synthetic call:

RIJNH: poison: ctx built (Nr was 10), ctx->Nr forced to 0; entering rijndael_encrypt(ctx) now
Fatal user address access from kernel mode from rijnh at ffffffff809f1c09
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x800475000
fault code             = supervisor read data, page not present
Stopped at rijndaelEncrypt+0x1d9: xorl -0x8(%rdi),%ecx   (panic.poison.txt)

The faulting VA is 0x1200 (4608) bytes past ek — i.e. the loop executed ~144 iterations and read 4128 bytes past the end of the entire 488-byte ctx (DragonFly services kernel-mode demand faults on user VA while the surrounding mapping exists, so the walk crossed the ctx page and stopped at the first truly non-present page). In the real in-kernel scenario the ctx lives in kernel memory (wlan_ccmp ctx, cryptoapi session ctx), where the same walk would consume adjacent kernel objects and only trap — if ever — at an unmapped KVA hole up to gigabytes later: exactly the claimed kernel hang/panic. Identical result via a direct rijndaelEncrypt(ek, 0, ...) call (panic.direct.txt), confirming the runaway is in the core function, not the wrapper.

Control (not a rig bug)

16/16 KAT vectors (FIPS-197 App. C.1-C.3, SP800-38A ECB, and an OpenSSL-derived extended set) PASS through the same real functions with correct encrypt+decrypt round-trip (kat_baseline_dmesg.txt); the instrumented twin used for the DF-2367 evidence matches the real function byte-exact on 600 random vectors.

Reachability honesty (who can actually hit this)

Not reachable from unprivileged userspace today — every in-tree caller pre-validates the key size:

• sys/netproto/802_11/wlan_ccmp/ieee80211_crypto_ccmp.c:130-141 — ccmp_setkey rejects wk_keylen != 16; keys arrive via privileged ioctls / association paths that fix 128-bit CCMP keys.
• sys/crypto/cryptoapi/cryptoapi.c:305-317 (aes_cbc_setkey) and :399-411 (aes_xts_setkey via aes_xts_valid_keysize_in_bits, 256/512 only) — the only cryptoapi consumer is sys/dev/disk/dm/crypt/dm_target_crypt.c (dm-crypt), whose table configuration is privileged.
• sys/crypto/rijndael/rijndael-api-fst.c:48-52 (rijndael_makeKey) validates.
• opencrypto/IPsec do NOT use this rijndael at all (AES-NI/xform path).

So the finding stands as filed: a latent DoS landmine at the kernel KPI boundary (one future caller that forgets to pre-validate turns invalid keyBits into a kernel hang/panic), Low severity, CWE-617. The guest harness reaches it only because the rig is compiled into the kernel for verification.

Privesc assessment (team directive: crypto-core class — close or flag)

CLOSED as non-privesc with reasoning: the runaway loop performs OOB reads only (round-key words are XOR-ed into on-stack cipher state; nothing OOB is written), the walked data never reaches userspace, and the terminal behavior is a fatal trap. No write primitive, no controlled pointer, no info return path — there is no escalation chain from this bug. Impact ceiling: kernel DoS.

Fix validation (A/B, same guest, same rig)

fix.diff (generated against the read-only sys/ tree; applied only inside the guest /usr/src with patch -p1; git apply --check clean on the host):

1. rijndaelKeySetupEnc/rijndaelKeySetupDec: runtime check returning -1 for keyBits not in {128,192,256} (KASSERT kept for INVARIANTS builds).
2. rijndael_set_key: rejects invalid bits — stores Nr = 0 and zeroes ek/dk (no stale schedule reuse) without calling the setup functions.
3. rijndaelEncrypt/rijndaelDecrypt: guard Nr != 10 && != 12 && != 14 -> immediate return, killing the runaway even for direct callers.

Baseline (kernel #1) vs fixed (kernel #2):

Full log: fixrun_dmesg.txt (fixed), kat_baseline_dmesg.txt (baseline). Bug inputs now rejected/clamped and all FIPS-197 vectors bit-identical — fix objective met.

Notes

• The guest was returned to the pristine with-src snapshot after verification.
• PoC sources: rijndael_harness.c (kernel rig), rijnh.c (userland driver); sha256 in verdict.json.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.