[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161019233004.GJ19318@brightrain.aerifal.cx>
Date: Wed, 19 Oct 2016 19:30:04 -0400
From: Rich Felker <dalias@...c.org>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com, ville@...rikari.net
Subject: Re: CVE Request - TRE & musl libc regex integer overflows in buffer
size computations
On Wed, Oct 19, 2016 at 05:34:12PM -0400, cve-assign@...re.org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> > Due to incorrect use of integer types and missing overflow checks in
> > the tre_tnfa_run_parallel function's buffer overflow logic, the TRE
> > regex implementation (both original version and the one used in musl
> > libc) are subject to integer overflows in buffer size computation.
>
> > at least the num_states*num_tags multiplication can clearly
> > overflow in practice. for safety, check them all, and use the proper
> > type, size_t, rather than int.
>
> Use CVE-2016-8859 for this entire report. We do not see a sensible way
> in which the issue of an incorrect data type could be separated from
> the issue of unchecked multiplication.
Agreed.
> > - buf = xmalloc((unsigned)total_bytes);
> > + buf = calloc(total_bytes, 1);
>
> If this is a security fix, it would need a separate CVE ID.
It's not, just something I did at the same time as fixing the bogus
cast (which would be unsafe after the type fix) in this line. In
musl's version of the code, xmalloc is just malloc, and malloc+memset
was a sloppy way of writing calloc that I cleaned up.
Rich
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
