A | B | C | D | E | F | G | H | I | J | K | |
---|---|---|---|---|---|---|---|---|---|---|---|
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 # | Status | Title | Brief summary | Severity | Difficulty | Data loss/corruption? | Dupe Count | Domains touched | First Reported | Comments |
3 | 11679 | Open | ZFS on Linux null pointer dereference | The 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. | 5 | Quite hard | Sometimes | 6 | ARC, send|recv | 0.8.0-rc[mumble] | |
4 | 10523 | Closed | Raw send on encrypted datasets does not work when copying snapshots back | send -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 back | 3 | ? | Yes | 4 | send|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 | 8758 | Open | cannot send raw incremental send after creation of snapshot at remote end | send -w src@snap1 | recv dst;snap dst@newsnap breaks send -w -i src@snap1 src@snap2 until dst@newsnap is destroyed | 2 | ? | No | 1 | send|recv | 0.8.0-rc5 | |
6 | 11433 | Open | assertion 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 related | 2 | ??? | ? | 1 | userobj_accounting | 2.0.0 | |
7 | 8722 | Open | NULL dereference receiving (non-raw) to encrypted dataset | NULL in zio_crypt_copy_dnode_bonus on recv - suspect it's earliest reported instance of #11679 | dupe | See #11679 | dupe | 0 | ARC,send|recv | 0.8.0-rc4 | |
8 | 10275 | Open | Cannot zfs recv raw incremental encrypted stream after snapshot on destination | Dupe of #8758 | dupe | See #8758 | dupe | 0 | send|recv | 0.8.3 | |
9 | 10603 | Open | udev not creating device file for cloned zvol | Seems simple. May be fixed by #12271 already? | 2 | ? | No | 0 | clones | 0.8.4 | |
10 | 10787 | Open | On 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? | 1 | Probably low | No | 0 | send|recv (userland) | 0.8.4 | |
11 | 11294 | Closed | HEAD issues mounting encrypted datasets/corrupting metadata | The 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 lost | 0 | git d1d47691c | ||
12 | 11405 | Open | PANIC when sending encrypted dataset with the raw flag | Like it says on the tin. Appears to be TrueNAS-specific patch caused | 0 | ??? | No | 0 | 2.0.0* | Another TrueNAS SCALE report. | |
13 | 11490 | Open | VERIFY(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 | ??? | ? | 0 | send|recv | 2.0.0* | It's also on TrueNAS SCALE, may or may not be relevant to upstream? |
14 | 11688 | Open | permanent 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... | dupe | See #11679 | dupe | 0 | send|recv | 2.0.3 | aerusso 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 | 11983 | Closed | Input/Output Error when sending an encrypted incremental dataset back to it's source | #10523 with metal paint and a chip on its shoulder | dupe | see #10523 | dupe | 0 | send|recv | 2.0.4 | |
16 | 12000 | Open | Repair encryption hierarchy of 'send -Rw | recv -d' datasets that do not bring their encryption root | Seems like #10523 in a dollar store wig, possibly; comes with a reproducer! | dupe | see #10523 | dupe | 0 | send|recv | 0.8.3 | |
17 | 12001 | Open | ZFS hangs on kernel error: VERIFY3(0 == dmu_bonus_hold_by_dnode | Same as #12732, probably just #11679 | dupe | See #11679 | dupe | 0 | send|recv | 2.0.3 | |
18 | 12014 | Open | ZFS corruption related to snapshots post-2.0.x upgrade | #11679 with a bad wig | dupe | See #11679 | dupe | 0 | 2.0.3 | ||
19 | 12123 | Open | After 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 al | 5 | see #10523 | Sometimes | 0 | send|recv, key management | 2.0.4 | Higher 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 | 12270 | Open | SPL Panic during ZFS Receive | Same as #12732 which I think are both just #11679 in a trenchcoat when you lose the race in a different point in the code | dupe | See #11679 | dupe | 0 | ARC, send|recv | 2.0.4 | |
21 | 12418 | Open | zfs mount fails silently on encrypted dataset | Seems 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 later | 4 | ??? | Sometimes | 0 | key management | git 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 | 12439 | Open | PANIC 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 | ??? | No | 0 | send|recv | 2.0.3 | Rated 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 | 12594 | Closed | Sometimes raw send on encrypted datasets does not work when copying snapshots back | #10523 with a fake mustache; has a reproducer script! | dupe | see #10523 | dupe | 0 | send|recv | 2.1.1 | |
24 | 12614 | Open | Replicating encrypted child dataset + change-key + incremental receive overwrites master key of replica, causes permission denied on remount | zfs 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 loaded | 5 | ??? | Sometimes | 0 | send|recv, key management | 2.0.5 | Attila 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 | 12659 | Open | Kernel panic VERIFY3(sa.sa_magic == SA_MAGIC) failed | dupe of 11433 | dupe | see #11433 | dupe | 0 | userobj_accounting, send|recv | 2.0.6 | |
26 | 12659 | Open | Unable to receive encrypted raw send | receiver erroring with "must upgrade kernel modules", but both sides are 2.0.6, so ??? | 3 | ??? | No | 0 | send|recv | 2.0.6 | |
27 | 12732 | Open | PANIC at dmu_recv.c on receiving snapshot to encrypted file system | #11679 again, I believe | dupe | See #11679 | dupe | 0 | send|recv | 2.0.6 | |
28 | 12785 | Open | Kernel 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 #11679 | dupe | See #11679 | dupe | 0 | send|recv | 2.0.3 | |
29 | 13067 | Closed | Raw sending to a pool with larger ashift results in unmountable filesystem | Family of 12762? | PR open | I think so | 0 | send|recv, ashift | 2.1.2 | ||
30 | 13038 | Closed | FreeBSD: zfskeys_enable: encryption key not loaded for a file system within a pool that imports automatically at startup | 1 | ??? | no | 0 | git ??? | |||
31 | 13033 | Closed | Cannot zfs receive unencrypted dataset as a child of encrypted dataset ('cannot receive new filesystem stream: inherited key must be loaded') | 1 | ??? | no | 0 | ||||
32 | 12869 | Open | ztest fails in l2arc_apply_transforms comparing calculated MAC | 1 | ??? | ??? | 0 | ztest | git ??? | ||
33 | 9046 | Closed | panic in abd_verify while running zpool_create_crypt_combos test | Once again, it's just 11679, poor and unfixed. | dupe | See #11679 | ??? | 0 | |||
34 | 13445 | Open | ZFS Receive of encrypted incremental data stream causes a PANIC | Relative of 13067? Unclear if a problem on 2.1.4+ | 1 | ??? | ??? | 0 | send|recv | 2.1.2 | |
35 | 13477 | Open | PANIC 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 | 13491 | Open | Panic while receiving and encrypting dataset | Yeah no that stack trace is 100% 11679 | dupe | See #11679 | 0 | send|recv | 2.1.2 | ||
37 | 13521 | Open | Filesystem can not be mounted: Input/output error | Maybe just the change-key bug, maybe #13709, who knows | 3 | 0 | send|recv | 0.8.3-ubuntumumble | |||
38 | 13859 | Open | Permanent errors have been detected in the following files with clean scrub and no other errors | dupe | see #13709 | 0 | |||||
39 | 13709 | Open | I/O error on mounting encrypt fs after upgrading | oh it's just #11294 again | dupe | see #11294 | 2 | send|recv | 2.1.3 | ||
40 | 14083 | Open | Cannot Decrypt Dataset(s) Under v2.1.6 Created Using v2.1.0 | Appears to have been a macOS-specific bug that just resembled 13709 | 1 | 0 | send|recv | 2.1.6 | |||
41 | 13926 | Open | kernel: PANIC <pool> blkptr at <address> has invalid CHECKSUM 0 | ||||||||
42 | 13922 | Open | [sparc64] Encrypted datasets erroring with "Unable to handle kernel NULL pointer dereference errors" | ||||||||
43 | 13699 | Open | per dataset large_block feature detection not reliable when sending raw encrypted large block ds | ||||||||
44 | 13634 | Open | Cannot read, write or delete corrupted directory | ||||||||
45 | 13561 | Open | zpool_import_errata4 PANICs slow sparc64 machine | ||||||||
46 | 14330 | Open | Another 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... | no | 0 | send|recv | 2.1.4 | Easy to reproduce if you patch some conditionals out of the code, haven't found a reproducer that doesn't involve that... |
47 | 14245 | Open | Receiving 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 |