Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=576431 Michal Ambroz <rebus@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(rebus@xxxxxxxxx) | --- Comment #24 from Michal Ambroz <rebus@xxxxxxxxx> 2010-04-21 14:27:29 EDT --- Hello Tomas, regarding the FORIFY_SOURCE - here are the links to the skipfish bugzilla: http://code.google.com/p/skipfish/issues/detail?id=34 http://code.google.com/p/skipfish/issues/detail?id=1 Result is that this won't be fixed in skipfish and is issue of the fortify code in gcc. Skipfish upstream distributes with makefile containing -DFORTIFY_SOURCE=0. Issue which I have analyzed was working like that: 1) ask malloc to allocate buffer of size let say 97 bytes 2) malloc allocates 100 (according to malloc_usable_size) 3) to clean any leftovers memset(buffer, 0, 100) is called 4) this triggers coredump as FORTIFY code believes 97 bytes was requested, no more should be accessed. Situation gets even more complicated with realloc. In my opinion malloc_usable_size should be "FORTIFIED" (return only number of requested and not allocated bytes) or FORTIFY_SOURCE should use malloc_usable_size as the cap and not the requested bytes. >From security point of view - if I got from kernel more space than requested it is OK to clean it all from some lef-overs which have been there before to avoid some posibility of injecting some unwanted data. Best regards Michal Ambroz -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review