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 |
---|---|---|
.gitignore | -rw-r--r-- | 7 bytes |
README | -rw-r--r-- | 10.6 KB |
TEAMS | -rw-r--r-- | 2.4 KB |
bg.po | -rw-r--r-- | 628.8 KB |
ca.po | -rw-r--r-- | 479.4 KB |
de.po | -rw-r--r-- | 501.2 KB |
es.po | -rw-r--r-- | 477.3 KB |
fr.po | -rw-r--r-- | 521.8 KB |
git.pot | -rw-r--r-- | 312.2 KB |
is.po | -rw-r--r-- | 3.3 KB |
it.po | -rw-r--r-- | 128.2 KB |
ko.po | -rw-r--r-- | 509.8 KB |
pt_PT.po | -rw-r--r-- | 482.9 KB |
ru.po | -rw-r--r-- | 605.0 KB |
sv.po | -rw-r--r-- | 505.6 KB |
vi.po | -rw-r--r-- | 558.7 KB |
zh_CN.po | -rw-r--r-- | 460.3 KB |
Computing file changes ...