[cfe-dev] Static Analyzer Rocks Hard

Török Edwin edwintorok at gmail.com
Mon Jun 23 09:05:59 PDT 2008

Matthew Jimenez wrote:
> It's been my experience that developers assume success without much  
> thought as to the result of failure until they actually witness it.  
> Allocation failure is especially nasty since the chances of  
> reproducing the error is so slim, and Objective-C might be even  
> nastier as nil is a valid receiver. So the need for a tool to check  
> this exists, but for better or worse, I still wouldn't imagine  
> developers to be proactive about handling such situations.
> Strangely enough, I have seen many developers be much more paranoid  
> when allocating memory directly rather than through objects.

Not handling allocation failures can lead to security holes if the
parameter to malloc
can be somehow controlled by an attacker.
It could request a huge amount of memory, that malloc would deny -> NULL
You don't necessarely have to be really out-of-memory to get an
allocation failure.

DoS: NULL dereference -> app crash
Remote code execution hole: NULL pointer -> pointer arithmetic involving
another attacker controlled value
    -> valid *attacker controlled* address -> overwrite stack -> shellcode

However in practice most allocations are unchecked leading to huge
number of warnings, so I think it would be best
to have an option to toggle checking for malloc failures.
Or classify them differently so you can filter the errors from the HTML
    null dereference on allocation failure, uninitialized value on
allocation failure, ...
Best regards,

More information about the cfe-dev mailing list