[llvm-bugs] [Bug 44310] New: false positive for realloc()?

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44310

            Bug ID: 44310
           Summary: false positive for realloc()?
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: dcoughlin at apple.com
          Reporter: rgerhards at hq.adiscon.com
                CC: dcoughlin at apple.com, llvm-bugs at lists.llvm.org

I think I found a false positive in static analyzer's understanding of
realloc(). Please have a look here:

http://ubuntu16.rsyslog.com/19-12-13_07-32-59/2019-12-13-073355-8933-1/report-da528b.html#EndPath

I do a realloc here:
uchar *const pbuf = realloc(mem->data, mem->len + write_size + 1);

Static analyzer assumes that this causes the memory (mem->data) to be released.
This is fine as it also assume a non-null return value. However, slightly later
in the code I reassign the "freed" memory pointer to the new buffer address
returned by realloc():

mem->data = pbuf;

That seems to be ignored by static analyzer as later in the process it claims
that the memory is still freed (report cause 18, after return from function). I
used "const" wherever appropriate and so there should be no doubt about
aliasing in regard to the new pointer.

In the end result, static analyzer diagnoses both a double free and
use-after-free. IMHO this is the effect of not honoring the reassignment of the
buffer pointer.

I have also checked other realloc() uses inside the same code base. They follow
all a similar pattern, but none of them triggers any alert.

I may have overlooked something, but I really don't have any idea anymore of
what could be the real error cause.

As a last resort, I will now go ahead and make the code in question invisible
to static analyzer via preprocessor #if, but I really don't like this idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191216/781e9ec2/attachment.html>