LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 13:06 Roman Gushchin
2015-01-29 19:57 ` Andrew Shewmaker
2015-02-03 13:29 ` Michal Hocko
0 siblings, 2 replies; 5+ 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] 5+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 13:06 [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Roman Gushchin
@ 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-02-03 13:29 ` Michal Hocko
1 sibling, 2 replies; 5+ 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] 5+ 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
2015-01-30 13:14 ` [PATCH] mm: " Roman Gushchin
1 sibling, 0 replies; 5+ 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] 5+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 19:57 ` Andrew Shewmaker
2015-01-30 13:09 ` [PATCH] mm/nommu.c: " Roman Gushchin
@ 2015-01-30 13:14 ` Roman Gushchin
1 sibling, 0 replies; 5+ 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] 5+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 13:06 [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Roman Gushchin
2015-01-29 19:57 ` Andrew Shewmaker
@ 2015-02-03 13:29 ` Michal Hocko
1 sibling, 0 replies; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2015-02-03 13:29 UTC | newest]
Thread overview: 5+ 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 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-02-03 13:29 ` Michal Hocko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).