What do you get with gdb on vmlinux and 'l *0xc04c26bb' ?

I'm guessing we're still trying to reference an inode in SELinux while 
it's being destroyed under memory pressure.

NULL deref was in inode_free_security called by destroy_inode to free the inode
security struct.  If the inode or its security struct was already freed, the
real bug happened earlier; this is just the messenger.  inode_free_security also
dereferences inode->i_sb->s_security, but that should be valid until
destroy_super calls selinux_sb_free_security just prior to freeing the
superblock itself.  As destroy_inode dereferences inode->i_sb itself, that
shouldn't be gone yet either.

> What do you get with gdb on vmlinux and 'l *0xc04c26bb' ?

0xc04c26bb is in selinux_inode_free_security (include/linux/list.h:299).
294      * list_empty - tests whether a list is empty
295      * @head: the list to test.
296      */
297     static inline int list_empty(const struct list_head *head)
298     {
299             return head->next == head;
300     }
301
302     /**
303      * list_empty_careful - tests whether a list is empty and not being modified

Wow, ok now i'm totally lost.  isec->list is actually a struct list_head embeded
in the inode_security_struct.  It is not a pointer to a struct list_head.  Thus
we see in inode_free_security

static void inode_free_security(struct inode *inode)
{
[SNIP]
        spin_lock(&sbsec->isec_lock);
        if (!list_empty(&isec->list))
                list_del_init(&isec->list);
        spin_unlock(&sbsec->isec_lock);
[SNIP]
}

So we are passing &isec->list to list_empty()  Since inode_security_struct is
deined as:

struct inode_security_struct {
        struct inode *inode;           /* back pointer to inode object */
        struct list_head list;         /* list of inode_security_struct */
        u32 task_sid;        /* SID of creating task */
[SNIP]
};

I was under the impression that &isec->list = isec + sizeof(struct inode *) =
isec + 4

But then when we get into list_empty it is saying that we tried to dereference
memory at 0000000e.  So I have no idea where it got 0000000e.  I just don't
understand how this can be anything other than hardware or maybe a compiler
problem (I haven't looked at the assembly around this area yet)  But it
certainly looks like the value of struct list_head *head in list_empty is messed
up but there doesn't appear to be any way in the code for that to happen....

(In reply to comment #4)
> I was under the impression that &isec->list = isec + sizeof(struct inode *) =
> isec + 4

Was the hardware x86_64?

Also, structs aren't necessarily packed.

Since the backtrace was all 32 bit I assumed i686 not x86_64

ebx = 0000000a
ebx+4 = 0000000e
Assuming that ebx holds isec there.

Anyway, if that is correct, isec aka inode->i_security is already corrupt on
entry to inode_free_security, and this is just the messenger, not the cause of
the bug.  
Seeing the state of the relevant inode would be interesting.

As usual you are correct.  

Dave, can I assume you do not have a core dump from this?  If you do can I get
it?  Any way you know to reproduce it?

From looking at the assembly, the inode is at %esi and it must be corrupted. 
ebx is actually supposed to be i_security as you thought.  edi - 0x48 is the
s_security which at least is in kernel memory.  I'll troll around tomorrow
looking for anything that plays with setting/changing i_security or the inode
fields around it, but I doubt I find anything...

I didn't get a coredump, and I only saw it happen once after doing an FC6
install and then a yum update to suck down a hundred or so RPMs.

No other boxes that I've done an identical procedure on have hit this.

That was on a 32bit core duo laptop btw.

I don't see what I can do here.  Haven't seen it since F6.  Closing as worksforme