All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm: Fix overflow check in expand_upwards()
@ 2017-06-29 23:02 Jörn Engel
  2017-06-30  6:57 ` Helge Deller
  0 siblings, 1 reply; 5+ messages in thread
From: Jörn Engel @ 2017-06-29 23:02 UTC (permalink / raw)
  To: Helge Deller, Hugh Dickins, linux-kernel

I believe the overflow check was correct, then got subtly broken by
	commit bd726c90b6b8
	Author: Helge Deller <deller@gmx.de>
	Date:   Mon Jun 19 17:34:05 2017 +0200

	    Allow stack to grow up to address space limit

The old overflow check may have been a bit subtle and I suppose Helge
missed its importance.

	if (!address)
		return -ENOMEM;

Functionally the my check is identical to the old one.  I just hope the
alternative form (and comment!) make it harder to miss and break things
in a future patch.

Signed-off-by: Joern Engel <joern@logfs.org>
---
 mm/mmap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index a5e3dcd75e79..7366f62c31f4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2232,7 +2232,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
 
 	/* Guard against exceeding limits of the address space. */
 	address &= PAGE_MASK;
-	if (address >= TASK_SIZE)
+	/* second check is for integer overflow */
+	if (address >= TASK_SIZE || address + PAGE_SIZE < address)
 		return -ENOMEM;
 	address += PAGE_SIZE;
 
-- 
2.1.4

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

* Re: [PATCH] mm: Fix overflow check in expand_upwards()
  2017-06-29 23:02 [PATCH] mm: Fix overflow check in expand_upwards() Jörn Engel
@ 2017-06-30  6:57 ` Helge Deller
  2017-06-30  7:34   ` Helge Deller
  2017-06-30 14:51   ` Jörn Engel
  0 siblings, 2 replies; 5+ messages in thread
From: Helge Deller @ 2017-06-30  6:57 UTC (permalink / raw)
  To: Jörn Engel, Hugh Dickins, linux-kernel

On 30.06.2017 01:02, Jörn Engel wrote:
> I believe the overflow check was correct, then got subtly broken by
> 	commit bd726c90b6b8
> 	Author: Helge Deller <deller@gmx.de>
> 	Date:   Mon Jun 19 17:34:05 2017 +0200
> 
> 	    Allow stack to grow up to address space limit
> 
> The old overflow check may have been a bit subtle and I suppose Helge
> missed its importance.
> 
> 	if (!address)
> 		return -ENOMEM;
> 
> Functionally the my check is identical to the old one.  I just hope the
> alternative form (and comment!) make it harder to miss and break things
> in a future patch.
> 
> Signed-off-by: Joern Engel <joern@logfs.org>
> ---
>  mm/mmap.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index a5e3dcd75e79..7366f62c31f4 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2232,7 +2232,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  
>  	/* Guard against exceeding limits of the address space. */
>  	address &= PAGE_MASK;
> -	if (address >= TASK_SIZE)
> +	/* second check is for integer overflow */
> +	if (address >= TASK_SIZE || address + PAGE_SIZE < address)
>  		return -ENOMEM;
>  	address += PAGE_SIZE;

That overflow check is still there.
Look at the next few lines in mmap.c:

       /* Enforce stack_guard_gap */
        gap_addr = address + stack_guard_gap;

        /* Guard against overflow */
        if (gap_addr < address || gap_addr > TASK_SIZE)
                gap_addr = TASK_SIZE;

If the requested page plus the gap (=gap_addr) wraps around, then the
code will limit it to TASK_SIZE.
So, the code should already take care of all possible areas >=TASK_SIZE,
including wrap-arounds.

Did you faced a real issue?

Helge

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

* Re: [PATCH] mm: Fix overflow check in expand_upwards()
  2017-06-30  6:57 ` Helge Deller
@ 2017-06-30  7:34   ` Helge Deller
  2017-06-30 18:26     ` Jörn Engel
  2017-06-30 14:51   ` Jörn Engel
  1 sibling, 1 reply; 5+ messages in thread
From: Helge Deller @ 2017-06-30  7:34 UTC (permalink / raw)
  To: Jörn Engel; +Cc: Hugh Dickins, linux-kernel

* Helge Deller <deller@gmx.de>:
> On 30.06.2017 01:02, Jörn Engel wrote:
> > I believe the overflow check was correct, then got subtly broken by
> > 	commit bd726c90b6b8
> > 	Author: Helge Deller <deller@gmx.de>
> > 	Date:   Mon Jun 19 17:34:05 2017 +0200
> > 
> > 	    Allow stack to grow up to address space limit
> > 
> > The old overflow check may have been a bit subtle and I suppose Helge
> > missed its importance.
> > 
> > 	if (!address)
> > 		return -ENOMEM;
> > 
> > Functionally the my check is identical to the old one.  I just hope the
> > alternative form (and comment!) make it harder to miss and break things
> > in a future patch.
> > 
> > Signed-off-by: Joern Engel <joern@logfs.org>
> > ---
> >  mm/mmap.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index a5e3dcd75e79..7366f62c31f4 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2232,7 +2232,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
> >  
> >  	/* Guard against exceeding limits of the address space. */
> >  	address &= PAGE_MASK;
> > -	if (address >= TASK_SIZE)
> > +	/* second check is for integer overflow */
> > +	if (address >= TASK_SIZE || address + PAGE_SIZE < address)
> >  		return -ENOMEM;
> >  	address += PAGE_SIZE;
> 
> That overflow check is still there.

I see there are some architectures which define TASK_SIZE not as
multiple of PAGE_SIZE and as 0xffffffff for which the (address >=
TASK_SIZE) check will not trigger:

arch/arm/include/asm/memory.h:#define TASK_SIZE         UL(0xffffffff)
arch/frv/include/asm/mem-layout.h:#define TASK_SIZE                     __UL(0xFFFFFFFFUL)
arch/m68k/include/asm/processor.h:#define TASK_SIZE     (0xFFFFFFFFUL)
arch/blackfin/include/asm/processor.h:#define TASK_SIZE 0xFFFFFFFF
arch/h8300/include/asm/processor.h:#define TASK_SIZE    (0xFFFFFFFFUL)
arch/xtensa/include/asm/processor.h:#define TASK_SIZE   __XTENSA_UL_CONST(0xffffffff)

None of those have an upwards growing stack and thus I believe we don't
run into issues, but nevertheless the checks could probably be changed
like this (untested patch):

diff --git a/mm/mmap.c b/mm/mmap.c
index a5e3dcd..224bdc2 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2224,15 +2224,17 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
 {
 	struct mm_struct *mm = vma->vm_mm;
 	struct vm_area_struct *next;
-	unsigned long gap_addr;
+	unsigned long gap_addr, max_task_size;
 	int error = 0;
 
 	if (!(vma->vm_flags & VM_GROWSUP))
 		return -EFAULT;
 
+	max_task_size = TASK_SIZE & PAGE_MASK;
+
 	/* Guard against exceeding limits of the address space. */
 	address &= PAGE_MASK;
-	if (address >= TASK_SIZE)
+	if (address >= max_task_size)
 		return -ENOMEM;
 	address += PAGE_SIZE;
 
@@ -2240,8 +2242,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
 	gap_addr = address + stack_guard_gap;
 
 	/* Guard against overflow */
-	if (gap_addr < address || gap_addr > TASK_SIZE)
-		gap_addr = TASK_SIZE;
+	if (gap_addr < address || gap_addr > max_task_size)
+		gap_addr = max_task_size;
 
 	next = vma->vm_next;
 	if (next && next->vm_start < gap_addr) {

Helge

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

* Re: [PATCH] mm: Fix overflow check in expand_upwards()
  2017-06-30  6:57 ` Helge Deller
  2017-06-30  7:34   ` Helge Deller
@ 2017-06-30 14:51   ` Jörn Engel
  1 sibling, 0 replies; 5+ messages in thread
From: Jörn Engel @ 2017-06-30 14:51 UTC (permalink / raw)
  To: Helge Deller; +Cc: Hugh Dickins, linux-kernel

On Fri, Jun 30, 2017 at 08:57:27AM +0200, Helge Deller wrote:
> On 30.06.2017 01:02, Jörn Engel wrote:
> > I believe the overflow check was correct, then got subtly broken by
> > 	commit bd726c90b6b8
> > 	Author: Helge Deller <deller@gmx.de>
> > 	Date:   Mon Jun 19 17:34:05 2017 +0200
> > 
> > 	    Allow stack to grow up to address space limit
> > 
> > The old overflow check may have been a bit subtle and I suppose Helge
> > missed its importance.
> > 
> > 	if (!address)
> > 		return -ENOMEM;
> > 
> > Functionally the my check is identical to the old one.  I just hope the
> > alternative form (and comment!) make it harder to miss and break things
> > in a future patch.
> > 
> > Signed-off-by: Joern Engel <joern@logfs.org>
> > ---
> >  mm/mmap.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index a5e3dcd75e79..7366f62c31f4 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2232,7 +2232,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
> >  
> >  	/* Guard against exceeding limits of the address space. */
> >  	address &= PAGE_MASK;
> > -	if (address >= TASK_SIZE)
> > +	/* second check is for integer overflow */
> > +	if (address >= TASK_SIZE || address + PAGE_SIZE < address)
> >  		return -ENOMEM;
> >  	address += PAGE_SIZE;
> 
> That overflow check is still there.
> Look at the next few lines in mmap.c:
> 
>        /* Enforce stack_guard_gap */
>         gap_addr = address + stack_guard_gap;
> 
>         /* Guard against overflow */
>         if (gap_addr < address || gap_addr > TASK_SIZE)
>                 gap_addr = TASK_SIZE;
> 
> If the requested page plus the gap (=gap_addr) wraps around, then the
> code will limit it to TASK_SIZE.
> So, the code should already take care of all possible areas >=TASK_SIZE,
> including wrap-arounds.

Does it cover the case where address is (unsigned long)-PAGE_SIZE?

I believe you catch every other case, but not that one.

> Did you faced a real issue?

No.  I don't even own a computer with stacks growing up.  Just spotted
this while reviewing some patches going by.

Jörn

--
The Linux community is zillions of people with different cultures and ideas
all trying to convince the rest that their vision of the shared culture
is right.
-- Alan Cox

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

* Re: [PATCH] mm: Fix overflow check in expand_upwards()
  2017-06-30  7:34   ` Helge Deller
@ 2017-06-30 18:26     ` Jörn Engel
  0 siblings, 0 replies; 5+ messages in thread
From: Jörn Engel @ 2017-06-30 18:26 UTC (permalink / raw)
  To: Helge Deller; +Cc: Hugh Dickins, linux-kernel

On Fri, Jun 30, 2017 at 09:34:24AM +0200, Helge Deller wrote:
> 
> I see there are some architectures which define TASK_SIZE not as
> multiple of PAGE_SIZE and as 0xffffffff for which the (address >=
> TASK_SIZE) check will not trigger:
> 
> arch/arm/include/asm/memory.h:#define TASK_SIZE         UL(0xffffffff)
> arch/frv/include/asm/mem-layout.h:#define TASK_SIZE                     __UL(0xFFFFFFFFUL)
> arch/m68k/include/asm/processor.h:#define TASK_SIZE     (0xFFFFFFFFUL)
> arch/blackfin/include/asm/processor.h:#define TASK_SIZE 0xFFFFFFFF
> arch/h8300/include/asm/processor.h:#define TASK_SIZE    (0xFFFFFFFFUL)
> arch/xtensa/include/asm/processor.h:#define TASK_SIZE   __XTENSA_UL_CONST(0xffffffff)
> 
> None of those have an upwards growing stack and thus I believe we don't
> run into issues, but nevertheless the checks could probably be changed
> like this (untested patch):

That would also work.  I have no preference which patch to use.

> diff --git a/mm/mmap.c b/mm/mmap.c
> index a5e3dcd..224bdc2 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2224,15 +2224,17 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  {
>  	struct mm_struct *mm = vma->vm_mm;
>  	struct vm_area_struct *next;
> -	unsigned long gap_addr;
> +	unsigned long gap_addr, max_task_size;
>  	int error = 0;
>  
>  	if (!(vma->vm_flags & VM_GROWSUP))
>  		return -EFAULT;
>  
> +	max_task_size = TASK_SIZE & PAGE_MASK;
> +
>  	/* Guard against exceeding limits of the address space. */
>  	address &= PAGE_MASK;
> -	if (address >= TASK_SIZE)
> +	if (address >= max_task_size)
>  		return -ENOMEM;
>  	address += PAGE_SIZE;
>  
> @@ -2240,8 +2242,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  	gap_addr = address + stack_guard_gap;
>  
>  	/* Guard against overflow */
> -	if (gap_addr < address || gap_addr > TASK_SIZE)
> -		gap_addr = TASK_SIZE;
> +	if (gap_addr < address || gap_addr > max_task_size)
> +		gap_addr = max_task_size;
>  
>  	next = vma->vm_next;
>  	if (next && next->vm_start < gap_addr) {
> 
> Helge

Jörn

--
You cannot suppose that Moliere ever troubled himself to be original in the
matter of ideas. You cannot suppose that the stories he tells in his plays
have never been told before. They were culled, as you very well know.
-- Andre-Louis Moreau in Scarabouche

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

end of thread, other threads:[~2017-06-30 18:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-29 23:02 [PATCH] mm: Fix overflow check in expand_upwards() Jörn Engel
2017-06-30  6:57 ` Helge Deller
2017-06-30  7:34   ` Helge Deller
2017-06-30 18:26     ` Jörn Engel
2017-06-30 14:51   ` Jörn Engel

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.