linux-kernel - Re: fanotify use after free.

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: <CA+55aFxnv050RqhhLBbsvV4=dcu-_ZXokbhmuO8Y4zVcvVJ6OQ@mail.gmail.com>
Date:	Wed, 22 Jan 2014 10:20:01 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Jones <davej@...hat.com>, Jan Kara <jack@...e.cz>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: fanotify use after free.

On Tue, Jan 21, 2014 at 10:27 PM, Dave Jones <davej@...hat.com> wrote:
>
> BUG fanotify_event_info (Not tainted): Poison overwritten

Looking at the poison data, it seems that is is the

        u32 response;

field that has been overwritten (with all zero).

That doesn't really help me guess where the bug is, though. That code
is crazy. For example, looking at one place where it is set, we have:

 - process_access_response():

        re->event->response = response;

        wake_up(&group->fanotify_data.access_waitq);

        kmem_cache_free(fanotify_response_event_cache, re);

which looks buggy in *so* many ways. In particular, we're doing a
kmem_cache_free() on "re", but what happened to "re->event" that we
just used? There was no release of that anywhere. Wut?

So it seems that the lifetime of these "fanotify_event_info"
structures is completely buggered. I don't even see any *attempt* to
maintain reference counts or other lifetime info. People free the
containers that point to them without doing anything at all about the
fsnotify_event that contains the fanotify_event_info that they point
to.

Jan - how is the lifetime of the fanotify_event_info tied to the
lifetime of the fanotify_response_event structure that contains
pointers into it? Because I don't see it.

And considering that it's the response field that gets overwritten, it
really sounds like *that* is the exact issue at play here - there is
some fanotify_response_event structure holding a pointer to the
fanotify_event that is embedded into a fanotify_event_info that has
been freed.

Jan?

                 Linus
--
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/