From: Andrew Morton <akpm@linux-foundation.org>
To: Hugh Dickins <hugh@veritas.com>, David Howells <dhowells@redhat.com>
Cc: Brian Pomerantz <bapper@piratehaven.org>,
viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] fix page leak during core dump
Date: Fri, 30 Mar 2007 15:13:53 -0700 [thread overview]
Message-ID: <20070330151353.95cd56ed.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0703302250050.28059@blonde.wat.veritas.com>
On Fri, 30 Mar 2007 23:01:45 +0100 (BST)
Hugh Dickins <hugh@veritas.com> wrote:
> On Fri, 30 Mar 2007, Andrew Morton wrote:
> > On Thu, 29 Mar 2007 13:39:13 -0700
> > Brian Pomerantz <bapper@piratehaven.org> wrote:
> >
> > > When the dump cannot occur most likely because of a full file system
> > > and the page to be written is the zero page, the call to
> > > page_cache_release() is missed.
> > >
> > > Signed-off-by: Brian Pomerantz <bapper@mvista.com>
> > >
> > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > > index a2fceba..9cc4f0a 100644
> > > --- a/fs/binfmt_elf.c
> > > +++ b/fs/binfmt_elf.c
> > > @@ -1704,7 +1704,10 @@ static int elf_core_dump(long signr, struct pt_regs *regs, struct file *file)
> > > DUMP_SEEK(PAGE_SIZE);
> > > } else {
> > > if (page == ZERO_PAGE(addr)) {
> > > - DUMP_SEEK(PAGE_SIZE);
> > > + if (!dump_seek(file, PAGE_SIZE)) {
> > > + page_cache_release(page);
> > > + goto end_coredump;
> > > + }
> >
> > Oh for gawds sake I wish we could be rid of those idiotic macros :(
> >
> > This patch looks OK to me, although a refcount leak on the ZERO_PAGE is
> > special, because that page is PageReserved().
> >
> > It used to be the case that we'd ignore attempts to change the refcount on
> > reserved pages (or at least on the ZERO_PAGE), but we changed that, so we
> > now actually refcount the ZERO_PAGE. (I think, from a quick read of the
> > code. This contradicts my memory of how it works).
> >
> > So I expect the net effect here is that a sufficiently determined attacker
> > can overflow the ZERO_PAGE's refcount, thus causing it to be "freed". The
> > page allocator won't actually free the page due to PG_Reserved, but it'll
> > all become very noisy.
> >
> > Nick, Hugh: agree?
>
> I think so - lots of "Bad page state" messages as the count bounces
> around the 0 mark, but not actually freed. But when CONFIG_DEBUG_VM
> you'll get BUG_ONs. And I can't swear bad things won't happen some-
> where once the count wraps to negative. Easier to fix than work out
> the consequences.
>
> (Of course, Nick is right now proposing a patch to take us back the
> other way, back to not accounting the ZERO_PAGE: so the fix needs
> to go in, then he'll need to reverse that again in his patch.)
OK.
> Doesn't fs/binfmt_elf_fdpic.c need the same fix? It looks slightly
> different there, but I think when you look closer there's exactly
> the same issue?
Think so. David, does it look OK?
<would anyone be interested in hearing my opinion on the DUMP_SEEK macro
again?>
From: Brian Pomerantz <bapper@piratehaven.org>
When the dump cannot occur most likely because of a full file system and
the page to be written is the zero page, the call to page_cache_release()
is missed.
Signed-off-by: Brian Pomerantz <bapper@mvista.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/binfmt_elf.c | 5 ++++-
fs/binfmt_elf_fdpic.c | 6 ++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff -puN fs/binfmt_elf.c~fix-page-leak-during-core-dump fs/binfmt_elf.c
--- a/fs/binfmt_elf.c~fix-page-leak-during-core-dump
+++ a/fs/binfmt_elf.c
@@ -1704,7 +1704,10 @@ static int elf_core_dump(long signr, str
DUMP_SEEK(PAGE_SIZE);
} else {
if (page == ZERO_PAGE(addr)) {
- DUMP_SEEK(PAGE_SIZE);
+ if (!dump_seek(file, PAGE_SIZE)) {
+ page_cache_release(page);
+ goto end_coredump;
+ }
} else {
void *kaddr;
flush_cache_page(vma, addr,
diff -puN fs/binfmt_elf_fdpic.c~fix-page-leak-during-core-dump fs/binfmt_elf_fdpic.c
--- a/fs/binfmt_elf_fdpic.c~fix-page-leak-during-core-dump
+++ a/fs/binfmt_elf_fdpic.c
@@ -1480,8 +1480,10 @@ static int elf_fdpic_dump_segments(struc
DUMP_SEEK(file->f_pos + PAGE_SIZE);
}
else if (page == ZERO_PAGE(addr)) {
- DUMP_SEEK(file->f_pos + PAGE_SIZE);
- page_cache_release(page);
+ if (!dump_seek(file, file->f_pos + PAGE_SIZE)) {
+ page_cache_release(page);
+ return 0;
+ }
}
else {
void *kaddr;
_
next prev parent reply other threads:[~2007-03-30 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-29 20:39 [PATCH] fix page leak during core dump Brian Pomerantz
2007-03-30 20:43 ` Andrew Morton
2007-03-30 22:01 ` Hugh Dickins
2007-03-30 22:13 ` Andrew Morton [this message]
2007-03-30 23:06 ` Hugh Dickins
2007-03-31 12:59 ` David Howells
2007-03-31 12:57 ` David Howells
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=20070330151353.95cd56ed.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bapper@piratehaven.org \
--cc=dhowells@redhat.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=viro@zeniv.linux.org.uk \
/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.