linux-kernel - Re: kernel bugs 2.6.31-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1250378345.14501.92.camel@dhcp231-106.rdu.redhat.com>
Date:	Sat, 15 Aug 2009 19:19:05 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Thielecke <christoph.thielecke@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: kernel bugs 2.6.31-rc6

On Sat, 2009-08-15 at 10:52 -0700, Linus Torvalds wrote:
> 
> On Sat, 15 Aug 2009, Linus Torvalds wrote:
> > 
> > For example, fsnotify_remove_priv_from_event() will remove the private 
> > data event from the list, but what if there are _multiple_ entries with 
> > the same 'group' entry? If so, it will remove just the first one.

I can happen, but ONLY for the staticly declared q_overflow_event in
notification.c.  If the refcnt on that ever hits 0 to trigger this bug
we are in some serious dodo.  

> Hmm. Looking closer, that shouldn't much matter. Each time we added an 
> entry in private_data_list, we would have done a 
> 'fsnotify_get_event(event)' due to adding it to the 'golder->event_list'.
> 
> That said, there does seem to be some dubious code there. For example, 
> in 'inotify_ignored_and_remove_idr()', we do this:
> 
>         fsnotify_add_notify_event(group, ignored_event, fsn_event_priv);
> 
>         /* did the private data get added? */
>         if (list_empty(&fsn_event_priv->event_list))
>                 inotify_free_event_priv(fsn_event_priv);

> and we do it without holding any locks at all. So as far as I can tell, 
> what could happen is that 'fsnotify_add_notify_event()' actually adds the 
> private event (fsn_event_priv), but then before we check that the 
> event_list is empty, another user (on another CPU, or preempted on the 
> same CPU - Christoph has both PREEMPT and SMP on) comes along, picks up 
> the private event and frees it (and re-uses it).

Actually you look correct in your assessment that there is a race here.
I guess I could imagine a way to make it panic like this, but I would
have expected a different problem in that after I freed this memory
(which wasn't mine any more) the other task which owned this memory
would have to still be able to run list_for_each_entry, but find that
it's group was no longer there.  Not sure how could screw up the group,
but not the list entries.

I'll fix this race tonight or in the morning.

I'm downloading and installing KDE, as I guess kde uses inotify pretty
hard since both Mikko and Christoph were using kde.

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/