[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1543f203-6032-8926-b722-6de2e06d3e71@redhat.com>
Date: Tue, 25 Jun 2019 08:33:42 -0600
From: Jeff Law <law@...hat.com>
To: oss-security@...ts.openwall.com,
Matthew Fernandez <matthew.fernandez@...il.com>
Subject: Re: Thousands of vulnerabilities, almost no CVEs:
OSS-Fuzz
On 6/25/19 8:14 AM, Matthew Fernandez wrote:
>
>> On Jun 25, 2019, at 06:41, Bob Friesenhahn <bfriesen@...ple.dallas.tx.us> wrote:
>>
>> * Consumption of uninitialized data (e.g. image data) which is not
>> used to make important decisions. This is usually due to unhandled
>> cases or error handling which does not quit immediately.
>
> C/C++ compilers will infer backwards from uninitialized variable reads (undefined behavior in these languages) that preceding code is unreachable. For example, when moving from GCC 6 series to GCC 7 series we found one of our code bases would produce a binary that would only segfault when compiled at >= -O2. We root caused this to exactly the situation you describe: an error handling path that read uninitialized variables. The compiler appeared to infer backwards that the error check itself was a no-op as the true branch led to unconditional UB (this is my interpretation of its actions; I did not delve into the compiler’s internals).
Well, as a GCC developer, I can say it doesn't use an uninitialized read
to allow back-propagation of state to eliminate conditionals. It may
have looked that way, but there had to be something else going on.
Jeff
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.
