All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>, linux-api@vger.kernel.org
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Florian Weimer <fweimer@redhat.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Michal Hocko <mhocko@suse.com>,
	Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
	Joel Stanley <joel@jms.id.au>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map
Date: Wed, 29 Nov 2017 10:45:43 -0700	[thread overview]
Message-ID: <93ce964b-e352-1905-c2b6-deedf2ea06f8@oracle.com> (raw)
In-Reply-To: <20171129144219.22867-3-mhocko@kernel.org>

On 11/29/2017 07:42 AM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> Both load_elf_interp and load_elf_binary rely on elf_map to map segments
> on a controlled address and they use MAP_FIXED to enforce that. This is
> however dangerous thing prone to silent data corruption which can be
> even exploitable. Let's take CVE-2017-1000253 as an example. At the time
> (before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
> ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
> the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
> we could end up mapping over the existing stack with some luck.
> 
> The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
> fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
> further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
> revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
> stack consumption early during execve fully stopped by da029c11e6b1
> ("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
> safe and any attack should be impractical. On the other hand this is
> just too subtle assumption so it can break quite easily and hard to
> spot.
> 
> I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
> fundamentally dangerous. Moreover it shouldn't be even needed. We are
> at the early process stage and so there shouldn't be unrelated mappings
> (except for stack and loader) existing so mmap for a given address
> should succeed even without MAP_FIXED. Something is terribly wrong if
> this is not the case and we should rather fail than silently corrupt the
> underlying mapping.
> 
> Address this issue by changing MAP_FIXED to the newly added
> MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
> existing mapping clashing with the requested one without clobbering it.
> 
> Cc: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
> Cc: Joel Stanley <joel@jms.id.au>
> Acked-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---

Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>

WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>, linux-api@vger.kernel.org
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Florian Weimer <fweimer@redhat.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Michal Hocko <mhocko@suse.com>,
	Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
	Joel Stanley <joel@jms.id.au>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map
Date: Wed, 29 Nov 2017 10:45:43 -0700	[thread overview]
Message-ID: <93ce964b-e352-1905-c2b6-deedf2ea06f8@oracle.com> (raw)
In-Reply-To: <20171129144219.22867-3-mhocko@kernel.org>

On 11/29/2017 07:42 AM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> Both load_elf_interp and load_elf_binary rely on elf_map to map segments
> on a controlled address and they use MAP_FIXED to enforce that. This is
> however dangerous thing prone to silent data corruption which can be
> even exploitable. Let's take CVE-2017-1000253 as an example. At the time
> (before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
> ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
> the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
> we could end up mapping over the existing stack with some luck.
> 
> The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
> fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
> further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
> revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
> stack consumption early during execve fully stopped by da029c11e6b1
> ("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
> safe and any attack should be impractical. On the other hand this is
> just too subtle assumption so it can break quite easily and hard to
> spot.
> 
> I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
> fundamentally dangerous. Moreover it shouldn't be even needed. We are
> at the early process stage and so there shouldn't be unrelated mappings
> (except for stack and loader) existing so mmap for a given address
> should succeed even without MAP_FIXED. Something is terribly wrong if
> this is not the case and we should rather fail than silently corrupt the
> underlying mapping.
> 
> Address this issue by changing MAP_FIXED to the newly added
> MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
> existing mapping clashing with the requested one without clobbering it.
> 
> Cc: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
> Cc: Joel Stanley <joel@jms.id.au>
> Acked-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---

Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>

--
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>

  reply	other threads:[~2017-11-29 17:46 UTC|newest]

Thread overview: 130+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 14:42 [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Michal Hocko
2017-11-29 14:42 ` Michal Hocko
2017-11-29 14:42 ` Michal Hocko
2017-11-29 14:42 ` [PATCH 1/2] " Michal Hocko
2017-11-29 14:42   ` Michal Hocko
2017-11-29 14:42   ` Michal Hocko
2017-12-06  5:15   ` Michael Ellerman
2017-12-06  5:15     ` Michael Ellerman
2017-12-06  9:27     ` Michal Hocko
2017-12-06  9:27       ` Michal Hocko
2017-12-06 10:02       ` Michal Hocko
2017-12-06 10:02         ` Michal Hocko
2017-12-07 12:07   ` Pavel Machek
2017-12-07 12:07     ` Pavel Machek
2017-11-29 14:42 ` [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2017-11-29 14:42   ` Michal Hocko
2017-11-29 14:42   ` Michal Hocko
2017-11-29 17:45   ` Khalid Aziz [this message]
2017-11-29 17:45     ` Khalid Aziz
2018-05-29 22:21     ` Mike Kravetz
2018-05-30  8:02       ` Michal Hocko
2018-05-30 15:00         ` Mike Kravetz
2018-05-30 16:25           ` Michal Hocko
2018-05-31  0:51             ` Mike Kravetz
2018-05-31  9:24               ` Michal Hocko
2018-05-31 21:46                 ` Mike Kravetz
2017-11-29 14:45 ` [PATCH] mmap.2: document new MAP_FIXED_SAFE flag Michal Hocko
2017-11-29 14:45   ` Michal Hocko
2017-11-29 14:45   ` Michal Hocko
2017-11-30  3:16   ` John Hubbard
2017-11-30  3:16     ` John Hubbard
2017-11-30  3:16     ` John Hubbard
2017-11-30  8:23     ` Michal Hocko
2017-11-30  8:23       ` Michal Hocko
2017-11-30  8:24   ` [PATCH v2] " Michal Hocko
2017-11-30  8:24     ` Michal Hocko
2017-11-30  8:24     ` Michal Hocko
2017-11-30  8:24     ` Michal Hocko
2017-11-30 18:31     ` John Hubbard
2017-11-30 18:31       ` John Hubbard
2017-11-30 18:31       ` John Hubbard
2017-11-30 18:39       ` Michal Hocko
2017-11-30 18:39         ` Michal Hocko
2017-11-29 15:13 ` [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Rasmus Villemoes
2017-11-29 15:13   ` Rasmus Villemoes
2017-11-29 15:13   ` Rasmus Villemoes
2017-11-29 15:50   ` Michal Hocko
2017-11-29 15:50     ` Michal Hocko
2017-11-29 15:50     ` Michal Hocko
2017-11-29 22:15   ` Kees Cook
2017-11-29 22:15     ` Kees Cook
2017-11-29 22:12 ` Kees Cook
2017-11-29 22:12   ` Kees Cook
2017-11-29 22:25 ` Kees Cook
2017-11-29 22:25   ` Kees Cook
2017-11-30  6:58   ` Michal Hocko
2017-11-30  6:58     ` Michal Hocko
2017-11-30  6:58     ` Michal Hocko
2017-12-01 15:26     ` Cyril Hrubis
2017-12-01 15:26       ` Cyril Hrubis
2017-12-06  4:51       ` Michael Ellerman
2017-12-06  4:51         ` Michael Ellerman
2017-12-06  4:54         ` Matthew Wilcox
2017-12-06  4:54           ` Matthew Wilcox
2017-12-06  7:03           ` Matthew Wilcox
2017-12-06  7:03             ` Matthew Wilcox
2017-12-06  7:33             ` John Hubbard
2017-12-06  7:33               ` John Hubbard
2017-12-06  7:35               ` Florian Weimer
2017-12-06  7:35                 ` Florian Weimer
2017-12-06  7:35                 ` Florian Weimer
2017-12-06  8:06                 ` John Hubbard
2017-12-06  8:06                   ` John Hubbard
2017-12-06  8:06                   ` John Hubbard
2017-12-06  8:06                   ` John Hubbard
2017-12-06  8:54                   ` Florian Weimer
2017-12-06  8:54                     ` Florian Weimer
2017-12-06  8:54                     ` Florian Weimer
2017-12-07  5:46             ` Michael Ellerman
2017-12-07  5:46               ` Michael Ellerman
2017-12-07  5:46               ` Michael Ellerman
2017-12-07 19:14               ` Kees Cook
2017-12-07 19:14                 ` Kees Cook
2017-12-07 19:57                 ` Matthew Wilcox
2017-12-07 19:57                   ` Matthew Wilcox
2017-12-07 19:57                   ` Matthew Wilcox
2017-12-08  8:33                   ` Michal Hocko
2017-12-08  8:33                     ` Michal Hocko
2017-12-08 20:13                     ` Kees Cook
2017-12-08 20:13                       ` Kees Cook
2017-12-08 20:13                       ` Kees Cook
2017-12-08 20:57                       ` Matthew Wilcox
2017-12-08 20:57                         ` Matthew Wilcox
2017-12-08 20:57                         ` Matthew Wilcox
2017-12-08 11:08                   ` Michael Ellerman
2017-12-08 11:08                     ` Michael Ellerman
2017-12-08 14:27                     ` Pavel Machek
2017-12-08 20:31                       ` Cyril Hrubis
2017-12-08 20:31                         ` Cyril Hrubis
2017-12-08 20:31                         ` Cyril Hrubis
2017-12-08 20:47                       ` Florian Weimer
2017-12-08 20:47                         ` Florian Weimer
2017-12-08 20:47                         ` Florian Weimer
2017-12-08 14:33                     ` David Laight
2017-12-08 14:33                       ` David Laight
2017-12-06  4:50     ` Michael Ellerman
2017-12-06  4:50       ` Michael Ellerman
2017-12-06  7:33       ` Rasmus Villemoes
2017-12-06  7:33         ` Rasmus Villemoes
2017-12-06  7:33         ` Rasmus Villemoes
2017-12-06  9:08         ` Michal Hocko
2017-12-06  9:08           ` Michal Hocko
2017-12-06  9:08           ` Michal Hocko
2017-12-07  0:19           ` Kees Cook
2017-12-07  0:19             ` Kees Cook
2017-12-07  1:08             ` John Hubbard
2017-12-07  1:08               ` John Hubbard
  -- strict thread matches above, loose matches on Subject: below --
2017-12-13  9:25 [PATCH v2 " Michal Hocko
2017-12-13  9:25 ` [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2017-12-13  9:25   ` Michal Hocko
2017-12-13  9:25   ` Michal Hocko
2018-04-18 10:51   ` Tetsuo Handa
2018-04-18 10:51     ` Tetsuo Handa
2018-04-18 11:33     ` Michal Hocko
2018-04-18 11:43       ` Tetsuo Handa
2018-04-18 11:55         ` Michal Hocko
2017-11-16 10:18 Michal Hocko
2017-11-16 10:19 ` [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2017-11-16 10:19   ` Michal Hocko
2017-11-16 10:19   ` Michal Hocko
2017-11-17  0:30   ` Kees Cook
2017-11-17  0:30     ` Kees Cook

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=93ce964b-e352-1905-c2b6-deedf2ea06f8@oracle.com \
    --to=khalid.aziz@oracle.com \
    --cc=aarcange@redhat.com \
    --cc=abdhalee@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweimer@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=joel@jms.id.au \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    /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.