[PATCH] audit: grab a reference to context->pwd when it's cached

[Peter Moody]

On Fri, Oct 5, 2012 at 8:16 AM, Peter Moody <pmoody at google.com> wrote:
> On Fri, Oct 5, 2012 at 7:26 AM, Jeff Layton <jlayton at redhat.com> wrote:
>> On Fri, 5 Oct 2012 06:57:59 -0700
>> Peter Moody <pmoody at google.com> wrote:
>>
>>> On Fri, Oct 5, 2012 at 5:55 AM, Jeff Layton <jlayton at redhat.com> wrote:
>>> > On Thu, 4 Oct 2012 11:48:23 -0700
>>> > Peter Moody <pmoody at google.com> wrote:
>>> >
>>> >> On Wed, Sep 26, 2012 at 6:50 AM, Alexander Viro <aviro at redhat.com> wrote:
>>> >> > On Tue, Sep 25, 2012 at 10:03:23AM -0700, Peter Moody wrote:
>>> >> >> Hey folks,
>>> >> >>
>>> >> >> following up on old patches, are there any comments on this? Did you
>>> >> >> get around to finding a better way to fix this bug, Al?
>>> >> >
>>> >> > Alas, I've found none ;-/  Looks like we'll have to go with this one,
>>> >> > at least until somebody comes up with better solution.
>>> >>
>>> >> Not surprisingly, this patch doesn't actually fix the issue (or at
>>> >> least doesn't do it correctly).
>>> >>
>>> >> I hadn't noticed that get_fs_pwd() actually calls path_get() on
>>> >> &context->pwd so the additional path_get() is useless and the
>>> >> reference doesn't ever actually get freed if audit_putname is called
>>> >> while we're in a syscall.
>>> >>
>>> >> Al, Eric, Jeff; do any of you guys have an understanding of what the
>>> >> initial bug actually is since this clearly doesn't fix it?
>>> >>
>>> >> Cheers,
>>> >> peter
>>> >>
>>> >
>>> > BTW, I ran this test on one of my KVM guests and it ran just fine. That
>>> > one is an x86_64 guest running a 3.6.0+ kernel. The root fs on there is
>>> > ext4 though, not ext3. So perhaps that's a factor?
>>> >
>>> > The oops message you posted at least looks like something down in the
>>> > bowels of ext3 or fs/buffer.c.
>>>
>>> Yeah, the only place this actually happens for me on these giant xen
>>> instances we have (6 cores, 32G ram) and it happens on both ext3 and
>>> ext4 filesystems and it happens with 100% reliability.
>>>
>>> The actual oops is from:
>>>
>>> static inline void check_irqs_on(void)
>>> {
>>> #ifdef irqs_disabled
>>>         BUG_ON(irqs_disabled());
>>> #endif
>>> }
>>>
>>> with the code path looking like:
>>>
>>> __find_get_block() -> lookup_bh_lru() -> check_irqs_on() -> BUG()
>>>
>>
>> Do you have a backtrace from a more recent kernel? I wonder if
>> something in the syscall exit codepath is disabling IRQs here?
>
> is 3.6.0-rc1 recent enough or do you want something newer?

nevermind, that doesn't boot. One sec.

>> --
>> Jeff Layton <jlayton at redhat.com>
>
>
>
> --
> Peter Moody      Google    1.650.253.7306
> Security Engineer  pgp:0xC3410038



-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038