From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Roman Gushchin To: Andrew Shewmaker Cc: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton , Rik van Riel , Konstantin Khlebnikov , "stable@vger.kernel.org" In-Reply-To: <20150129195735.GA9331@scruffy> References: <1422536763-31325-1-git-send-email-klamm@yandex-team.ru> <20150129195735.GA9331@scruffy> Subject: Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() MIME-Version: 1.0 Message-Id: <66011422623650@webcorp02h.yandex-team.ru> Date: Fri, 30 Jan 2015 16:14:10 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Sender: owner-linux-mm@kvack.org List-ID: 29.01.2015, 22:57, "Andrew Shewmaker" : > 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 29 Jan 2015 11:57:35 -0800 From: Andrew Shewmaker To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Rik van Riel , Konstantin Khlebnikov , stable@vger.kernel.org Subject: Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Message-ID: <20150129195735.GA9331@scruffy> References: <1422536763-31325-1-git-send-email-klamm@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422536763-31325-1-git-send-email-klamm@yandex-team.ru> Sender: owner-linux-mm@kvack.org List-ID: 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 > Cc: Andrew Morton > Cc: Andrew Shewmaker > Cc: Rik van Riel > Cc: Konstantin Khlebnikov > 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Roman Gushchin To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Roman Gushchin , Andrew Morton , Andrew Shewmaker , Rik van Riel , Konstantin Khlebnikov , stable@vger.kernel.org Subject: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Date: Thu, 29 Jan 2015 16:06:03 +0300 Message-Id: <1422536763-31325-1-git-send-email-klamm@yandex-team.ru> Sender: owner-linux-mm@kvack.org List-ID: 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 Cc: Andrew Morton Cc: Andrew Shewmaker Cc: Rik van Riel Cc: Konstantin Khlebnikov 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Roman Gushchin To: linux-mm@kvack.kernel.org Cc: linux-kernel@vger.kernel.org, Roman Gushchin , Andrew Morton , Andrew Shewmaker , Rik van Riel , Konstantin Khlebnikov , stable@vger.kernel.org Subject: [PATCH] mm/nommu.c: fix arithmetic overflow in __vm_enough_memory() Date: Fri, 30 Jan 2015 16:09:45 +0300 Message-Id: <1422623385-13614-1-git-send-email-klamm@yandex-team.ru> In-Reply-To: <20150129195735.GA9331@scruffy> References: <20150129195735.GA9331@scruffy> Sender: linux-kernel-owner@vger.kernel.org List-ID: 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 Cc: Andrew Morton Cc: Andrew Shewmaker Cc: Rik van Riel Cc: Konstantin Khlebnikov 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 3 Feb 2015 14:29:28 +0100 From: Michal Hocko To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Andrew Shewmaker , Rik van Riel , Konstantin Khlebnikov , stable@vger.kernel.org Subject: Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Message-ID: <20150203132928.GB8914@dhcp22.suse.cz> References: <1422536763-31325-1-git-send-email-klamm@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422536763-31325-1-git-send-email-klamm@yandex-team.ru> Sender: owner-linux-mm@kvack.org List-ID: 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 > Cc: Andrew Morton > Cc: Andrew Shewmaker > Cc: Rik van Riel > Cc: Konstantin Khlebnikov > Cc: stable@vger.kernel.org With Andrew min -> min_t fixup Reviewed-by: Michal Hocko > --- > 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: email@kvack.org -- 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: email@kvack.org