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:pavel@xxxxxx] > Sent: Friday, February 11, 2011 2:27 PM > To: Jesper Juhl > Cc: Struk, Tadeusz; herbert@xxxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx; 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.struk@xxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
