[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-tech
Subject:    Re: Doubt about an integer overflow in cut.c
From:       Ted Unangst <ted.unangst () gmail ! com>
Date:       2010-03-26 11:24:15
Message-ID: 3407409B-4321-4469-90DF-17B69A06BCE0 () gmail ! com
[Download RAW message or body]

If len + 1 == 0, that means the string is every byte but one, meaning  
there wouldn't be enough space for len and the string to coexist.

On Mar 26, 2010, at 5:18 AM, Amarendra Godbole <amarendra.godbole@gmail.com 
 > wrote:

> cut.c has the following:
>
> [...]
> void
> f_cut(FILE *fp, char *fname)
> {
>    int ch, field, isdelim;
>    char *pos, *p, sep;
>    int output;
>    size_t len;
>    char *lbuf, *tbuf;
>
>    for (sep = dchar, tbuf = NULL; (lbuf = fgetln(fp, &len));) {
>        output = 0;
>        if (lbuf[len - 1] != '\n') {
>            /* no newline at the end of the last line so add one */
>            if ((tbuf = (char *)malloc(len + 1)) == NULL)
>                err(1, NULL);
>            memcpy(tbuf, lbuf, len);
>            tbuf[len] = '\n';
>            lbuf = tbuf;
>        }
> [...]
>
> Now it is possible for "len+1" in the malloc() above to overflow and
> turn to 0 if len is UINT_MAX. Interestingly, in this case, fgetln()
> mostly fails with errno 12, ENOMEM so the while is never entered. My
> question is, does the malloc() here require the overflow test as
> indicated in malloc(3) manpage, or not?
>
> Thanks.
>
> -Amarendra

[prev in list] [next in list] [prev in thread] [next in thread]