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
History
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

README

back to top