ABCDEFGHIJK
1
Quick note: this was just a rapid pass over every open bug that looked like encryption was involved. It is not intended to be taken as authoritative or completely well informed, just a first pass
2
Bug #StatusTitleBrief summarySeverityDifficulty
Data loss/corruption?
Dupe CountDomains touchedFirst ReportedComments
3
11679OpenZFS on Linux null pointer dereferenceThe one I understand best. It seems like there's a refcount bug with dnodes when encrypted buffers are around, such that in some unusual case (I suspect it's at least triggerable with some memory fragmentation edge case, based on seeing that happen under heavy mem frag on non-x86 platforms), we wind up with a buffer in a header that thinks it has refcount 0 but it's still referenced somewhere, it gets freed and reallocated, and then eventually either it gets destroyed by one of the references dropping it and then the other tries accessing it and a panic or corruption ensues.5Quite hardSometimes6ARC, send|recv0.8.0-rc[mumble]
4
10523ClosedRaw send on encrypted datasets does not work when copying snapshots backsend -w from src to dst; make changes and new snaps on dst; try to incrementally recv on src again, src dataset is now unmountable until rolled back3?Yes4send|recv???Someone tried patching it once, but found that the fix did not account for encryption setups that were never in stable releases, so it was backed out.
5
8758Opencannot send raw incremental send after creation of snapshot at remote endsend -w src@snap1 | recv dst;snap dst@newsnap breaks send -w -i src@snap1 src@snap2 until dst@newsnap is destroyed2?No1send|recv0.8.0-rc5
6
11433Openassertion failure: bad sa_magic in zpl_get_file_info()Looks like somehow some bad metadata winds up in memory or on disk from userobj_accounting - the reporters so far have all also been using encryption, unclear if related2????1userobj_accounting2.0.0
7
8722OpenNULL dereference receiving (non-raw) to encrypted datasetNULL in zio_crypt_copy_dnode_bonus on recv - suspect it's earliest reported instance of #11679dupeSee #11679dupe0ARC,send|recv0.8.0-rc4
8
10275OpenCannot zfs recv raw incremental encrypted stream after snapshot on destinationDupe of #8758dupeSee #8758dupe0send|recv0.8.3
9
10603Openudev not creating device file for cloned zvolSeems simple. May be fixed by #12271 already?2?No0clones0.8.4
10
10787OpenOn zfs recv: ASSERT at libzfs_sendrecv.c:2798:recv_fix_encryption_hierarchy()Seems like a flaw in send/recv with (non-encrypted datasets, using -w, using -h)? May no longer be relevant?1Probably lowNo0send|recv (userland)0.8.4
11
11294ClosedHEAD issues mounting encrypted datasets/corrupting metadataThe reason a patch got reverted - encrypted dataset with odd combination of configuration never present in a shipped release broke a bugfix, so it got reverted and not yet fixed again.?
Difficult, apparently.
Inaccessible, not lost0git d1d47691c
12
11405OpenPANIC when sending encrypted dataset with the raw flagLike it says on the tin. Appears to be TrueNAS-specific patch caused0???No02.0.0*Another TrueNAS SCALE report.
13
11490OpenVERIFY(zfs_refcount_count(&dck->dck_holds) == 0) failed PANIC at dsl_crypt.c:503:dsl_crypto_key_free()Maybe a missing lock that got stepped on during recv? I don't know this portion of the code.3????0send|recv2.0.0*It's also on TrueNAS SCALE, may or may not be relevant to upstream?
14
11688Openpermanent errors (ereport.fs.zfs.authentication) reported after syncoid snapshot/send workload#11679 with [witticism], I suspect - random corruption in encrypted snapshots sure fits the bill, though I can't be certain until it's fixed and we see if it still happens...dupeSee #11679dupe0send|recv2.0.3aerusso may have a different opinion than me, but I'd probably suspect many instances of mysterious corruption on-disk when encryption (esp. encrypted send/recv) is involved of being #11679 until proven otherwise
15
11983ClosedInput/Output Error when sending an encrypted incremental dataset back to it's source#10523 with metal paint and a chip on its shoulderdupesee #10523dupe0send|recv2.0.4
16
12000OpenRepair encryption hierarchy of 'send -Rw | recv -d' datasets that do not bring their encryption rootSeems like #10523 in a dollar store wig, possibly; comes with a reproducer!dupesee #10523dupe0send|recv0.8.3
17
12001OpenZFS hangs on kernel error: VERIFY3(0 == dmu_bonus_hold_by_dnodeSame as #12732, probably just #11679dupeSee #11679dupe0send|recv2.0.3
18
12014OpenZFS corruption related to snapshots post-2.0.x upgrade#11679 with a bad wigdupeSee #11679dupe02.0.3
19
12123OpenAfter replicating the encrypted dataset and perform key inheritance on the target dataset (change-key -i), next incremental snapshot will break the dataset \ volume.As the name says - changing child key after raw recving a tree of encrypted datasets breaks mounting in some conditions - probably the same flavor as 10523 et al5see #10523Sometimes0send|recv, key management2.0.4Higher rating because in this case you may explicitly no longer have the older snapshots anywhere any more, while 10523 is explicitly sending from the active to a redundant copy
20
12270OpenSPL Panic during ZFS ReceiveSame as #12732 which I think are both just #11679 in a trenchcoat when you lose the race in a different point in the codedupeSee #11679dupe0ARC, send|recv2.0.4
21
12418Openzfs mount fails silently on encrypted datasetSeems similar in concept to #12614 - change-key on a child seems to break mounting parent and child, though at least the child can be manually triggered to mount later4???Sometimes0key managementgit 1b50749ce9 (July 2021)Unclear if the original wrapping key is obliterated or what. Presumably if the wrapping keys involved are =prompt you could just regenerate them after writing tools to hackily bypass checks and just rewrite the metadata.
22
12439OpenPANIC at dsl_crypt.c:2441:dsl_crypto_populate_key_nvlist()Giving send -w a whole filesystem not just a snapshot can make it panic for some datasets, but not always? Sample pool which reproduces is enclosed.1???No0send|recv2.0.3Rated 1 because it basically only happens if you do something dumb; if someone has a real use case that's not user error where it does this, I'd bump it up.
23
12594ClosedSometimes raw send on encrypted datasets does not work when copying snapshots back#10523 with a fake mustache; has a reproducer script!dupesee #10523dupe0send|recv2.1.1
24
12614OpenReplicating encrypted child dataset + change-key + incremental receive overwrites master key of replica, causes permission denied on remountzfs send -Rw src/encrypted@1 | zfs recv dst/encrypted; zfs change-key dst/encrypted;zfs send -iw src/encrypted/a@{1,2} | zfs recv dst/encrypted/a; will overwrite the new wrapping key on disk with the old one, and away goes your data next time you unmount and the key is no longer loaded5???Sometimes0send|recv, key management2.0.5Attila remarked that he thought you'd need to just block recvs in that case, rather than handling it better/just ignoring the received wrapping key if it's been change-key'd in the interim. Unclear if that's a hard restriction for reasons not obvious to me. Unclear to me why encrypted incrementals need to send that at all, ever, much less every time...or why the receiver can't just ignore it or handle it by actually doing a proper change-key.
25
12659OpenKernel panic VERIFY3(sa.sa_magic == SA_MAGIC) faileddupe of 11433dupesee #11433dupe0
userobj_accounting, send|recv
2.0.6
26
12659OpenUnable to receive encrypted raw sendreceiver erroring with "must upgrade kernel modules", but both sides are 2.0.6, so ???3???No0send|recv2.0.6
27
12732OpenPANIC at dmu_recv.c on receiving snapshot to encrypted file system#11679 again, I believedupeSee #11679dupe0send|recv2.0.6
28
12785OpenKernel panic on incremental send/recv between two encrypted datasets on the same pool, dest is using zstd-19#12001 which I suspect may just be #11679dupeSee #11679dupe0send|recv2.0.3
29
13067ClosedRaw sending to a pool with larger ashift results in unmountable filesystemFamily of 12762?PR openI think so0send|recv, ashift2.1.2
30
13038ClosedFreeBSD: zfskeys_enable: encryption key not loaded for a file system within a pool that imports automatically at startup1???no0git ???
31
13033ClosedCannot zfs receive unencrypted dataset as a child of encrypted dataset ('cannot receive new filesystem stream: inherited key must be loaded')1???no0
32
12869Openztest fails in l2arc_apply_transforms comparing calculated MAC1??????0ztestgit ???
33
9046Closedpanic in abd_verify while running zpool_create_crypt_combos testOnce again, it's just 11679, poor and unfixed.dupeSee #11679???0
34
13445OpenZFS Receive of encrypted incremental data stream causes a PANICRelative of 13067? Unclear if a problem on 2.1.4+1??????0send|recv2.1.2
35
13477OpenPANIC at zfs_znode.c zfs_znode_sa_init() - Regression in closed issue #10971? Relative of 11679, or another SA-related panic????2.1.4
36
13491OpenPanic while receiving and encrypting datasetYeah no that stack trace is 100% 11679dupeSee #116790send|recv2.1.2
37
13521OpenFilesystem can not be mounted: Input/output errorMaybe just the change-key bug, maybe #13709, who knows30send|recv0.8.3-ubuntumumble
38
13859OpenPermanent errors have been detected in the following files with clean scrub and no other errors
dupesee #137090
39
13709OpenI/O error on mounting encrypt fs after upgradingoh it's just #11294 againdupesee #112942send|recv2.1.3
40
14083OpenCannot Decrypt Dataset(s) Under v2.1.6 Created Using v2.1.0Appears to have been a macOS-specific bug that just resembled 1370910send|recv2.1.6
41
13926Openkernel: PANIC <pool> blkptr at <address> has invalid CHECKSUM 0
42
13922Open[sparc64] Encrypted datasets erroring with "Unable to handle kernel NULL pointer dereference errors"
43
13699Openper dataset large_block feature detection not reliable when sending raw encrypted large block ds
44
13634OpenCannot read, write or delete corrupted directory
45
13561Openzpool_import_errata4 PANICs slow sparc64 machine
46
14330OpenAnother encryption bug: "unencrypted block in encrypted object set"Seems you can wind up with an embedded_data record on an encrypted DS.1
??? Haven't been able to reproduce it...
no0send|recv2.1.4Easy to reproduce if you patch some conditionals out of the code, haven't found a reproducer that doesn't involve that...
47
14245OpenReceiving incremental stream causes process to hang
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100