All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Keno Fischer <keno@juliacomputing.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Andrey Vagin <avagin@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
	Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Subject: Re: [PATCH] prctl: allow to setup brk for et_dyn executables
Date: Fri, 22 Jan 2021 12:17:30 +0300	[thread overview]
Message-ID: <98915534-2309-cbbd-b77e-354dd274ed00@virtuozzo.com> (raw)
In-Reply-To: <20210121221207.GB2174@grain>

CC: Pavel and Alexander

On 22.01.2021 01:12, Cyrill Gorcunov wrote:
> Keno Fischer reported that when a binray loaded via
> ld-linux-x the prctl(PR_SET_MM_MAP) doesn't allow to
> setup brk value because it lays before mm:end_data.
> 
> For example a test program shows
> 
>  | # ~/t
>  |
>  | start_code      401000
>  | end_code        401a15
>  | start_stack     7ffce4577dd0
>  | start_data	   403e10
>  | end_data        40408c
>  | start_brk	   b5b000
>  | sbrk(0)         b5b000
> 
> and when executed via ld-linux
> 
>  | # /lib64/ld-linux-x86-64.so.2 ~/t
>  |
>  | start_code      7fc25b0a4000
>  | end_code        7fc25b0c4524
>  | start_stack     7fffcc6b2400
>  | start_data	   7fc25b0ce4c0
>  | end_data        7fc25b0cff98
>  | start_brk	   55555710c000
>  | sbrk(0)         55555710c000
> 
> This of course prevent criu from restoring such programs.
> Looking into how kernel operates with brk/start_brk inside
> brk() syscall I don't see any problem if we allow to setup
> brk/start_brk without checking for end_data. Even if someone
> pass some weird address here on a purpose then the worst
> possible result will be an unexpected unmapping of existing
> vma (own vma, since prctl works with the callers memory) but
> test for RLIMIT_DATA is still valid and a user won't be able
> to gain more memory in case of expanding VMAs via new values
> shipped with prctl call.
> 
> Reported-by: Keno Fischer <keno@juliacomputing.com>
> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Dmitry Safonov <0x7f454c46@gmail.com>
> CC: Andrey Vagin <avagin@gmail.com>
> CC: Kirill Tkhai <ktkhai@virtuozzo.com>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> ---
> Guys, take a look please once time permit. Hopefully I didn't
> miss something 'cause made this patch via code reading only.
> 
> Andrey, do we still have a criu container which tests new kernels,
> right? Would be great to run criu tests with this patch applied
> to make sure everything is intact.
> 
>  kernel/sys.c |    7 -------
>  1 file changed, 7 deletions(-)
> 
> Index: linux-tip.git/kernel/sys.c
> ===================================================================
> --- linux-tip.git.orig/kernel/sys.c
> +++ linux-tip.git/kernel/sys.c
> @@ -1943,13 +1943,6 @@ static int validate_prctl_map_addr(struc
>  	error = -EINVAL;
>  
>  	/*
> -	 * @brk should be after @end_data in traditional maps.
> -	 */
> -	if (prctl_map->start_brk <= prctl_map->end_data ||
> -	    prctl_map->brk <= prctl_map->end_data)
> -		goto out;
> -
> -	/*
>  	 * Neither we should allow to override limits if they set.
>  	 */
>  	if (check_data_rlimit(rlimit(RLIMIT_DATA), prctl_map->brk,
> 


  reply	other threads:[~2021-01-22  9:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 22:12 [PATCH] prctl: allow to setup brk for et_dyn executables Cyrill Gorcunov
2021-01-22  9:17 ` Kirill Tkhai [this message]
2021-07-20  7:33 ` Andrei Vagin
2021-07-20 13:54   ` Cyrill Gorcunov
2021-07-20 21:51 ` Andrew Morton
2021-07-20 22:25   ` Cyrill Gorcunov

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=98915534-2309-cbbd-b77e-354dd274ed00@virtuozzo.com \
    --to=ktkhai@virtuozzo.com \
    --cc=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.mikhalitsyn@virtuozzo.com \
    --cc=avagin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@gmail.com \
    --cc=keno@juliacomputing.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptikhomirov@virtuozzo.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.