svn commit: r361583 - head/sys/crypto/aesni

[John Baldwin]

On 5/29/20 12:46 AM, Kornel Dulęba wrote:
> On Thu, May 28, 2020 at 8:30 PM John Baldwin <jhb at 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.

Hmm, I did change the return types, oof.  Thanks for tracking this down.

-- 
John Baldwin