From: Jesper Juhl Subject: Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey(). Date: Mon, 7 Feb 2011 19:24:43 +0100 (CET) Message-ID: References: <4d502ccb.p+rKcuFjWCnBlXY9%tadeusz.struk@intel.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: herbert@gondor.hengli.com.au, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, aidan.o.mahony@intel.com, gabriele.paoloni@intel.com, adrian.hoban@intel.com To: tadeusz.struk@intel.com Return-path: Received: from swampdragon.chaosbits.net ([90.184.90.115]:23128 "EHLO swampdragon.chaosbits.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754357Ab1BGSZ6 (ORCPT ); Mon, 7 Feb 2011 13:25:58 -0500 In-Reply-To: <4d502ccb.p+rKcuFjWCnBlXY9%tadeusz.struk@intel.com> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Mon, 7 Feb 2011, tadeusz.struk@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. -- Jesper Juhl http://www.chaosbits.net/ Plain text mails only, please. Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html