All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: fanotify use after free.
Date: Tue, 28 Jan 2014 01:10:37 -0500	[thread overview]
Message-ID: <20140128061037.GA27636@redhat.com> (raw)
In-Reply-To: <20140127234017.GA7868@quack.suse.cz>

On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote:
 > On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
 > > On Fri, 24 Jan 2014, Jan Kara wrote:
 > > 
 > > >   Strange. I've installed systemd system (openSUSE 13.1) and it boots 
 > > > with the latest Linus' kernel just fine (and I have at least FANOTIFY 
 > > > and SLAB debugging set the same way as you). But it was only a KVM 
 > > > guest. I'll try tomorrow with a physical machine I guess.
 > > 
 > > FWIW the system I am reliably able to reproduce this on is opensuse 12.3 
 > > with this systemd version: 
 > > 
 > > Version     : 195
 > > Release     : 13.18.1
 >   Hum, still no luck with reproduction (either on physical machine or with
 > KVM). Anyway, I've looked at the code again and the previous patch had a
 > stupid bug (passing different pointer to fsnotify_destroy_event() than we
 > should have), plus also the merging function in fanotify was too
 > aggressive. Can you try the attached patch? It boots for me but that means
 > nothing since I cannot reproduce the issue... Thanks!

still not good I'm afraid. I still see corruption very early on in boot
and now it panics and locks up too.

Again, this happens so early that I can't grab it over usb-serial.
I stuck an mdelay(10000) in the slub corruption detector, and managed
to grab a photo of the first trace.

Trace:
? preempt_schedule
lock_acquire
? lockref_put_or_lock
_raw_spin_lock
? lockref_put_or_lock
dput
path_put
fanotify_free_event
fsnotify_destroy_event
fanotify_handle_event
? mntput
? path_openat
? handle_mm_fault
send_to_group
? fsnotify
fsnotify
do_sys_open
sys_open
RIP: lock_acquire

  2b:*	4d 8b 64 c6 08       	mov    0x8(%r14,%rax,8),%r12     <-- trapping instruction

R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free.

I also notice you mention SLAB above, but I've been using SLUB. I don't
know if the choice of allocator makes a difference in reproducability.

It's also worth noting that I have lockdep enabled, which may be perturbing things
to some degree.

	Dave


  reply	other threads:[~2014-01-28  6:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22  6:27 fanotify use after free Dave Jones
2014-01-22 16:43 ` Dave Jones
2014-01-22 18:20 ` Linus Torvalds
2014-01-22 23:36   ` Jan Kara
2014-01-23  0:08     ` Linus Torvalds
2014-01-23  0:32       ` Dave Jones
2014-01-23 15:05         ` Jan Kara
2014-01-23 10:23       ` Jiri Kosina
2014-01-23 15:05         ` Jan Kara
2014-01-23 15:07           ` Jiri Kosina
2014-01-23 23:55             ` Jan Kara
2014-01-24  7:26               ` Jiri Kosina
2014-01-27 23:40                 ` Jan Kara
2014-01-28  6:10                   ` Dave Jones [this message]
2014-01-28  8:02                     ` Jan Kara
2014-01-28 11:07                       ` Jiri Kosina
2014-01-28 14:53                         ` Jan Kara
2014-01-28 15:24                           ` Dave Jones
2014-01-28 10:53                   ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140128061037.GA27636@redhat.com \
    --to=davej@redhat.com \
    --cc=jack@suse.cz \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.