All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 13:06 ` Roman Gushchin
  0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-29 13:06 UTC (permalink / raw)
  To: linux-mm
  Cc: linux-kernel, Roman Gushchin, Andrew Morton, Andrew Shewmaker,
	Rik van Riel, Konstantin Khlebnikov, stable

I noticed, that "allowed" can easily overflow by falling below 0,
because (total_vm / 32) can be larger than "allowed". The problem
occurs in OVERCOMMIT_NONE mode.

In this case, a huge allocation can success and overcommit the system
(despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
(system-wide), so system become unusable.

The problem was masked out by commit c9b1d0981fcc
("mm: limit growth of 3% hardcoded other user reserve"),
but it's easy to reproduce it on older kernels:
1) set overcommit_memory sysctl to 2
2) mmap() large file multiple times (with VM_SHARED flag)
3) try to malloc() large amount of memory

It also can be reproduced on newer kernels, but miss-configured
sysctl_user_reserve_kbytes is required.

Fix this issue by switching to signed arithmetic here.

Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: stable@vger.kernel.org
---
 mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 7f684d5..5aa8dfe 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
  */
 int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 {
-	unsigned long free, allowed, reserve;
+	long free, allowed, reserve;
 
 	VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
 			-(s64)vm_committed_as_batch * num_online_cpus(),
@@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 	 */
 	if (mm) {
 		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
-		allowed -= min(mm->total_vm / 32, reserve);
+		allowed -= min((long)mm->total_vm / 32, reserve);
 	}
 
 	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
-- 
2.1.0


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 13:06 ` Roman Gushchin
  0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-29 13:06 UTC (permalink / raw)
  To: linux-mm
  Cc: linux-kernel, Roman Gushchin, Andrew Morton, Andrew Shewmaker,
	Rik van Riel, Konstantin Khlebnikov, stable

I noticed, that "allowed" can easily overflow by falling below 0,
because (total_vm / 32) can be larger than "allowed". The problem
occurs in OVERCOMMIT_NONE mode.

In this case, a huge allocation can success and overcommit the system
(despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
(system-wide), so system become unusable.

The problem was masked out by commit c9b1d0981fcc
("mm: limit growth of 3% hardcoded other user reserve"),
but it's easy to reproduce it on older kernels:
1) set overcommit_memory sysctl to 2
2) mmap() large file multiple times (with VM_SHARED flag)
3) try to malloc() large amount of memory

It also can be reproduced on newer kernels, but miss-configured
sysctl_user_reserve_kbytes is required.

Fix this issue by switching to signed arithmetic here.

Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: stable@vger.kernel.org
---
 mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 7f684d5..5aa8dfe 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
  */
 int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 {
-	unsigned long free, allowed, reserve;
+	long free, allowed, reserve;
 
 	VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
 			-(s64)vm_committed_as_batch * num_online_cpus(),
@@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 	 */
 	if (mm) {
 		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
-		allowed -= min(mm->total_vm / 32, reserve);
+		allowed -= min((long)mm->total_vm / 32, reserve);
 	}
 
 	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
-- 
2.1.0

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

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
  2015-01-29 13:06 ` Roman Gushchin
@ 2015-01-29 19:57   ` Andrew Shewmaker
  -1 siblings, 0 replies; 10+ messages in thread
From: Andrew Shewmaker @ 2015-01-29 19:57 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
	Konstantin Khlebnikov, stable

On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.
> 
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
> 
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
> 
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
> 
> Fix this issue by switching to signed arithmetic here.
> 
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org
> ---
>  mm/mmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
>   */
>  int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  {
> -	unsigned long free, allowed, reserve;
> +	long free, allowed, reserve;
>  
>  	VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
>  			-(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  	 */
>  	if (mm) {
>  		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> -		allowed -= min(mm->total_vm / 32, reserve);
> +		allowed -= min((long)mm->total_vm / 32, reserve);
>  	}
>  
>  	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> -- 
> 2.1.0
> 
Makes sense to me. Please fix mm/nommu.c also.

If a caller passes in a big negative value for pages,
then vm_acct_memory() would decrement vm_committed_as, possibly 
causing percpu_counter_read_positive(&vm_committed_as) and
__vm_enough_memory to return 0. Maybe that's okay? Callers
won't be passing in a negative pages anyway. Is there a reason
to let them, though?

-Andrew

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 19:57   ` Andrew Shewmaker
  0 siblings, 0 replies; 10+ messages in thread
From: Andrew Shewmaker @ 2015-01-29 19:57 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
	Konstantin Khlebnikov, stable

On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.
> 
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
> 
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
> 
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
> 
> Fix this issue by switching to signed arithmetic here.
> 
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org
> ---
>  mm/mmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
>   */
>  int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  {
> -	unsigned long free, allowed, reserve;
> +	long free, allowed, reserve;
>  
>  	VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
>  			-(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  	 */
>  	if (mm) {
>  		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> -		allowed -= min(mm->total_vm / 32, reserve);
> +		allowed -= min((long)mm->total_vm / 32, reserve);
>  	}
>  
>  	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> -- 
> 2.1.0
> 
Makes sense to me. Please fix mm/nommu.c also.

If a caller passes in a big negative value for pages,
then vm_acct_memory() would decrement vm_committed_as, possibly 
causing percpu_counter_read_positive(&vm_committed_as) and
__vm_enough_memory to return 0. Maybe that's okay? Callers
won't be passing in a negative pages anyway. Is there a reason
to let them, though?

-Andrew

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH] mm/nommu.c: fix arithmetic overflow in __vm_enough_memory()
  2015-01-29 19:57   ` Andrew Shewmaker
  (?)
@ 2015-01-30 13:09   ` Roman Gushchin
  -1 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:09 UTC (permalink / raw)
  To: linux-mm
  Cc: linux-kernel, Roman Gushchin, Andrew Morton, Andrew Shewmaker,
	Rik van Riel, Konstantin Khlebnikov, stable

I noticed, that "allowed" can easily overflow by falling below 0,
because (total_vm / 32) can be larger than "allowed". The problem
occurs in OVERCOMMIT_NONE mode.

In this case, a huge allocation can success and overcommit the system
(despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
(system-wide), so system become unusable.

The problem was masked out by commit c9b1d0981fcc
("mm: limit growth of 3% hardcoded other user reserve"),
but it's easy to reproduce it on older kernels:
1) set overcommit_memory sysctl to 2
2) mmap() large file multiple times (with VM_SHARED flag)
3) try to malloc() large amount of memory

It also can be reproduced on newer kernels, but miss-configured
sysctl_user_reserve_kbytes is required.

Fix this issue by switching to signed arithmetic here.

Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: stable@vger.kernel.org
---
 mm/nommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/nommu.c b/mm/nommu.c
index b51eadf..e1fd67b 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1894,7 +1894,7 @@ EXPORT_SYMBOL(unmap_mapping_range);
  */
 int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 {
-	unsigned long free, allowed, reserve;
+	long free, allowed, reserve;
 
 	vm_acct_memory(pages);
 
@@ -1958,7 +1958,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 	 */
 	if (mm) {
 		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
-		allowed -= min(mm->total_vm / 32, reserve);
+		allowed -= min_t(long, mm->total_vm / 32, reserve);
 	}
 
 	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
-- 
2.1.0


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
  2015-01-29 19:57   ` Andrew Shewmaker
  (?)
@ 2015-01-30 13:14     ` Roman Gushchin
  -1 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:14 UTC (permalink / raw)
  To: Andrew Shewmaker
  Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
	Konstantin Khlebnikov, stable

29.01.2015, 22:57, "Andrew Shewmaker" <agshew@gmail.com>:
> On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
>>  I noticed, that "allowed" can easily overflow by falling below 0,
>>  because (total_vm / 32) can be larger than "allowed". The problem
>>  occurs in OVERCOMMIT_NONE mode.
>>

> Makes sense to me. Please fix mm/nommu.c also.

Thanks!
I sent a patch for nommu.c.

>
> If a caller passes in a big negative value for pages,
> then vm_acct_memory() would decrement vm_committed_as, possibly
> causing percpu_counter_read_positive(&vm_committed_as) and
> __vm_enough_memory to return 0. Maybe that's okay? Callers
> won't be passing in a negative pages anyway. Is there a reason
> to let them, though?

I think, it isn't a problem, since no one will commit negative values (I hope).

R.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-30 13:14     ` Roman Gushchin
  0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:14 UTC (permalink / raw)
  To: Andrew Shewmaker
  Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
	Konstantin Khlebnikov, stable

29.01.2015, 22:57, "Andrew Shewmaker" <agshew@gmail.com>:
> On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
>> О©╫I noticed, that "allowed" can easily overflow by falling below 0,
>> О©╫because (total_vm / 32) can be larger than "allowed". The problem
>> О©╫occurs in OVERCOMMIT_NONE mode.
>>

> Makes sense to me. Please fix mm/nommu.c also.

Thanks!
I sent a patch for nommu.c.

>
> If a caller passes in a big negative value for pages,
> then vm_acct_memory() would decrement vm_committed_as, possibly
> causing percpu_counter_read_positive(&vm_committed_as) and
> __vm_enough_memory to return 0. Maybe that's okay? Callers
> won't be passing in a negative pages anyway. Is there a reason
> to let them, though?

I think, it isn't a problem, since no one will commit negative values (I hope).

R.

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-30 13:14     ` Roman Gushchin
  0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:14 UTC (permalink / raw)
  To: Andrew Shewmaker
  Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
	Konstantin Khlebnikov, stable

29.01.2015, 22:57, "Andrew Shewmaker" <agshew@gmail.com>:
> On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
>> ?I noticed, that "allowed" can easily overflow by falling below 0,
>> ?because (total_vm / 32) can be larger than "allowed". The problem
>> ?occurs in OVERCOMMIT_NONE mode.
>>

> Makes sense to me. Please fix mm/nommu.c also.

Thanks!
I sent a patch for nommu.c.

>
> If a caller passes in a big negative value for pages,
> then vm_acct_memory() would decrement vm_committed_as, possibly
> causing percpu_counter_read_positive(&vm_committed_as) and
> __vm_enough_memory to return 0. Maybe that's okay? Callers
> won't be passing in a negative pages anyway. Is there a reason
> to let them, though?

I think, it isn't a problem, since no one will commit negative values (I hope).

R.

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
  2015-01-29 13:06 ` Roman Gushchin
@ 2015-02-03 13:29   ` Michal Hocko
  -1 siblings, 0 replies; 10+ messages in thread
From: Michal Hocko @ 2015-02-03 13:29 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: linux-mm, linux-kernel, Andrew Morton, Andrew Shewmaker,
	Rik van Riel, Konstantin Khlebnikov, stable

On Thu 29-01-15 16:06:03, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.

s@OVERCOMMIT_NONE@OVERCOMMIT_NEVER@
 
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
> 
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
> 
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
> 
> Fix this issue by switching to signed arithmetic here.
> 
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org

With Andrew min -> min_t fixup
Reviewed-by: Michal Hocko <mhocko@suse.cz>

> ---
>  mm/mmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
>   */
>  int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  {
> -	unsigned long free, allowed, reserve;
> +	long free, allowed, reserve;
>  
>  	VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
>  			-(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  	 */
>  	if (mm) {
>  		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> -		allowed -= min(mm->total_vm / 32, reserve);
> +		allowed -= min((long)mm->total_vm / 32, reserve);
>  	}
>  
>  	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> -- 
> 2.1.0
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-02-03 13:29   ` Michal Hocko
  0 siblings, 0 replies; 10+ messages in thread
From: Michal Hocko @ 2015-02-03 13:29 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: linux-mm, linux-kernel, Andrew Morton, Andrew Shewmaker,
	Rik van Riel, Konstantin Khlebnikov, stable

On Thu 29-01-15 16:06:03, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.

s@OVERCOMMIT_NONE@OVERCOMMIT_NEVER@
 
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
> 
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
> 
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
> 
> Fix this issue by switching to signed arithmetic here.
> 
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org

With Andrew min -> min_t fixup
Reviewed-by: Michal Hocko <mhocko@suse.cz>

> ---
>  mm/mmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
>   */
>  int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  {
> -	unsigned long free, allowed, reserve;
> +	long free, allowed, reserve;
>  
>  	VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
>  			-(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>  	 */
>  	if (mm) {
>  		reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> -		allowed -= min(mm->total_vm / 32, reserve);
> +		allowed -= min((long)mm->total_vm / 32, reserve);
>  	}
>  
>  	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> -- 
> 2.1.0
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-02-03 13:29 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-29 13:06 [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Roman Gushchin
2015-01-29 13:06 ` Roman Gushchin
2015-01-29 19:57 ` Andrew Shewmaker
2015-01-29 19:57   ` Andrew Shewmaker
2015-01-30 13:09   ` [PATCH] mm/nommu.c: " Roman Gushchin
2015-01-30 13:14   ` [PATCH] mm: " Roman Gushchin
2015-01-30 13:14     ` Roman Gushchin
2015-01-30 13:14     ` Roman Gushchin
2015-02-03 13:29 ` Michal Hocko
2015-02-03 13:29   ` Michal Hocko

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.