mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome