Conversation

CVE-2019-6208 (Jann Horn of Google Project Zero) may be described in the pictures. I didn't find this by binary diff, I find this by bug collision :-( :-( :-(

is this your CVE-2019-6208?

Replying to

doesn't look like it

Replying to

Oh, then that’s my mistake. This uninitialized stack memory bug was fixed in 10.14.3, and the only CVE describing kernel memory leak is your CVE, that’s why I thought my bug conflicted with yours.

Replying to

and

No compiler option to auto-initialize stack variables?

Replying to

and

I don't know the accurate answer. Maybe some do that(e.g. -finit-local-zero under some gcc) while others don't. On the other side, C standard says the local variable has an uninitialized value, you should zero it by yourself.

Replying to

and

-finit-local-zero is a Fortran language option. I don't think there's any switch for default zero initialization in C or C++ in GCC. It was implemented in Clang, but exposed by the frontend in a way that makes it unlikely that there will be adoption. gcc.gnu.org/onlinedocs/gfo

Replying to

Clang implementation is intended to be production quality along with having useful features for debugging (not just zero bytes for hardening) but they don't want it to be a way to get well-defined semantics for uninitialized variables as a new language dialect. It's still a bug.

12:07 PM · Feb 21, 2019Twitter Web Client

Replying to

Since if it was defined as zeroing, it wouldn't be possible to detect uninitialized variable usage. The better solution to the problem is outright preventing uninitialized variable usage like Rust without having any default, just forcing init before usage based on control flow.

Replying to

C compilers don't have an option for that, since code wasn't written for strict init before use semantics. Their uninitialized variable warnings are very conservative to avoid false positives. `int x; foo(&x);` won't warn even though it's local analysis and can't know it's safe.

Show replies