Messages in this thread Patch in this message | | | Date | Thu, 11 Apr 2013 09:40:29 -0400 (EDT) | From | Eric Paris <> | Subject | Re: [PATCH] kernel: auditfilter: looping issue, memory leak if has 2 or more AUDIT_FILTERKEYs |
| |
----- Original Message ----- > On 2013年04月11日 05:19, Eric Paris wrote: > > ----- Original Message ----- > > > >> > b. has an new issue for AUDIT_DIR: > >> > after AUDIT_DIR succeed, it will set rule->tree. > >> > next, the other case fail, then will call audit_free_rule. > >> > but audit_free_rule will not free rule->tree. > > Definitely a couple of leaks here... > > > > I'm seeing leaks on size 8, 64, and 128. > > > > Al, what do you think? Should I be calling audit_put_tree() in the error > > case if entry->tree != NULL? The audit trees are some of the most complex > > code in the kernel I think. > > > > > > can we add it in audit_free_rule ? > > maybe like this: > > @@ -75,6 +75,8 @@ static inline void audit_free_rule(struct audit_entry *e) > /* some rules don't have associated watches */ > if (erule->watch) > audit_put_watch(erule->watch); > + if (erule->tree) > + audit_put_tree(erule->tree); > if (erule->fields) > for (i = 0; i < erule->field_count; i++) { > struct audit_field *f = &erule->fields[i];
Where does the tree information get freed normally? That's the code you need to run down. You don't want to start getting double frees on the non-error case. I'll try to dig into it if Al doesn't. It's easy to show the leak on current kernels.
while(1) auditctl -a exit,always -w /etc -F auid=-1
-- 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/
| |