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

On Fri, Oct 5, 2012 at 8:16 AM, Peter Moody <pmoody(a)google.com&gt; wrote: > On Fri, Oct 5, 2012 at 7:26 AM, Jeff Layton <jlayton(a)redhat.com&gt; wrote: >> On Fri, 5 Oct 2012 06:57:59 -0700 >> Peter Moody <pmoody(a)google.com&gt; wrote: >> >>> On Fri, Oct 5, 2012 at 5:55 AM, Jeff Layton <jlayton(a)redhat.com&gt; wrote: >>> > On Thu, 4 Oct 2012 11:48:23 -0700 >>> > Peter Moody <pmoody(a)google.com&gt; wrote: >>> > >>> >> On Wed, Sep 26, 2012 at 6:50 AM, Alexander Viro <aviro(a)redhat.com&gt; 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(a)redhat.com&gt; > > > > -- > Peter Moody Google 1.650.253.7306 > Security Engineer pgp:0xC3410038 -- Peter Moody Google 1.650.253.7306 Security Engineer pgp:0xC3410038