Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH v2] crypto: ccm - avoid negative wrapping of integers
@ 2021-07-26 17:01 Jordy Zomer
  2021-07-26 17:18 ` Eric Biggers
  0 siblings, 1 reply; 4+ messages in thread
From: Jordy Zomer @ 2021-07-26 17:01 UTC (permalink / raw)
  To: netdev
  Cc: Greg Kroah-Hartman, Jordy Zomer, Herbert Xu, David S. Miller,
	linux-crypto, linux-kernel

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@pwning.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;
 
-- 
2.27.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] crypto: ccm - avoid negative wrapping of integers
  2021-07-26 17:01 [PATCH v2] crypto: ccm - avoid negative wrapping of integers Jordy Zomer
@ 2021-07-26 17:18 ` Eric Biggers
  2021-07-27  5:36   ` Greg Kroah-Hartman
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Biggers @ 2021-07-26 17:18 UTC (permalink / raw)
  To: Jordy Zomer
  Cc: netdev, Greg Kroah-Hartman, Herbert Xu, David S. Miller,
	linux-crypto, linux-kernel

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@pwning.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.
Also please line wrap your commit message.

- Eric

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] crypto: ccm - avoid negative wrapping of integers
  2021-07-26 17:18 ` Eric Biggers
@ 2021-07-27  5:36   ` Greg Kroah-Hartman
  2021-07-27  5:38     ` Greg Kroah-Hartman
  0 siblings, 1 reply; 4+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-27  5:36 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Jordy Zomer, netdev, Herbert Xu, David S. Miller, linux-crypto,
	linux-kernel

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@pwning.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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] crypto: ccm - avoid negative wrapping of integers
  2021-07-27  5:36   ` Greg Kroah-Hartman
@ 2021-07-27  5:38     ` Greg Kroah-Hartman
  0 siblings, 0 replies; 4+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-27  5:38 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Jordy Zomer, netdev, Herbert Xu, David S. Miller, linux-crypto,
	linux-kernel

On Tue, Jul 27, 2021 at 07:36:56AM +0200, Greg Kroah-Hartman wrote:
> 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@pwning.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?

And part of this effort is to make it obvious that there is no overflow
happening, to allow tools to check this type of thing.  When you have to
work backwards long long ways like this, it makes automatic auditing
almost impossible, along with manual auditing like I tried to do :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-07-27  5:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-26 17:01 [PATCH v2] crypto: ccm - avoid negative wrapping of integers Jordy Zomer
2021-07-26 17:18 ` Eric Biggers
2021-07-27  5:36   ` Greg Kroah-Hartman
2021-07-27  5:38     ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).