=== DF-4467 baseline reproduction (unpatched) ===
uname: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026  x86_64
(crypto: software - QEMU CPU has no AESNI; dmesg shows
 "dm_target_crypt: using crypto_cipher: AES-CBC (Rijndael-128) in software")

--- RACE RUN: aes-xts-plain64 256-bit, 8 concurrent writers on disjoint
--- 4KB blocks for 25s, then 3 verification rounds of all 512 blocks ---
[setup] 512 blocks initialized (single threaded)
[race] 8 writers stopped after 25s
[CORRUPT] block 0 round 0: got 796e5d6a want 00000009
[CORRUPT] block 1 round 0: got 2513ffffffcd63 want 00000109
[CORRUPT] block 2 round 0: got 19ffffffffffffff9843 want 00000209
[CORRUPT] block 3 round 0: got 444043ffffff8f want 00000309
[result] corrupted blocks: 1413 / 512 (XTS TWEAK RACE REPRODUCED)
RC=3

--- CONTROL RUN: identical setup, no concurrent writers (control=1) ---
[setup] 512 blocks initialized (single threaded)
[result] corrupted blocks: 0 / 512 (no corruption detected)
RC=0

Interpretation: every pwrite() reported success, yet the write-then-read
round-trip returns garbage for essentially every concurrently-written
block: the ENCRYPT side used wrong XTS tweaks. The tweak state
(aes_xts_ctx.tweak) lives in the shared session context and is
re-initialized/mutated per cryptoapi_cipher_crypt() call; concurrent
dmtc_bio_encdec() loops (one per in-flight bio, on any CPU) interleave
reinit/mutation, so data blocks get encrypted under tweaks belonging to
other data units -> silent on-disk ciphertext corruption and XTS tweak
reuse across data units. The single-threaded control round-trips
perfectly, ruling out key/IV/setup errors.