From: Andrew Morton <akpm@linux-foundation.org>
To: Michel Lespinasse <walken@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix for binary_sysctl() memory leak
Date: Thu, 15 Dec 2011 14:44:11 -0800 [thread overview]
Message-ID: <20111215144411.930dd860.akpm@linux-foundation.org> (raw)
In-Reply-To: <CANN689EViJYxDRr48wK1=_Lpb62wB5tj4-fnN1-MY8y-1L33fw@mail.gmail.com>
On Thu, 15 Dec 2011 14:38:58 -0800
Michel Lespinasse <walken@google.com> wrote:
> On Thu, Dec 15, 2011 at 2:19 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > I think the patch is correct but the description is misleading?
> >
> > I see no memory leak here. __Calling __putname() directly simply
> > bypasses some audit-related stuff.
>
> Hmmm, maybe I wasn't explicit enough about it. We are definitely
> seeing a memory leak without the patch.
>
> When auditing is enabled, putname() calls audit_putname *instead* (not
> in addition) to __putname(). Then, if a syscall is in progress,
> audit_putname does not release the name - instead, it expects the name
> to get released when the syscall completes, but that will happen only
> if audit_getname() was called previously, i.e. if the name was
> allocated with getname() rather than the naked __getname(). So,
> __getname() followed by putname() ends up leaking memory.
>
OK. Please resend with a new changelog?
The bug surprises me - it seems that it makes it trivial for userspace
to cause leaking of mad amounts of kernel memory, which would cause the
bug to be found and fixed quickly.
Is it a recent regression, or does the bug trigger only in weird
circumstances, or what?
next prev parent reply other threads:[~2011-12-15 22:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 2:44 [PATCH] Fix for binary_sysctl() memory leak Michel Lespinasse
2011-12-15 22:19 ` Andrew Morton
2011-12-15 22:38 ` Michel Lespinasse
2011-12-15 22:44 ` Andrew Morton [this message]
2011-12-15 22:59 ` Michel Lespinasse
2011-12-15 23:07 ` Michel Lespinasse
2011-12-17 22:14 ` Eric W. Biederman
2011-12-18 1:23 ` Michel Lespinasse
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=20111215144411.930dd860.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=walken@google.com \
/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.