Re: [PATCH] Potential NULL pointer deference in drbg_ctr_df

Re: [PATCH] Potential NULL pointer deference in drbg_ctr_df

[Herbert Xu]

On Sat, Jun 21, 2014 at 02:26:29PM +0200, Stephan Mueller wrote:
> The handling of additional input data / personalization string data may
> be subject to a NULL pointer deference for the CTR DRBG. The
> caller-provided data may be NULL which must be caught by the DRBG.
> 
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
>  crypto/drbg.c | 23 +++++++++++++----------
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/crypto/drbg.c b/crypto/drbg.c
> index faaa2ce..8e7c302 100644
> --- a/crypto/drbg.c
> +++ b/crypto/drbg.c
> @@ -513,17 +513,20 @@ static int drbg_ctr_df(struct drbg_state *drbg,
>  	drbg_string_fill(&S2, L_N, sizeof(L_N));
>  	drbg_string_fill(&S4, pad, padlen);
>  	S1.next = &S2;
> -	S2.next = addtl;
>  
> -	/*
> -	 * splice in addtl between S2 and S4 -- we place S4 at the end of the
> -	 * input data chain
> -	 */
> -	tempstr = addtl;
> -	for (; NULL != tempstr; tempstr = tempstr->next)
> -		if (NULL == tempstr->next)
> -			break;
> -	tempstr->next = &S4;
> +	if (NULL == addtl) {
> +		S2.next = &S4;
> +	} else {
> +		/*
> +		 * splice in addtl between S2 and S4 -- we place S4 at the end
> +		 * of the input data chain
> +		 */
> +		S2.next = addtl;
> +		tempstr = addtl;
> +		while (tempstr->next)
> +			tempstr = tempstr->next;
> +		tempstr->next = &S4;

You've still got exactly the same NULL dereference.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [cryptodev:master 9/28] crypto/drbg.c:526 drbg_ctr_df() error: we previously assumed 'tempstr' could be null (see line 523)

[Herbert Xu]

On Sat, Jun 21, 2014 at 02:45:33PM +0200, Stephan Mueller wrote:
> Am Freitag, 20. Juni 2014, 23:24:18 schrieb kbuild test robot:
> 
> Hi,
> 
> first of all, thanks for the information. As you have seen, I created a patch 
> covering your comments on the NULL pointer handling.
> > 
> > The kernel also provides standard linked list features and you should
> > consider using those instead of rolling your own.
> 
> There is a reason for this approach: the very same code (with exception of the 
> interface code part) is also available for libgcrypt -- see [1] and gcrypt-
> devel. I did not want to have different code, because any bug fix relevant to 
> the one implementation is also important to the other. Thus, I feel that it is 
> beneficial to use the linked list feature as implemented in the current DRBG.
> 
> [1] http://www.chronox.de/drbg.html

This is unacceptable.  We are not going to add crap to the kernel
just because the same crap exists elsewhere.

Please fix this or I will be reverting your patches.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Potential NULL pointer deference in drbg_ctr_df

[Dan Carpenter]

On Wed, Jun 25, 2014 at 05:06:46PM +0800, Herbert Xu wrote:
> On Sat, Jun 21, 2014 at 02:26:29PM +0200, Stephan Mueller wrote:
> > The handling of additional input data / personalization string data may
> > be subject to a NULL pointer deference for the CTR DRBG. The
> > caller-provided data may be NULL which must be caught by the DRBG.
> > 
> > Reported-by: kbuild test robot <fengguang.wu@intel.com>


Oh, huh.  This bug was actually reported by me but I forgot to change
the from header and apparently my smtp server allows me to send emails
as if I work for Intel.  :P

Fengguang is much nicer than I am.  :P

> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> > ---
> >  crypto/drbg.c | 23 +++++++++++++----------
> >  1 file changed, 13 insertions(+), 10 deletions(-)
> > 
> > diff --git a/crypto/drbg.c b/crypto/drbg.c
> > index faaa2ce..8e7c302 100644
> > --- a/crypto/drbg.c
> > +++ b/crypto/drbg.c
> > @@ -513,17 +513,20 @@ static int drbg_ctr_df(struct drbg_state *drbg,
> >  	drbg_string_fill(&S2, L_N, sizeof(L_N));
> >  	drbg_string_fill(&S4, pad, padlen);
> >  	S1.next = &S2;
> > -	S2.next = addtl;
> >  
> > -	/*
> > -	 * splice in addtl between S2 and S4 -- we place S4 at the end of the
> > -	 * input data chain
> > -	 */
> > -	tempstr = addtl;
> > -	for (; NULL != tempstr; tempstr = tempstr->next)
> > -		if (NULL == tempstr->next)
> > -			break;
> > -	tempstr->next = &S4;
> > +	if (NULL == addtl) {
> > +		S2.next = &S4;
> > +	} else {
> > +		/*
> > +		 * splice in addtl between S2 and S4 -- we place S4 at the end
> > +		 * of the input data chain
> > +		 */
> > +		S2.next = addtl;
> > +		tempstr = addtl;
> > +		while (tempstr->next)
> > +			tempstr = tempstr->next;
> > +		tempstr->next = &S4;
> 
> You've still got exactly the same NULL dereference.

I was offline for a bit so I'm coming into this late.  It's weird that
Stephan isn't defending his patch but it looks ok to me...

regards,
dan carpenter

Re: [PATCH] Potential NULL pointer deference in drbg_ctr_df

[Stephan Mueller]

Am Freitag, 4. Juli 2014, 13:50:03 schrieb Dan Carpenter:

Hi Dan,

> On Wed, Jun 25, 2014 at 05:06:46PM +0800, Herbert Xu wrote:
> > On Sat, Jun 21, 2014 at 02:26:29PM +0200, Stephan Mueller wrote:
> > > The handling of additional input data / personalization string data may
> > > be subject to a NULL pointer deference for the CTR DRBG. The
> > > caller-provided data may be NULL which must be caught by the DRBG.
> > > 
> > > Reported-by: kbuild test robot <fengguang.wu@intel.com>
> 
> Oh, huh.  This bug was actually reported by me but I forgot to change
> the from header and apparently my smtp server allows me to send emails
> as if I work for Intel.  :P
> 
> Fengguang is much nicer than I am.  :P

Too late, your colleague's name is now in the patches ;-)
> 
> > > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> > > ---
> > > 
> > >  crypto/drbg.c | 23 +++++++++++++----------
> > >  1 file changed, 13 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/crypto/drbg.c b/crypto/drbg.c
> > > index faaa2ce..8e7c302 100644
> > > --- a/crypto/drbg.c
> > > +++ b/crypto/drbg.c
> > > @@ -513,17 +513,20 @@ static int drbg_ctr_df(struct drbg_state *drbg,
> > > 
> > >  	drbg_string_fill(&S2, L_N, sizeof(L_N));
> > >  	drbg_string_fill(&S4, pad, padlen);
> > >  	S1.next = &S2;
> > > 
> > > -	S2.next = addtl;
> > > 
> > > -	/*
> > > -	 * splice in addtl between S2 and S4 -- we place S4 at the end of the
> > > -	 * input data chain
> > > -	 */
> > > -	tempstr = addtl;
> > > -	for (; NULL != tempstr; tempstr = tempstr->next)
> > > -		if (NULL == tempstr->next)
> > > -			break;
> > > -	tempstr->next = &S4;
> > > +	if (NULL == addtl) {
> > > +		S2.next = &S4;
> > > +	} else {
> > > +		/*
> > > +		 * splice in addtl between S2 and S4 -- we place S4 at the end
> > > +		 * of the input data chain
> > > +		 */
> > > +		S2.next = addtl;
> > > +		tempstr = addtl;
> > > +		while (tempstr->next)
> > > +			tempstr = tempstr->next;
> > > +		tempstr->next = &S4;
> > 
> > You've still got exactly the same NULL dereference.
> 
> I was offline for a bit so I'm coming into this late.  It's weird that
> Stephan isn't defending his patch but it looks ok to me...

It has been clarified in a later email that there was no NULL pointer after 
all. I erroneously sent this message and initially missed the check that 
guards against the NULL pointer.
> 
> regards,
> dan carpenter


-- 
Ciao
Stephan

Re: [PATCH] Potential NULL pointer deference in drbg_ctr_df

[Fengguang Wu]

On Sat, Jul 05, 2014 at 02:00:15AM +0200, Stephan Mueller wrote:
> Am Freitag, 4. Juli 2014, 13:50:03 schrieb Dan Carpenter:
> 
> Hi Dan,
> 
> > On Wed, Jun 25, 2014 at 05:06:46PM +0800, Herbert Xu wrote:
> > > On Sat, Jun 21, 2014 at 02:26:29PM +0200, Stephan Mueller wrote:
> > > > The handling of additional input data / personalization string data may
> > > > be subject to a NULL pointer deference for the CTR DRBG. The
> > > > caller-provided data may be NULL which must be caught by the DRBG.
> > > > 
> > > > Reported-by: kbuild test robot <fengguang.wu@intel.com>
> > 
> > Oh, huh.  This bug was actually reported by me but I forgot to change
> > the from header and apparently my smtp server allows me to send emails
> > as if I work for Intel.  :P
> > 
> > Fengguang is much nicer than I am.  :P
> 
> Too late, your colleague's name is now in the patches ;-)

Thank you nice guys! :P

Thanks,
Fengguang