I added a commit to this PR which fixes the issue with `Invalid dnode block MAC`.
In blocks of dnodes, only the bonus buffers are encrypted. If there are no bonus buffers (which is always the case with ZVOLs), then the amount of data to decrypt will be 0, but we still want to go through the decryption routines for the MAC validation (the MAC covers more than just the bonus buffers). The problem is that `ccm_init_ctx()` tries to allocate "the amount of encrypted data" which is zero, but `kmem_alloc(0)` returns NULL, which `ccm_init_ctx()` interprets as an allocation failure, so it fails the decrypt operation with `CRYPTO_HOST_MEMORY`. On ZoL, the problem doesn't occur because this call to `kmem_alloc()` was changed to `vmem_alloc()`. The fix is for `ccm_init_ctx()` to only try to allocate (and check for an error from allocation) if we have a nonzero length. I checked for similar uses of kmem_alloc(length) in `usr/src/common/crypto` and didn't find any. I also made a change in `crypto_uio_data()` which fixes a mismerge from the original ZoL crypto commit (and is superficially similar to the bug but didn't actually fix it). @lundman Be sure to pull down my commit before you rebase / force push to your github branch. @GernotS I wasn't able to reproduce the NULL pointer dereference when using L2ARC, but it's very possible that is due to improper error handling of this same spurious decryption error. Could you run your L2ARC test again with this fix and let me know if it works now? @tcaputi said he'd bring this fix to ZoL - Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/489#issuecomment-375717708 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T91797982fdd5b7d9-M10542107ffda1912eb171371 Delivery options: https://openzfs.topicbox.com/groups
