Hi Junio & Wolfgang, On 2015-06-25 22:24, Junio C Hamano wrote: > Wolfgang Denk <wd@xxxxxxx> writes: > >> In message <xmqqegkzzoaz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> you wrote: >>> >>> > Question is: how can we fix that? >>> >>> It could be that 4d0d8975 is buggy and barking at a non breakage. Well, I would like to believe that this commit made our code *safer* by making sure that we would never overrun the buffer. Remember: under certain circumstances, the buffer passed to the fsck machinery is *not* terminated by a NUL. The code I introduced simply verifies that there is an empty line because the fsck code stops there and does not look further. If the buffer does *not* contain an empty line, the fsck code runs the danger of looking beyond the allocated memory because it uses functions that assume NUL-terminated strings, while the buffer passed to the fsck code is a counted string. The quick & dirty work-around would be to detect when the buffer does not contain an empty line and to make a NUL-terminated copy in that case. A better solution was outlined by Peff back when I submitted those patches: change all the code paths that read objects and make sure that all of them are terminated by a NUL. AFAIR some code paths did that already, but not all of them. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html