All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tobin C. Harding" <me@tobin.cc>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [RFC] Warn the user when they could overflow mapcount
Date: Thu, 8 Feb 2018 14:18:04 +1100	[thread overview]
Message-ID: <20180208031804.GD3304@eros> (raw)
In-Reply-To: <20180208021112.GB14918@bombadil.infradead.org>

On Wed, Feb 07, 2018 at 06:11:12PM -0800, Matthew Wilcox wrote:
> 
> Kirill and I were talking about trying to overflow page->_mapcount
> the other day and realised that the default settings of pid_max and
> max_map_count prevent it [1].  But there isn't even documentation to
> warn a sysadmin that they've just opened themselves up to the possibility
> that they've opened their system up to a sufficiently-determined attacker.
> 
> I'm not sufficiently wise in the ways of the MM to understand exactly
> what goes wrong if we do wrap mapcount.  Kirill says:
> 
>   rmap depends on mapcount to decide when the page is not longer mapped.
>   If it sees page_mapcount() == 0 due to 32-bit wrap we are screwed;
>   data corruption, etc.
> 
> That seems pretty bad.  So here's a patch which adds documentation to the
> two sysctls that a sysadmin could use to shoot themselves in the foot,
> and adds a warning if they change either of them to a dangerous value.
> It's possible to get into a dangerous situation without triggering this
> warning (already have the file mapped a lot of times, then lower pid_max,
> then raise max_map_count, then map the file a lot more times), but it's
> unlikely to happen.
> 
> Comments?
> 
> [1] map_count counts the number of times that a page is mapped to
> userspace; max_map_count restricts the number of times a process can
> map a page and pid_max restricts the number of processes that can exist.
> So map_count can never be larger than pid_max * max_map_count.
> 
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 412314eebda6..ec90cd633e99 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -718,6 +718,8 @@ pid_max:
>  PID allocation wrap value.  When the kernel's next PID value
>  reaches this value, it wraps back to a minimum PID value.
>  PIDs of value pid_max or larger are not allocated.
> +Increasing this value without decreasing vm.max_map_count may
> +allow a hostile user to corrupt kernel memory
>  
>  ==============================================================
>  
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index ff234d229cbb..0ab306ea8f80 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -379,7 +379,8 @@ While most applications need less than a thousand maps, certain
>  programs, particularly malloc debuggers, may consume lots of them,
>  e.g., up to one or two maps per allocation.
>  
> -The default value is 65536.
> +The default value is 65530.  Increasing this value without decreasing
> +pid_max may allow a hostile user to corrupt kernel memory.

Just checking - did you mean the final '0' on this value?

	Tobin

WARNING: multiple messages have this Message-ID (diff)
From: "Tobin C. Harding" <me@tobin.cc>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [RFC] Warn the user when they could overflow mapcount
Date: Thu, 8 Feb 2018 14:18:04 +1100	[thread overview]
Message-ID: <20180208031804.GD3304@eros> (raw)
In-Reply-To: <20180208021112.GB14918@bombadil.infradead.org>

On Wed, Feb 07, 2018 at 06:11:12PM -0800, Matthew Wilcox wrote:
> 
> Kirill and I were talking about trying to overflow page->_mapcount
> the other day and realised that the default settings of pid_max and
> max_map_count prevent it [1].  But there isn't even documentation to
> warn a sysadmin that they've just opened themselves up to the possibility
> that they've opened their system up to a sufficiently-determined attacker.
> 
> I'm not sufficiently wise in the ways of the MM to understand exactly
> what goes wrong if we do wrap mapcount.  Kirill says:
> 
>   rmap depends on mapcount to decide when the page is not longer mapped.
>   If it sees page_mapcount() == 0 due to 32-bit wrap we are screwed;
>   data corruption, etc.
> 
> That seems pretty bad.  So here's a patch which adds documentation to the
> two sysctls that a sysadmin could use to shoot themselves in the foot,
> and adds a warning if they change either of them to a dangerous value.
> It's possible to get into a dangerous situation without triggering this
> warning (already have the file mapped a lot of times, then lower pid_max,
> then raise max_map_count, then map the file a lot more times), but it's
> unlikely to happen.
> 
> Comments?
> 
> [1] map_count counts the number of times that a page is mapped to
> userspace; max_map_count restricts the number of times a process can
> map a page and pid_max restricts the number of processes that can exist.
> So map_count can never be larger than pid_max * max_map_count.
> 
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 412314eebda6..ec90cd633e99 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -718,6 +718,8 @@ pid_max:
>  PID allocation wrap value.  When the kernel's next PID value
>  reaches this value, it wraps back to a minimum PID value.
>  PIDs of value pid_max or larger are not allocated.
> +Increasing this value without decreasing vm.max_map_count may
> +allow a hostile user to corrupt kernel memory
>  
>  ==============================================================
>  
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index ff234d229cbb..0ab306ea8f80 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -379,7 +379,8 @@ While most applications need less than a thousand maps, certain
>  programs, particularly malloc debuggers, may consume lots of them,
>  e.g., up to one or two maps per allocation.
>  
> -The default value is 65536.
> +The default value is 65530.  Increasing this value without decreasing
> +pid_max may allow a hostile user to corrupt kernel memory.

Just checking - did you mean the final '0' on this value?

	Tobin

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

  parent reply	other threads:[~2018-02-08  3:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08  2:11 [RFC] Warn the user when they could overflow mapcount Matthew Wilcox
2018-02-08  2:11 ` Matthew Wilcox
2018-02-08  2:56 ` Jann Horn
2018-02-08  2:56   ` Jann Horn
2018-02-08  4:04   ` Matthew Wilcox
2018-02-08  4:04     ` Matthew Wilcox
2018-02-08 17:58   ` valdis.kletnieks
2018-02-08 18:05   ` Daniel Micay
2018-02-08 18:05     ` Daniel Micay
2018-02-08 18:56     ` Matthew Wilcox
2018-02-08 18:56       ` Matthew Wilcox
2018-02-08 19:33       ` Daniel Micay
2018-02-08 19:33         ` Daniel Micay
2018-02-08 19:42         ` Matthew Wilcox
2018-02-08 19:42           ` Matthew Wilcox
2018-02-08 19:48           ` Daniel Micay
2018-02-08 19:48             ` Daniel Micay
2018-02-08 20:21             ` Matthew Wilcox
2018-02-08 20:21               ` Matthew Wilcox
2018-02-08 21:37               ` [RFC] Limit mappings to ten per page per process Matthew Wilcox
2018-02-08 21:37                 ` Matthew Wilcox
2018-02-09  4:26                 ` Kirill A. Shutemov
2018-02-09  4:26                   ` Kirill A. Shutemov
2018-02-14 13:51                   ` Matthew Wilcox
2018-02-14 13:51                     ` Matthew Wilcox
2018-02-14 14:05                     ` Kirill A. Shutemov
2018-02-14 14:05                       ` Kirill A. Shutemov
2018-02-09  1:47               ` [RFC] Warn the user when they could overflow mapcount Daniel Micay
2018-02-09  1:47                 ` Daniel Micay
2018-02-08  3:18 ` Tobin C. Harding [this message]
2018-02-08  3:18   ` Tobin C. Harding
2018-02-08  4:06   ` Matthew Wilcox
2018-02-08  4:06     ` Matthew Wilcox
2018-03-02 21:26 ` [RFC] Handle mapcount overflows Matthew Wilcox
2018-03-02 21:26   ` Matthew Wilcox
2018-03-02 22:03   ` Matthew Wilcox
2018-03-02 22:03     ` Matthew Wilcox
2019-05-01 14:41   ` Jann Horn

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=20180208031804.GD3304@eros \
    --to=me@tobin.cc \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.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.