AppVerifier and Heap buffer overrun
Thorsten Tarrach
the flowing code flaw is not detected by Application Verifier:
int main()
{
int* a = malloc(sizeof(int)*5);
a[5] = 5;
printf("%d",a[5]);
}
If I try to access a[6] AppVerifier does break into the debugger.
In the above case I get a warning by PreFast, but in general such an error
is not detected at compile time, that's why run time analysis is so
important for me.
Thanks, Thorsten
Jialiang Ge [MSFT]
I have tested the sample code, and reproduced the problem that appverifier
does not detect the array indexing error when the index equals 5 in a 5
-element array, but if the index is larger than 5, appverifier can detect
the memory overrun. Although I have not yet found out a switch that can
overcome the problem, I'm communicating with the appverifier product group
to search for the solutions, verify whether it's a product issue and
whether it can be enhanced/fixed.
Below is my analysis of why appverifier does not detect the overrun when
index = 5, but it can detect the error when index > 5.
==================
I debugged into the exe, and see the memory layout of the array 'a' after
the malloc statement:
a = 05253fe8
05253fd8 00000014 00000001 00000076 fdfdfdfd
05253fe8 cdcdcdcd cdcdcdcd cdcdcdcd cdcdcdcd
05253ff8 cdcdcdcd fdfdfdfd ???????? ????????
05254008 ???????? ???????? ???????? ????????
The part with the content 'cdcdcdcd' is the right area of the allocated
array. The part with the content 'fdfdfdfd' serves as the boundary of the
array, and the part with ??????? is the inaccessible memory. Appverifier
aligns the allocation address and adds the "pattern" between end of
allocation and inaccessible page depending on the allocation size.
After we call a[5] = 5, the memory becomes:
05253fd8 00000014 00000001 00000076 fdfdfdfd
05253fe8 cdcdcdcd cdcdcdcd cdcdcdcd cdcdcdcd
05253ff8 cdcdcdcd 0000005 ???????? ????????
05254008 ???????? ???????? ???????? ????????
From it, we can see a[5] = 5 corrupt the "pattern" without touching the
inaccessible page. Appverfier is not aware of this corrupt, and does not
report the problem.
If we change the index to 6, the value will be attempted to be written to
the inaccessible page (????????). Appverifier is capable of detecting this
kind of error and reports the problem. This explains why appverifier does
not detect the overrun when index = 5, but it can detect the error when
index > 5.
==================
I'm performing more researches on the issue, and will report back as soon
as possible. Also, thank you very much for reporting this issue to us!
Have a nice day!
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jialiang Ge [MSFT]
I discussed the issue with the AppVerifier product group. They told me that
you would need to call free(a). At the point of free(a), AppVerifier can
detect the heap corruption and display the dialog for debugging the
program. They also told me that they are trying to enhance AppVerifier so
that a heap corruption check can be trigger when our exe exists. In this
way, even though we do not manually call free(a), the heap corruption
problem can still be detected at the end of the program.
Thorsten, is the above information helpful to you. If you have any
questions or concerns about it, please feel free to tell me. I will forward
the question to the product group if I do not have an answer for it.
Have a very nice day!
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Thorsten Tarrach
Thanks for investigating. I abandoned AppVerifier now, because I noticed a
performance drop after installation which could only be solved by
reinstalling Vista (could have been sth else of course, but I don't remember
changing anything else).
But in the scenario I discovered the bug we discussed I did free all memory
in the end. But I used realloc in the meantime which probably cured the heap
corruption. So they should check the heap on realloc.
Thorsten
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:DtqQZfTS...@TK2MSFTNGHUB02.phx.gbl...
Jialiang Ge [MSFT]
I hear your frustration. I agree with you that heap corruption needs be
checked at realloc. This suggestion has been conveyed to the product group.
If you'd like, I'm also very willing to help you with the low performance
of Vista when it's installed with appverifier.
As the article
http://blogs.msdn.com/vcblog/archive/2008/02/05/prefast-and-sal-annotations.
aspx says, "While there is no tool that can do everything, and some overlap
in their purpose, used in combination they ensure high quality product
development.". In this case, appverifer does not successfully detect the
heap overrun, but PreFast can see the problem as you found. It's a good
practice to combine the two.
Please feel free to let me know if there's anything else I can do for you
in this case.
Have a great day!