Bug 223129

        if (ret) {
                ret->count++;
        } else if (allocate) {
                ret = audit_data_pool;
                audit_data_pool = ret->next_hash;        <----------- Crash Here
                audit_pool_size--;
                dprintk("allocate from pool. %d left\n", audit_pool_size);

Created attachment 145943 [details]
potential fix for problem

This is an untested proposed patch for this problem.

I don't like that patch -- isn't the whole point of the pool that we're
preallocating data structures so that we can use them later, in a context where
we cannot allocate? If we don't have enough in the pool then there's a real
underlying problem which needs to be fixed. 

Created attachment 146837 [details]
syslog kern.debug output with dprintk on, working on serial access

QE ack for RHEL4.5.

Created attachment 147495 [details]
Potential fix

This message was sent to the upstream audit list.  I am still hoping for some
comments....

**********************

Since the upstream filesystem auditing is different than RHEL4 this
problem (I believe) is RHEL4 specific.	Lets assume I add the rule

auditctl -w /tmp/watched_file

then I run

touch /tmp/unwatched_file
mv -f /tmp/unwatech_file /tmp/watched_file

For the purposes of this discussion lets call the inode for the
original /tmp/watched_file i1 and the indoe for the
original /tmp/unwatched_file i2.

The RHEL4 kernel panics.  The reason is because it wants to allocate a
audit_inode_data to i2 but there is no audit_inode_data to allocate.
Thus we get the panic as seen in RH BZ 223129.	

When the watch was originally inserted the kernel mallocs 2
audit_inode_data structs.  One for the inode to be watched and one for
the parent of the that inode.  In our case the panic happens because
those 2 structs are allocated for i1 and for the inode associated
with /tmp.  From looking at the code I saw that in d_move we were
dropping the audit_inode_data associated with i2 (inside that function
i2 is pointed at by "dentry") at the beginning.  But we were not
dropping the watch on i1.  It appears that the watch was intended to
have been dropped on i1 later in i_put.  At the end of d_move we add the
watch for i2.  It was at this point that things blew up (as i_put had
not yet released the data structure.)

My first attempt at fixing this simply was to change d_move such that it
would drop the audit_inode_data for both i1 and i2 and then add it back
to i2 once i2 was the inode which needed the watch.  This however simply
moved the panic into i_put when it wanted to remove the audit_inode_data
from the original i1.  The reason it panics there is because when trying
to fetch the audit_inode_data to free it, it was actually trying to
allocate a new struct so it had something to free!  My solution simply
passes a new flag to audit_data_get which states if the intent of
requesting the audit_inode_data is to use it or to remove it.  If the
intent of getting the audit_inode_data was to simply remove that struct
from the inode there is no need to allocate a new one just to have it
removed.

This patch appears to fix the panic and to correctly watch the correct
inodes at the correct times.  I'd love comment as there may be other
solutions to either of the problems.  Maybe we like the removal of the
watch on i1 in d_move but we don't like the new flags.	In that case we
could just 'mess' around with i1 at the end of d_move such that it
wouldn't watch the watch in i_put and wouldn't ever get into
audit_data_get to cause the secondary panic.  Maybe there is something
I'm missing altogether.  Anyway comments please before I put this into a
RHEL4 kernel would be appreciated.

-Eric

committed in stream U5 build 47. A test kernel with this patch is available from
http://people.redhat.com/~jbaron/rhel4/

changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |FIXEDAWAITINGTEST
     Public Release|                            |expected in 42.47 or later
         Resolution|                            |FIX_BY_IBM
   Target Milestone|---                         |RHEL4_U5




------- Additional Comments From sglass.com  2007-02-13 10:51 EDT -------
This will be in the RHEL 4.5 beta. 

committed in stream E5 build 42.0.10. 

This issue affects _only_ the Red Hat Enterprise Linux 4 kernel. Other kernel
versions or upstream kernels are _not_ known be affected.

verified on an x86_64 xen guest and an ia64 system.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0085.html

committed in stream U5 build 49. A test kernel with this patch is available from
http://people.redhat.com/~jbaron/rhel4/