On Thu, May 28, 2020 at 8:30 PM John Baldwin <j...@freebsd.org> wrote:
> On 5/28/20 2:13 AM, Marcin Wojtas wrote: > > Author: mw > > Date: Thu May 28 09:13:20 2020 > > New Revision: 361583 > > URL: https://svnweb.freebsd.org/changeset/base/361583 > > > > Log: > > Change return types of hash update functions in SHA-NI > > > > r359374 introduced crypto_apply function which takes as argument a > function pointer > > that is expected to return an int, however aesni hash update functions > > return void. > > Because of that the function pointer passed was simply cast with > > its return value changed. > > This resulted in undefined behavior, in particular when mbuf is used, > (ipsec) > > m_apply checks return value of function pointer passed to it > > and in our case bogusly fails after calculating hash of the first mbuf > > in chain. > > Fix it by changing signatures of sha update routines in aesni and > > dropping the casts. > > Hmm, I missed one nit in the review. r359374 didn't introduce > crypto_apply, it just changed some of the arguments arguments (crp > instead of crp_buf and crp_flags). This fix needs to be MFC'd to 12 > as well since the issue with the return type is also present there. > > -- > John Baldwin > Whoops, I should have read the diff more carefully. Before debugging I did some bisecting and found r359374 as the culprit. In r359374 return types of intel_sha256_update and intel_sha1_update were changed to void which is the root cause. SHA-NI on stable/12 should work just fine right now. Sorry for the noise. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"