[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC][PATCH] (#6 U1) the latest incarnation



On Thu, 2005-03-24 at 16:02 -0600, Timothy R. Chavez wrote:
> I took your advice on just initializing inode->i_audit to NULL like the 
> security field.  So would this be reasonable Stephen?
> 
> if (audit_inode_free(inode) || security_inode_alloc(inode)) {
> 	audit_inode_free(inode);
> 	security_inode_free(inode);
> 	if (inode->i_sb->s_op->destroy_inode)
> 		inode->i_sb->s_op->destroy_inode(inode);
> 	else
> 		kmem_cache_free(inode_cachep, (inode));
> 	return NULL;
> }
> 
> This way, in either case where there could be leakage, we clean up the memory 
> before the inode goes bye-bye.

1,1 s/audit_inode_free/audit_inode_alloc/

You don't need the security_inode_free() call on the error handling
path.  Consider the cases:
1) audit_inode_alloc() fails, so we don't call security_inode_alloc()
and both i_audit and i_security are NULL.  The audit_inode_free() call
on the error path does no harm.
2) audit_inode_alloc() succeeds and security_inode_alloc() fails, so
i_audit is non-NULL and i_security is NULL.  In this case, we need the
audit_inode_free() call on the error handling path.

In neither case do you need a security_inode_free() call on the error
handling path.

-- 
Stephen Smalley <sds tycho nsa gov>
National Security Agency


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]