lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YP+beE4NGUCDIQHR@kroah.com>
Date:   Tue, 27 Jul 2021 07:36:56 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Jordy Zomer <jordy@...ing.systems>, netdev@...r.kernel.org,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] crypto: ccm - avoid negative wrapping of integers

On Mon, Jul 26, 2021 at 10:18:47AM -0700, Eric Biggers wrote:
> On Mon, Jul 26, 2021 at 07:01:20PM +0200, Jordy Zomer wrote:
> > Set csize to unsigned int to avoid it from wrapping as a negative number (since format input sends an unsigned integer to this function). This would also result in undefined behavior in the left shift when msg len is checked, potentially resulting in a buffer overflow in the memcpy call.
> > 
> > Signed-off-by: Jordy Zomer <jordy@...ing.systems>
> > ---
> > To address was corrected, and ccm was added to the topic to indicate that this is just for ccm.
> > 
> >  crypto/ccm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/crypto/ccm.c b/crypto/ccm.c
> > index 6b815ece51c6..e14201edf9db 100644
> > --- a/crypto/ccm.c
> > +++ b/crypto/ccm.c
> > @@ -66,7 +66,7 @@ static inline struct crypto_ccm_req_priv_ctx *crypto_ccm_reqctx(
> >  	return (void *)PTR_ALIGN((u8 *)aead_request_ctx(req), align + 1);
> >  }
> >  
> > -static int set_msg_len(u8 *block, unsigned int msglen, int csize)
> > +static int set_msg_len(u8 *block, unsigned int msglen, unsigned int csize)
> >  {
> >  	__be32 data;
> 
> This isn't necessarily a bad change, but the value of csize is clearly in
> [1, 256] if you read format_input(), and in fact is in [2, 8] if you read the
> whole file, so please don't claim this is actually fixing anything, as it's not.

Oh that was not obvious at all, I looked at that for a long time and
missed the place where this was checked earlier.  Perhaps just make
csize here a u8 and that would take away all question about what is
happening?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ