From: "Jörn Engel" <joern@purestorage.com>
To: Helge Deller <deller@gmx.de>
Cc: Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: Fix overflow check in expand_upwards()
Date: Fri, 30 Jun 2017 07:51:51 -0700 [thread overview]
Message-ID: <20170630145151.GD494@cork> (raw)
In-Reply-To: <747944b6-ffb8-14db-d574-efc03e11f2a5@gmx.de>
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
prev parent reply other threads:[~2017-06-30 14:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
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=20170630145151.GD494@cork \
--to=joern@purestorage.com \
--cc=deller@gmx.de \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.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.