Well anyway I think that the return value of "ablkcipher_request_alloc(ctr_tfm, 
GFP_KERNEL)" has to be changed from -EINVAL to -ENOMEM in case of failure. That 
is why would stay on the patch that Tadeusz proposed. Otherwise Juhl should 
send another one....

> -----Original Message-----
> From: Pavel Machek [mailto:pa...@ucw.cz]
> Sent: Friday, February 11, 2011 2:27 PM
> To: Jesper Juhl
> Cc: Struk, Tadeusz; herb...@gondor.hengli.com.au; linux-
> ker...@vger.kernel.org; linux-crypto@vger.kernel.org; O Mahony, Aidan;
> Paoloni, Gabriele; Hoban, Adrian
> Subject: Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in
> rfc4106_set_hash_subkey().
> 
> On Mon 2011-02-07 19:24:43, Jesper Juhl wrote:
> > On Mon, 7 Feb 2011, tadeusz.st...@intel.com wrote:
> >
> > > From:
> > > Date: Sun, 16 Jan 2011 16:41:11 +0000
> > > Subject: RE: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in
> rfc4106_set_hash_subkey().
> > >
> > > Hi Jesper,
> > > Thanks, but I think there is still a problem here. You don't want
> to kfree req_data
> > > when the kmalloc failed. I think it should look as follows.
> > > Are you ok with this?
> > >
> > Fine by me.
> >
> > I was aware of the kfree(NULL) thing, but desided to leave it as is
> for
> > two reasons - 1) kfree(NULL) is harmless and this is an error path,
> so the
> > extra function call doesn't matter much. 2) I wanted to preserve
> > deallocations in the reverse order of the allocations. But sure,
> moving
> > that kfree is a tiny optimization of the error path, so I'm fine with
> it.
> 
> I don't think such optimalization is worth doing... original code is
> as good but shorter and less complex...
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to