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

Re: Another slab size-32 leak 2.6.16-rc4-mm2



On Sat, Feb 25, 2006 at 04:54:14PM -0500, Steve Grubb wrote:
> On Friday 24 February 2006 20:51, Valdis Kletnieks vt edu wrote:
> > However, the call from ipc/util.c in ipcperms() doesn't seem to
> > get cleaned up after (and, in fact, it isn't clear why it's even
> > called there, at least to me...)
> 
> I don't see any reason for it either. The attached patch removes the
> offending line and since it is not called outside of auditsc.c, we
> should make it private to that file.

You are correct that the code as written isn't doing anything other
than leaking memory.  However, it was intended to collect labels for
message queues during calls to msgget(), msgrcv(), msgsnd(), etc.  The
audit_ipc_perms() hook is only collecting labels (and attempted perm
settings) from IPC_SET operations.

This call shouldn't be removed, it should be storing the retrieved
label in the appropriate place in the audit context.  The label would
then be freed in audit_free_aux().  

It should also be noted that there was some discussion on whether
ipcperms() was really the right place for audit to hook.  See:

https://www.redhat.com/archives/linux-audit/2005-October/msg00041.html
https://www.redhat.com/archives/linux-audit/2005-October/msg00043.html
https://www.redhat.com/archives/linux-audit/2005-October/msg00044.html

To my knowledge, this was never investigated/resolved.

Regards,
Amy


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