Hacker News Reader

Comment by zokier | Hacker News Reader

Yes. I believe the bug rises from some code like:

    if (newkey->callback != NULL) {
        newkey->callback()
    }

If newkey structure was not zeroed, then the callback would have had some contents from previous use and the NULL check would have passed and some unintended memory position would be called.

View on HN

The C standard doesn't require such code to be correct, even with calloc, because the NULL pointer is not necessarily represented by the zero bitpattern. While it will work "everywhere", calloc + NULL check is not semantically correct C.

The C standard defines NULL as 0:

"An integer constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function."

(Edit: the asterisk.)

Yes, but that's not what calloc does. It doesn't return memory with all values 0 (how can it? It doesn't know what structure you're allocating.), it returns all bits zero.

While I really appreciate learning from a good language-lawyering, and also acknowledge that there are many places where subtle interpretation issues have led to crashing code or even exploitable malfunctions, in practice the issue about different representations of Zero or the NULL-pointer are indeed mood.

I'll just be flamboyant now and claim that on all currently relevant platforms calloc'ing the memory of all supported numerical and pointer types will give you the numerical value 0 and also the NULL pointer.

Can someone name any CPU or microcontroller currently being produced that violates that statement? (e.g. uint64_t x; calloc(1,sizeof(x)) and void *p; calloc(1, sizeof(x)) or maybe memset(x,'0',sizeof(x))... and still x != 0 and p != NULL)? Even for gross missalignment? What about DSP platforms that don't have a useable byte-addressible memory? GPUs?

I agree. Note the fix used even depends on calloc setting a null pointer. The openbsd team generally makes a few other assumptions as well. But the comment I replied to was claiming the c standard itself makes these guarantees. That's wrong, and I think, slightly dangerous. It's fine to make assumptions, but one must always know what they are and not confuse them with guarantees.

Note that your memset call is totally bogus. '0' is not 0. You may have meant '\0', but plain 0 is perfectly legible. :)

I confirm that my inline C-code was written pretty sloppily... But obviously you clearly understood my intention :-)

> or the NULL-pointer are indeed mood

Just FYI, the word you probably mean is 'moot'.

Why didn't that crash? I understand the cleanup routine is always called and certainly someone tested the AES-GCM provider by just running it once.

Probably because the memory allocated just happened to contain only NUL bytes where that specific cleanup function pointer is stored whenever it was run in testing.

The point is that a targeted malicious attack would try and ensure that those bytes were not NUL and that it ended up calling malicious injected code on the target server.

Yeah, I've found a few bugs like this myself where the memory in question happened to be NULL, until some unrelated change elsewhere in the toolchain meant that it wasn't anymore.

Reply on news.ycombinator.com