From: Alexander Viro <aviro@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH 4/4] match audit name data
Date: Mon, 19 Mar 2007 03:24:13 -0400 [thread overview]
Message-ID: <20070319072413.GD11843@devserv.devel.redhat.com> (raw)
In-Reply-To: <200703171902.32088.sgrubb@redhat.com>
On Sat, Mar 17, 2007 at 07:02:31PM -0400, Steve Grubb wrote:
> On Wednesday 14 February 2007 13:08:03 Amy Griffis wrote:
> > Reposting with fixes for audit_inc_name_count() return value and
> > better conditional context->name_count >= AUDIT_NAMES. Thanks Eric P.
>
>
> Something is wrong with this patch as its causing slab corruption in the lspp
> 65 and later kernels. I'll try to figure out what's wrong...
I see one obviously wrong thing: we leave ->name and ->name_put alone in
if (audit_inc_name_count(context, parent))
return;
idx = context->name_count - 1;
audit_copy_inode(&context->names[idx], parent);
right after add_names.
Note that when we do audit_syscall_exit() -> audit_free_names() we do
*not* throw the context away. So ->name and ->name_put are left as-is
since the before audit_free_names(), with ->name pointing to freed memory.
So when we get to the quoted code, we advance ->name_count to entry that
might very well have had stale ->name *and* non-zero ->name_put. Guess
what happens when we do audit_free_names() again on that context?
The rule we need to enforce is "anything past ->name_count is garbage".
So we need to add context->names[idx].name = NULL; in there (->name_put is
harmless after that).
Another comment: for pity sake, simplify those boolean expressions. I mean,
not only
if (found_child || (!found_parent && !found_child)) {
is
if (found_child || !found_parent) {
but in this case it's simply
if (!found_parent) {
since we can't get both found_parent and found_child non-NULL at the same
time. The second one (several lines below) can go from
if (found_parent || (!found_parent && !found_child)) {
to
if (found_parent || !found_child) {
and to
if (!found_child) {
since again, non-NULL found_child means NULL found_parent. At which point
code actually starts to make sense...
--- kernel/auditsc.c 2007-03-19 02:36:00.000000000 -0400
+++ kernel/auditsc.c 2007-03-19 03:23:19.000000000 -0400
@@ -1404,14 +1404,15 @@
}
add_names:
- if (found_child || (!found_parent && !found_child)) {
+ if (!found_parent) {
if (audit_inc_name_count(context, parent))
return;
idx = context->name_count - 1;
+ context->names[idx].name = NULL;
audit_copy_inode(&context->names[idx], parent);
}
- if (found_parent || (!found_parent && !found_child)) {
+ if (!found_child) {
if (audit_inc_name_count(context, inode))
return;
idx = context->name_count - 1;
@@ -1424,6 +1425,8 @@
context->names[idx].name_len = AUDIT_NAME_FULL;
/* don't call __putname() */
context->names[idx].name_put = 0;
+ } else {
+ context->names[idx].name = NULL;
}
if (inode)
next prev parent reply other threads:[~2007-03-19 7:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-13 19:13 [PATCH 0/4] audit obj cleanups Amy Griffis
2007-02-13 19:14 ` [PATCH 1/4] initialize name osid Amy Griffis
2007-02-13 19:14 ` [PATCH 2/4] audit inode for all xattr syscalls Amy Griffis
2007-02-13 19:15 ` [PATCH 3/4] complete message queue auditing Amy Griffis
2007-02-13 19:15 ` [PATCH 4/4] match audit name data Amy Griffis
2007-02-14 18:08 ` Amy Griffis
2007-03-17 23:02 ` Steve Grubb
2007-03-19 7:24 ` Alexander Viro [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-03-19 20:43 [PATCH 1/4] initialize name osid Amy Griffis
2007-03-19 20:43 ` [PATCH 2/4] audit inode for all xattr syscalls Amy Griffis
2007-03-19 20:43 ` [PATCH 3/4] complete message queue auditing Amy Griffis
2007-03-19 20:42 ` [PATCH 0/4] audit obj cleanups Amy Griffis
2007-03-19 20:44 ` [PATCH 4/4] match audit name data Amy Griffis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070319072413.GD11843@devserv.devel.redhat.com \
--to=aviro@redhat.com \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.