Date: Thu, 28 May 2020 11:29:55 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Marcin Wojtas <mw@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r361583 - head/sys/crypto/aesni Message-ID: <9fdb00be-00e0-6aff-51ad-7a84b4215a4e@FreeBSD.org> In-Reply-To: <202005280913.04S9DKWv013795@repo.freebsd.org> References: <202005280913.04S9DKWv013795@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9fdb00be-00e0-6aff-51ad-7a84b4215a4e>