Consistent panic with "zfs send --raw"

I'm trying to replicate a filesystem with native encrytion enabled and
am getting a consistent NULL pointer dereference panic.  I'm running
13-stable fdbbd118faab but the code is identical in HEAD.

Looking at the backtrace:
#16 <signal handler called>
#17 dmu_dump_write (dscp=dscp@entry=0xfffffe02501abc30, type=<optimized out>, 
    object=<optimized out>, offset=<optimized out>, offset@entry=0, 
    lsize=<optimized out>, lsize@entry=131072, psize=psize@entry=131072, 
    bp=0x0, data=0xfffffe02d94a6000)
    at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:493
#18 0xffffffff80410a3c in do_dump (dscp=dscp@entry=0xfffffe02501abc30, 
    range=range@entry=0xfffff805fd82d900)
    at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:1016
#19 0xffffffff8040ead3 in dmu_send_impl (dspp=<optimized out>, 
    dspp@entry=0xfffffe02501abdf0)
    at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:2537
#20 0xffffffff8040d8fd in dmu_send_obj (pool=<optimized out>, 
    pool@entry=0xfffffe02d3b61000 "tank/compat@20210604bu", tosnap=10690, 
    fromsnap=11065, embedok=<optimized out>, embedok@entry=1, 
    large_block_ok=<optimized out>, large_block_ok@entry=2, 
    compressok=<optimized out>, compressok@entry=4, rawok=8, savedok=0, 
    outfd=1, off=0xfffffe02501ac070, dsop=0xfffffe02501ac058)
    at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:2695

dmu_send.c:493 is "ASSERT(!BP_IS_EMBEDDED(bp));" which dereferences bp
with no checks for NULL, whereas dmu_send.c:1016 explicitly passes NULL
to dmu_dump_write() as bp.  This is obviously a bug somewhere.

Looking at the comment at lines 1006-1008, it seems the code expects
that raw sends will always have large block sends enabled, avoiding the
problematic code block.  And zfs-send(8) says that --raw implies
--large-block if the source is not encrypted.  But even if I explicitly
specify --large-block then the code panics in the same way.  (And
--large-block as on option doesn't actually make sense with --raw
because the send stream must match what's on local disk by definition).

At this point, I'm not sure what the correct fix is.

-- 
Peter Jeremy