Message ID | 522F1BA7.7070102@linaro.org |
---|---|
State | Accepted |
Headers | show |
On 10 September 2013 18:46, Will Newton <will.newton@linaro.org> wrote: > diff --git a/malloc/malloc.c b/malloc/malloc.c > index 3148c5f..f7718a9 100644 > --- a/malloc/malloc.c > +++ b/malloc/malloc.c > @@ -3015,6 +3015,13 @@ __libc_memalign(size_t alignment, size_t bytes) > /* Otherwise, ensure that it is at least a minimum chunk size */ > if (alignment < MINSIZE) alignment = MINSIZE; > > + /* Check for overflow. */ > + if (bytes > SIZE_MAX - alignment - MINSIZE) > + { > + __set_errno (ENOMEM); > + return 0; > + } > + > arena_get(ar_ptr, bytes + alignment + MINSIZE); > if(!ar_ptr) > return 0; Looks OK to me. Siddhesh
On 10 September 2013 14:34, Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> wrote: > On 10 September 2013 18:46, Will Newton <will.newton@linaro.org> wrote: >> diff --git a/malloc/malloc.c b/malloc/malloc.c >> index 3148c5f..f7718a9 100644 >> --- a/malloc/malloc.c >> +++ b/malloc/malloc.c >> @@ -3015,6 +3015,13 @@ __libc_memalign(size_t alignment, size_t bytes) >> /* Otherwise, ensure that it is at least a minimum chunk size */ >> if (alignment < MINSIZE) alignment = MINSIZE; >> >> + /* Check for overflow. */ >> + if (bytes > SIZE_MAX - alignment - MINSIZE) >> + { >> + __set_errno (ENOMEM); >> + return 0; >> + } >> + >> arena_get(ar_ptr, bytes + alignment + MINSIZE); >> if(!ar_ptr) >> return 0; > > Looks OK to me. Thanks Siddhesh. I've applied the fixes for pvalloc, valloc and memalign. These patches should also apply cleanly to 2.18, should I cherry pick them there too? Also I am not sure if it is worth allocating a CVE number for these issues - pvalloc and valloc seem very rarely used but memalign and posix_memalign are more common.
On 11 September 2013 15:32, Will Newton <will.newton@linaro.org> wrote: > These patches should also apply cleanly to 2.18, should I cherry pick > them there too? David owns 2.18, so he can take that call. > Also I am not sure if it is worth allocating a CVE number for these > issues - pvalloc and valloc seem very rarely used but memalign and > posix_memalign are more common. It would be useful to allocate a CVE number. The fact that pvalloc and valloc are rarely used doesn't matter in this decision - it matters when evaluating the impact of the bug. Siddhesh
On 11 September 2013 11:18, Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> wrote: >> Also I am not sure if it is worth allocating a CVE number for these >> issues - pvalloc and valloc seem very rarely used but memalign and >> posix_memalign are more common. > > It would be useful to allocate a CVE number. The fact that pvalloc > and valloc are rarely used doesn't matter in this decision - it > matters when evaluating the impact of the bug. I'm not sure what the process is here, MAINTAINERS on the wiki has a link to CERT, but I aware that there are folks who work for CVE issuing authorities on this list. ;-)
On 11 September 2013 16:02, Will Newton <will.newton@linaro.org> wrote: > I'm not sure what the process is here, MAINTAINERS on the wiki has a > link to CERT, but I aware that there are folks who work for CVE > issuing authorities on this list. ;-) I've seen people emailing requests for CVE numbers on the oss-security mailing list (oss-security at lists dot openwall dot com). Siddhesh
diff --git a/malloc/malloc.c b/malloc/malloc.c index 3148c5f..f7718a9 100644 --- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -3015,6 +3015,13 @@ __libc_memalign(size_t alignment, size_t bytes) /* Otherwise, ensure that it is at least a minimum chunk size */ if (alignment < MINSIZE) alignment = MINSIZE; + /* Check for overflow. */ + if (bytes > SIZE_MAX - alignment - MINSIZE) + { + __set_errno (ENOMEM); + return 0; + } + arena_get(ar_ptr, bytes + alignment + MINSIZE); if(!ar_ptr) return 0;