On 6/1/2018 9:29 AM, CHANDAN VN wrote:
>>> I agree that the fix can be done simply by using "false" for
>>> smack_inode_getsecurity(), but what happens with kernfs_node_setsecdata()
>>> and smack_inode_notifysecctx(). kernfs_node_setsecdata() is probably
>>> ignorable
>>> but smack_inode_noti
>> I agree that the fix can be done simply by using "false" for
>> smack_inode_getsecurity(), but what happens with kernfs_node_setsecdata()
>> and smack_inode_notifysecctx(). kernfs_node_setsecdata() is probably
>>ignorable
>> but smack_inode_notifysecctx() is sending the "ctx" to
>>smack_ino
On 6/1/2018 1:56 AM, CHANDAN VN wrote:
> Hi
>
>
>> On 5/31/2018 9:11 AM, Tejun Heo wrote:
>> On Thu, May 31, 2018 at 09:04:25AM -0700, Casey Schaufler wrote:
On 5/31/2018 8:39 AM, Tejun Heo wrote:
> (cc'ing more security folks and copying whole body)
>
> So, I'm sure the patc
Hi
>On 5/31/2018 9:11 AM, Tejun Heo wrote:
> On Thu, May 31, 2018 at 09:04:25AM -0700, Casey Schaufler wrote:
>>> On 5/31/2018 8:39 AM, Tejun Heo wrote:
(cc'ing more security folks and copying whole body)
So, I'm sure the patch fixes the memory leak but API wise it looks
supe
On 5/31/2018 1:57 PM, Eric W. Biederman wrote:
> Casey Schaufler writes:
>
>> On 5/31/2018 2:28 AM, CHANDAN VN wrote:
>>> From: "sireesha.t"
>>>
>>> Leak is caused because smack_inode_getsecurity() is allocating memory
>>> using kstrdup(). Though the security_release_secctx() is called, it
>>> wo
Casey Schaufler writes:
> On 5/31/2018 2:28 AM, CHANDAN VN wrote:
>> From: "sireesha.t"
>>
>> Leak is caused because smack_inode_getsecurity() is allocating memory
>> using kstrdup(). Though the security_release_secctx() is called, it
>> would not free the allocated memory. Calling security_rele
On 5/31/2018 9:11 AM, Tejun Heo wrote:
> On Thu, May 31, 2018 at 09:04:25AM -0700, Casey Schaufler wrote:
>> On 5/31/2018 8:39 AM, Tejun Heo wrote:
>>> (cc'ing more security folks and copying whole body)
>>>
>>> So, I'm sure the patch fixes the memory leak but API wise it looks
>>> super confusing.
On Thu, May 31, 2018 at 09:04:25AM -0700, Casey Schaufler wrote:
> On 5/31/2018 8:39 AM, Tejun Heo wrote:
> > (cc'ing more security folks and copying whole body)
> >
> > So, I'm sure the patch fixes the memory leak but API wise it looks
> > super confusing. Can security folks chime in here? Is th
On 5/31/2018 8:39 AM, Tejun Heo wrote:
> (cc'ing more security folks and copying whole body)
>
> So, I'm sure the patch fixes the memory leak but API wise it looks
> super confusing. Can security folks chime in here? Is this the right
> fix?
security_inode_getsecctx() provides a security context
(cc'ing more security folks and copying whole body)
So, I'm sure the patch fixes the memory leak but API wise it looks
super confusing. Can security folks chime in here? Is this the right
fix?
Thanks.
On Thu, May 31, 2018 at 02:58:31PM +0530, CHANDAN VN wrote:
> From: "sireesha.t"
>
> Leak i
On 5/31/2018 2:28 AM, CHANDAN VN wrote:
> From: "sireesha.t"
>
> Leak is caused because smack_inode_getsecurity() is allocating memory
> using kstrdup(). Though the security_release_secctx() is called, it
> would not free the allocated memory. Calling security_release_secctx is
> not relevant for
From: "sireesha.t"
Leak is caused because smack_inode_getsecurity() is allocating memory
using kstrdup(). Though the security_release_secctx() is called, it
would not free the allocated memory. Calling security_release_secctx is
not relevant for this scenario as inode_getsecurity() does not provi
12 matches
Mail list logo
