From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, hujunjie <jj.net@163.com>
Cc: linux-mm@kvack.org
Subject: Re: fs/exec.c: fix minor memory leak
Date: Mon, 16 May 2016 22:43:39 +0200 [thread overview]
Message-ID: <20160516204339.GA26141@redhat.com> (raw)
Andrew, Vlastimil,
I found this patch by accident when I was looking at http://marc.info/?l=linux-mm
and I can't resist ;)
> On 04/21/2016 11:15 PM, Andrew Morton wrote:
> >
> > Could someone please double-check this?
>
> Looks OK to me.
>
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Subject: fs/exec.c: fix minor memory leak
> >
> > When the to-be-removed argument's trailing '\0' is the final byte in the
> > page, remove_arg_zero()'s logic will avoid freeing the page, will break
> > from the loop and will then advance bprm->p to point at the first byte in
> > the next page. Net result: the final page for the zeroeth argument is
> > unfreed.
> >
> > It isn't a very important leak - that page will be freed later by the
> > bprm-wide sweep in free_arg_pages().
And so I think we should just remove this free_arg_page(), it (and the patch)
only adds the unnecessary confusion.
Note that today free_arg_page() is nop if CONFIG_MMU. At the same time, the
only reason for this free_arg_page() was that (until the commit b6a2fea39)
CONFIG_MMU did install_arg_page() for every page != NULL in bprm->page[].
So we simply do not need it today. And note that the caller is going to do
copy_strings_kernel(), so if we do free_arg_page() with CONFIG_MMU=n we will
likely have to re-allocate this page right after free.
And note that this code is actually wrong! remove_arg_zero() assumes that
argv[0] is null-terminated but this is not necessarily true. copy_strings()
does:
len = strnlen_user(...);
...
copy_from_user(..., len);
another thread or debugger can change the memory in between. Fortunately
nothing really bad can happen (afaics) even if CONFIG_MMU=n, bprm->filename
must be always zero-terminated and it was copied by the 1st copy_strings_kernel().
Still perhaps it makes sense to check "bprm->p < bprm->exec" in the main loop.
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2016-05-16 20:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 20:43 Oleg Nesterov [this message]
2016-05-16 20:55 ` fs/exec.c: fix minor memory leak Andrew Morton
2016-05-17 15:53 ` [PATCH] exec: remove the no longer needed remove_arg_zero()->free_arg_page() Oleg Nesterov
2016-05-17 15:53 ` Oleg Nesterov
-- strict thread matches above, loose matches on Subject: below --
2016-04-21 21:15 fs/exec.c: fix minor memory leak Andrew Morton
2016-05-16 14:57 ` Vlastimil Babka
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=20160516204339.GA26141@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jj.net@163.com \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
/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.