Revision 19136be3f874ac265195ef35a8c5ed6c417eaea2 authored by Jeff King on 25 January 2018, 00:56:07 UTC, committed by Junio C Hamano on 25 January 2018, 21:50:17 UTC
If receive a request like: git-upload-pack /foo.git\0host=localhost we mark the offset of the NUL byte as "len", and then log the bytes after the NUL with a "%.*s" placeholder, using "pktlen - len" as the length, and "line + len + 1" as the start of the string. This is off-by-one, since the start of the string skips past the separating NUL byte, but the adjusted length includes it. Fortunately this doesn't actually read past the end of the buffer, since "%.*s" will stop when it hits a NUL. And regardless of what is in the buffer, packet_read() will always add an extra NUL terminator for safety. As an aside, the git.git client sends an extra NUL after a "host" field, too, so we'd generally hit that one first, not the one added by packet_read(). You can see this in the test output which reports 15 bytes, even though the string has only 14 bytes of visible data. But the point is that even a client sending unusual data could not get us to read past the end of the buffer, so this is purely a cosmetic fix. Reported-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 314a73d
File | Mode | Size |
---|---|---|
.gitattributes | -rw-r--r-- | 34 bytes |
LICENSE.txt | -rw-r--r-- | 1.2 KB |
sha1.c | -rw-r--r-- | 55.9 KB |
sha1.h | -rw-r--r-- | 4.0 KB |
ubc_check.c | -rw-r--r-- | 46.7 KB |
ubc_check.h | -rw-r--r-- | 1.7 KB |
Computing file changes ...