In crypto/mem_dbg.c, the type of static function pop_info() is to return an 
This pointer can be a dangling pointer, as can be seen in the following link as 
long as one assumes that line 382 is reachable (it is).

Returning a dangling pointer from a function is not terribly good style. Using 
dangling pointers for anything is technically undefined behavior, so there is 
nothing in theory that a caller can do with the function's result that will not 
be illegal when a dangling pointer is returned.

(It is well-known that dereferencing dangling pointers is undefined behavior, 
but examples at and at show that the behavior 
of a program the *only* fault of which is to compare a dangling pointer to 
something else can be surprising too).

The function pop_info() being static, no-one may use it outside mem_dbg.c and 
the callers inside mem_dbg.c do not dereference the returned pointer. They do 
use it in a comparison though, which should ideally be avoided because of the 
examples above.

The attached patch does three small things:

- change the type of the function to return an int: 1 if the pointer ret was 
non-null before being possibly freed, 0 otherwise, and adjust the two call 
sites correspondingly;
- add a one-line comment describing the behavior of the function;
- rename the local variable ret, the name of which no longer makes sense, into 

None of these three things should change the behavior in practice of OpenSSL. 
As compiled with current C compilers, the tests "pop_info() != NULL" evaluated 
to 1 when a dangling pointer was returned. These tests were replaced with 
"pop_info()" which now evaluates to 1 under the circumstances in which a 
dangling pointer was returned.

Attachment: pop_info.patch
Description: Binary data

openssl-bugs-mod mailing list
openssl-dev mailing list
To unsubscribe:

Reply via email to