[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180605070449epcms5p317013469ed52cc50878011c428bd12aa@epcms5p3>
Date: Tue, 05 Jun 2018 12:34:49 +0530
From: CHANDAN VN <chandan.vn@...sung.com>
To: Tejun Heo <tj@...nel.org>, Casey Schaufler <casey@...aufler-ca.com>
CC: "linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"bfields@...ldses.org" <bfields@...ldses.org>,
"jlayton@...nel.org" <jlayton@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
CPGS <cpgs@...sung.com>,
Sireesha Talluri <sireesha.t@...sung.com>,
Chris Wright <chrisw@...s-sol.org>
Subject: RE: Re: [PATCH] Smack: Fix memory leak in smack_inode_getsecctx
>On Mon, Jun 04, 2018 at 02:01:34PM -0700, Casey Schaufler wrote:
>> On 6/1/2018 10:45 AM, Casey Schaufler wrote:
>> > Fix memory leak in smack_inode_getsecctx
>> >
>> > The implementation of smack_inode_getsecctx() made
>> > incorrect assumptions about how Smack presents a security
>> > context. Smack does not need to allocate memory to support
>> > security contexts, so "releasing" a Smack context is a no-op.
>> > The code made an unnecessary copy and returned that as a
>> > context, which was never freed. The revised implementation
>> > returns the context correctly.
>> >
>> > Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>>
>> Tejun, does this pass your tests?
>Oh, I'm not the one who reported. Chandan?
Looks good to me. Leak not found.
Powered by blists - more mailing lists