Re: git: cfb7b942bed7 - main - cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers.

On Mon, Jan 17, 2022 at 10:30:05PM +0100, Guido Falsi wrote:
> On 15/01/22 01:26, Mark Johnston wrote:
> > On Fri, Jan 14, 2022 at 10:27:12PM +0100, Guido Falsi wrote:
> >> On 11/01/22 23:38, John Baldwin wrote:
> >>> The branch main has been updated by jhb:
> >>>
> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=cfb7b942bed72cb798b869d2e36e0097dbd243b2
> >>>
> >>> commit cfb7b942bed72cb798b869d2e36e0097dbd243b2
> >>> Author:     John Baldwin <jhb@FreeBSD.org>
> >>> AuthorDate: 2022-01-11 22:18:57 +0000
> >>> Commit:     John Baldwin <jhb@FreeBSD.org>
> >>> CommitDate: 2022-01-11 22:18:57 +0000
> >>>
> >>>       cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers.
> >>>       
> >>>       Reviewed by:    markj
> >>>       Sponsored by:   The FreeBSD Foundation
> >>>       Differential Revision:  https://reviews.freebsd.org/D33531
> >>
> >> Hi,
> >>
> >> I've just updated to recent head. I have a laptop using ZFS on geli
> >> setup and now it's unable to boot.
> >>
> >> I've seen the failure starting with git revision
> >> 3284f4925f697ad7cc2aa4761ff5cf6ce98fd623 (LRO: Don't merge ACK and
> >> non-ACK packets together - 01/13/22, 17:18)
> >>
> >> it's still there with revision fe453891d7ccc8e173d9293b67f5b4608c5378dd
> >> (01/14/22 11:00:08)
> >>
> >> While a kernel from the binary snapshot downloaded from mirrors compiled
> >> from revision ac413189f53524e489c900b3cfaa80a1552875ca (vfslist.c:
> >> initialize skipvfs variable 01/05/2022) is able to boot correctly.
> >>
> >> The machine panics as soon as it tries to work with geli, this is why I
> >> am replying to this commit message. I'm not completely sure this is the
> >> commit to blame, but it sure is related.
> >>
> >> I have not been able to save the backtrace to file, but the last two
> >> calls are to:
> >>
> >> crypto_cursor_segment()
> >> swcr_encdec()
> >>
> >> so it points to the last part of this patch.
> > 
> > I think the problem is that crypto_cursor_segment() doesn't expect to be
> > called once the cursor is at the end of a buffer.  It may or may not
> > perform an invalid memory access in that case, depending on the
> > underlying buffer type.
> > 
> > Fixing it would complicate the cursor code, maybe it's better to just
> > change cryptosoft to avoid this scenario:
> 
> Is this being followed up? Ads I said this patch works for me and I'm 
> using it locally. While I'm unable to review it, as a user and 
> contributor I'm interested in the issue being fixed for good in the 
> official tree.
> 
> If discussion is already ongoing in a publicly accessible can you point 
> me to it? Thanks!

I committed it just now, after some private discussion with John.
Thanks for the report and for testing.