DF-0875 interaction observed live during DF-2663 verification (stock kernel,
first attempt with data_off == volu_size exactly). Serial console capture
(vm.sh log) from that run:

  hammer2_ondisk: "/dev/mapper/leak" zone=0 id=0 offset=0x0000000000000000 size=0x0000000010000000
  hammer2_mount: hmp=0xfffff80119a80000 pmp=0xfffff8011a220000
  HAMMER2: VOLDATA DUMP
  HAMMER2: INITIATEpEa SnPiAcN:s n
   no volume for offset 0x0000000010000000
  cpuid = 0
  Trace beginning at frame 0xfffff801199f3700
  hammer2_get_volume() at hammer2_get_volume+0x4b 0xffffffff8098726b
  hammer2_get_volume() at hammer2_get_volume+0x4b 0xffffffff8098726b
  _hammer2_io_getblk() at _hammer2_io_getblk+0x477 0xffffffff809650f7
  _hammer2_io_bread() at _hammer2_io_bread+0x17 0xffffffff80965397
  hammer2_chain_load_data() at hammer2_chain_load_data+0x2a5 0xffffffff8096f4a5
  hammer2_chain_lock() at hammer2_chain_lock+0xde 0xffffffff8096fa4e
  Debugger("panic")

Notes:
- data_off was 0x10000010 (256MB|radix16) == volu_size (0x10000000): the
  forged size check had passed on the dm device (media_size = oversized
  table), but get_volume() requires offset < offset+size strictly, so the
  known DF-0875 panic fired instead of any read.
- With an oversized forged volu_size ACCEPTED (kernel A, sysctl=1), the
  DF-0875 panic window SHRINKS (more offsets map to the volume) but any
  data_off >= volu_size still panics - the two defects compose.