All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Cyrill Gorcunov <gorcunov@gmail.com>,
	Keno Fischer <keno@juliacomputing.com>,
	Andrey Vagin <avagin@gmail.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Kirill Tkhai <ktkhai@virtuozzo.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
	Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 4.4 07/23] prctl: allow to setup brk for et_dyn executables
Date: Fri, 24 Sep 2021 14:43:48 +0200	[thread overview]
Message-ID: <20210924124328.062183905@linuxfoundation.org> (raw)
In-Reply-To: <20210924124327.816210800@linuxfoundation.org>

From: Cyrill Gorcunov <gorcunov@gmail.com>

commit e1fbbd073137a9d63279f6bf363151a938347640 upstream.

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.

Link: https://lkml.kernel.org/r/20210121221207.GB2174@grain
Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec")
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reported-by: Keno Fischer <keno@juliacomputing.com>
Acked-by: Andrey Vagin <avagin@gmail.com>
Tested-by: Andrey Vagin <avagin@gmail.com>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 kernel/sys.c |    7 -------
 1 file changed, 7 deletions(-)

--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1775,13 +1775,6 @@ static int validate_prctl_map(struct prc
 	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,



  parent reply	other threads:[~2021-09-24 12:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 12:43 [PATCH 4.4 00/23] 4.4.285-rc1 review Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 01/23] s390/bpf: Fix optimizing out zero-extensions Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 02/23] PM / wakeirq: Fix unbalanced IRQ enable for wakeirq Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 03/23] sctp: validate chunk size in __rcv_asconf_lookup Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 04/23] sctp: add param size validation for SCTP_PARAM_SET_PRIMARY Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 05/23] thermal/drivers/exynos: Fix an error code in exynos_tmu_probe() Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 06/23] 9p/trans_virtio: Remove sysfs file on probe failure Greg Kroah-Hartman
2021-09-24 12:43 ` Greg Kroah-Hartman [this message]
2021-09-24 12:43 ` [PATCH 4.4 08/23] profiling: fix shift-out-of-bounds bugs Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 09/23] pwm: mxs: Dont modify HW state in .probe() after the PWM chip was registered Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 10/23] dmaengine: acpi-dma: check for 64-bit MMIO address Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 11/23] dmaengine: acpi: Avoid comparison GSI with Linux vIRQ Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 12/23] parisc: Move pci_dev_is_behind_card_dino to where it is used Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 13/23] dmaengine: ioat: depends on !UML Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 14/23] ceph: lockdep annotations for try_nonblocking_invalidate Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 15/23] nilfs2: fix memory leak in nilfs_sysfs_create_device_group Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 16/23] nilfs2: fix NULL pointer in nilfs_##name##_attr_release Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 17/23] nilfs2: fix memory leak in nilfs_sysfs_create_##name##_group Greg Kroah-Hartman
2021-09-24 12:43 ` [PATCH 4.4 18/23] nilfs2: fix memory leak in nilfs_sysfs_delete_##name##_group Greg Kroah-Hartman
2021-09-24 12:44 ` [PATCH 4.4 19/23] nilfs2: fix memory leak in nilfs_sysfs_create_snapshot_group Greg Kroah-Hartman
2021-09-24 12:44 ` [PATCH 4.4 20/23] nilfs2: fix memory leak in nilfs_sysfs_delete_snapshot_group Greg Kroah-Hartman
2021-09-24 12:44 ` [PATCH 4.4 21/23] blk-throttle: fix UAF by deleteing timer in blk_throtl_exit() Greg Kroah-Hartman
2021-09-24 12:44 ` [PATCH 4.4 22/23] drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV Greg Kroah-Hartman
2021-09-24 12:44 ` [PATCH 4.4 23/23] sctp: validate from_addr_param return Greg Kroah-Hartman
2021-09-24 13:50 ` [PATCH 4.4 00/23] 4.4.285-rc1 review Daniel Díaz
2021-09-25 11:45   ` Greg Kroah-Hartman
2021-09-24 17:50 ` Jon Hunter
2021-09-24 21:50 ` Pavel Machek
2021-09-24 21:55 ` Shuah Khan

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=20210924124328.062183905@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --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=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptikhomirov@virtuozzo.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.