[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTinzepKLh+x7VwaqCMdue28y0xUhXFqnvZ19d5-f@mail.gmail.com>
Date: Wed, 24 Nov 2010 00:43:32 +0100
From: Vegard Nossum <vegard.nossum@...il.com>
To: Eric Paris <eparis@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
Eugene Teo <eugene@...hat.com>
Subject: Fanotify uid leak?
On 24 November 2010 00:25, Eric Paris <eparis@...hat.com> wrote:
> On Wed, 2010-11-24 at 00:15 +0100, Vegard Nossum wrote:
>> Hi,
>>
>> Inotify does not clean up properly when it fails to create the file
>> descriptor. So it leaks kernel memory. Watch "slabtop" while running
>> this program:
>>
>> #include <sys/inotify.h>
>> #include <unistd.h>
>
> potential patch at
> http://git.infradead.org/users/eparis/notify.git/shortlog/refs/heads/for-next
>
> Only compiled, not tested. Will try to do that after dinner!
There is, by the way, I think, another problem in fanotify_init(),
fs/notify/fanotify/fanotify_user.c:
user = get_current_user();
if (atomic_read(&user->fanotify_listeners) >
FANOTIFY_DEFAULT_MAX_LISTENERS) {
free_uid(user);
return -EMFILE;
}
[...]
/* fsnotify_alloc_group takes a ref. Dropped in fanotify_release */
group = fsnotify_alloc_group(&fanotify_fsnotify_ops);
if (IS_ERR(group))
return PTR_ERR(group);
so you see if the group allocation fails, then the uid will not be
freed. Please double check.
This is in any case too hard for me to trigger as it would only happen
when memory allocation for the group fails.
Enjoy your meal :-)
Vegard
--
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/
Powered by blists - more mailing lists