summaryrefslogtreecommitdiff
path: root/help.c
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2018-08-18 16:16:28 (GMT)
committerJunio C Hamano <gitster@pobox.com>2018-08-18 16:16:48 (GMT)
commit59a255aef05633c45c780987fa0c861cda9006f2 (patch)
treeb47a7434e8bb1bdd483014cef6fdf1bbc654dafc /help.c
parentbf1a11f0a100b080a25233980c14b5ae8f3a7d2d (diff)
downloadgit-59a255aef05633c45c780987fa0c861cda9006f2.zip
git-59a255aef05633c45c780987fa0c861cda9006f2.tar.gz
git-59a255aef05633c45c780987fa0c861cda9006f2.tar.bz2
sideband: do not read beyond the end of input
The caller of maybe_colorize_sideband() gives a counted buffer <src, n>, but the callee checked src[] as if it were a NUL terminated buffer. If src[] had all isspace() bytes in it, we would have made n negative, and then (1) made number of strncasecmp() calls to see if the remaining bytes in src[] matched keywords, reading beyond the end of the array (this actually happens even if n does not go negative), and/or (2) called strbuf_add() with negative count, most likely triggering the "you want to use way too much memory" error due to unsigned integer overflow. Fix both issues by making sure we do not go beyond &src[n]. In the longer term we may want to accept size_t as parameter for clarity (even though we know that a sideband message we are painting typically would fit on a line on a terminal and int is sufficient). Write it down as a NEEDSWORK comment. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'help.c')
0 files changed, 0 insertions, 0 deletions