From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amy Griffis Subject: Re: [PATCH] name_count array overrun Date: Wed, 27 Sep 2006 17:04:49 -0400 Message-ID: <20060927210449.GD1539@fc.hp.com> References: <200609071400.06853.sgrubb@redhat.com> <20060907204322.GA12003@fc.hp.com> <200609240856.57610.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8RL5VD9026537 for ; Wed, 27 Sep 2006 17:05:31 -0400 Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k8RL5PFV014885 for ; Wed, 27 Sep 2006 17:05:25 -0400 Received: from smtp2.fc.hp.com (smtp-test.fc.hp.com [15.11.136.114]) by atlrel7.hp.com (Postfix) with ESMTP id 54BC836FC0 for ; Wed, 27 Sep 2006 17:05:20 -0400 (EDT) Received: from ldl.fc.hp.com (linux-bugs.fc.hp.com [15.11.146.30]) by smtp2.fc.hp.com (Postfix) with ESMTP id 150148D03D for ; Wed, 27 Sep 2006 21:05:20 +0000 (UTC) Received: from localhost (ldl.lart [127.0.0.1]) by ldl.fc.hp.com (Postfix) with ESMTP id CC35B134149 for ; Wed, 27 Sep 2006 15:05:19 -0600 (MDT) Received: from ldl.fc.hp.com ([127.0.0.1]) by localhost (ldl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17452-08 for ; Wed, 27 Sep 2006 15:05:16 -0600 (MDT) Content-Disposition: inline In-Reply-To: <200609240856.57610.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve Grubb wrote: [Sun Sep 24 2006, 08:56:57AM EDT] > On Thursday 07 September 2006 16:43, Amy Griffis wrote: > > Did you consider just dropping any data encountered after we've filled > > AUDIT_NAMES, instead of copying over the data for the last element? > > OK, corrected patch follows. Sorry for the delayed response, I've been out of town. Do we want a similar printk in __audit_inode()? > The below patch closes an unbounded use of name_count. This can lead to oopses > in some new file systems. > > Signed-off-by: Steve Grubb > > > diff -urp linux-2.6.18.x86_64.orig/kernel/auditsc.c > linux-2.6.18.x86_64/kernel/auditsc.c > --- linux-2.6.18.x86_64.orig/kernel/auditsc.c 2006-09-24 > 08:24:27.000000000 -0400 > +++ linux-2.6.18.x86_64/kernel/auditsc.c 2006-09-24 08:42:01.000000000 -0400 > @@ -1347,7 +1347,13 @@ void __audit_inode_child(const char *dna > } > > update_context: > - idx = context->name_count++; > + idx = context->name_count; > + if (context->name_count == AUDIT_NAMES) { > + printk(KERN_DEBUG "name_count maxed and losing %s\n", > + found_name ?: "(null)"); > + return; > + } > + context->name_count++; > #if AUDIT_DEBUG > context->ino_count++; > #endif > @@ -1365,7 +1371,18 @@ update_context: > /* A parent was not found in audit_names, so copy the inode data for the > * provided parent. */ > if (!found_name) { > - idx = context->name_count++; > + idx = context->name_count; > + if (context->name_count == AUDIT_NAMES) { > + printk(KERN_DEBUG > + "name_count maxed and losing parent inode data: dev=%02x:%02x rdev=%02x: > %02x, inode=%lu", > + MAJOR(parent->i_sb->s_dev), > + MINOR(parent->i_sb->s_dev), > + MAJOR(parent->i_rdev), > + MINOR(parent->i_rdev), > + parent->i_ino); > + return; > + } > + context->name_count++; > #if AUDIT_DEBUG > context->ino_count++; > #endif >