From: Kirill Korotaev <dev@sw.ru>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Pavel Emelianov <xemul@openvz.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org
Subject: Re: [Devel] Re: [PATCH] Fix user struct leakage with locked IPC shem segment
Date: Tue, 17 Jul 2007 13:07:55 +0400 [thread overview]
Message-ID: <469C86EB.8090501@sw.ru> (raw)
In-Reply-To: <20070716151738.2f4b5cf4.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Mon, 16 Jul 2007 16:24:12 +0400
> Pavel Emelianov <xemul@openvz.org> wrote:
>
>
>>When user locks an ipc shmem segmant with SHM_LOCK ctl and the
>>segment is already locked the shmem_lock() function returns 0.
>>After this the subsequent code leaks the existing user struct:
>
>
> I'm curious. For the past few months, people@openvz.org have discovered
> (and fixed) an ongoing stream of obscure but serious and quite
> long-standing bugs.
thanks a lot :@)
> How are you discovering these bugs?
Not sure what to answer :) Just trying to do our best.
This bug was thought over by Pavel for about 3 month after a single
uid leak in container was detected by beancounters' kernel memory accounting...
>>== ipc/shm.c: sys_shmctl() ==
>> ...
>> err = shmem_lock(shp->shm_file, 1, user);
>> if (!err) {
>> shp->shm_perm.mode |= SHM_LOCKED;
>> shp->mlock_user = user;
>> }
>> ...
>>==
>>
>>Other results of this are:
>>1. the new shp->mlock_user is not get-ed and will point to freed
>> memory when the task dies.
>
>
> That sounds fairly serious - can this lead to memory corruption and crashes?
Yes it can. According to Pavel when the shmem segment is destroyed it
puts the mlock_user pointer, which can already be stalled.
Kirill
next prev parent reply other threads:[~2007-07-17 9:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-16 12:24 [PATCH] Fix user struct leakage with locked IPC shem segment Pavel Emelianov
2007-07-16 22:17 ` Andrew Morton
2007-07-17 9:07 ` Kirill Korotaev [this message]
2007-07-17 9:15 ` [Devel] " Andrew Morton
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=469C86EB.8090501@sw.ru \
--to=dev@sw.ru \
--cc=akpm@linux-foundation.org \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xemul@openvz.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.