[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210820125315.GB28484@gondor.apana.org.au>
Date: Fri, 20 Aug 2021 20:53:15 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Shreyansh Chouhan <chouhan.shreyansh630@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
syzbot+20191dc583eff8602d2d@...kaller.appspotmail.com
Subject: Re: [PATCH] crypto: xts_crypt() return if walk.nbytes is 0
On Fri, Aug 20, 2021 at 01:14:52PM +0200, Ard Biesheuvel wrote:
>
> In spite of that, I have a slight preference for this version, given
> that it makes it obvious that we bail on two separate conditions:
> - an error has occurred
> - no error has occurred but the resulting walk is empty
>
> Testing walk.nbytes only needlessly obfuscates the code, as we need to
> return 'err' in the end anyway.
I disagree, this is how most skcipher walkers are structured, they
never explicitly test on err and only terminate the loop when
walk->nbytes hits zero, in which case err is returned as is.
I don't see why this particular skcipher walker should deviate
from that paradigm. In fact it is exactly that deviation that
caused the bug in the first instance.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists