[Bug 259093] [zfs] [panic] NULL pointer dereference on "zfs send --raw" of encrypted filesystem.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259093

            Bug ID: 259093
           Summary: [zfs] [panic] NULL pointer dereference on "zfs send
                    --raw" of encrypted filesystem.
           Product: Base System
           Version: 13.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: peterj@FreeBSD.org

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).

-- 
You are receiving this mail because:
You are the assignee for the bug.