Date: Mon, 7 Feb 2011 19:24:43 +0100 (CET)
From: Jesper Juhl <jj@chaosbits.net>
To: tadeusz.struk@intel.com
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
Subject: Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in
 rfc4106_set_hash_subkey().
In-Reply-To: <4d502ccb.p+rKcuFjWCnBlXY9%tadeusz.struk@intel.com>
Message-ID: <alpine.LNX.2.00.1102071922220.27796@swampdragon.chaosbits.net>
References: <4d502ccb.p+rKcuFjWCnBlXY9%tadeusz.struk@intel.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1183
Lines: 30

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 <jj@chaosbits.net>            http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/