summaryrefslogtreecommitdiff
path: root/pretty.c
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2022-12-01 14:47:23 (GMT)
committerJunio C Hamano <gitster@pobox.com>2022-12-09 05:26:21 (GMT)
commit304a50adff6480ede46b68f7545baab542cbfb46 (patch)
tree865578d1011a7c2a3ba0b844887a1e96f0f9aaa9 /pretty.c
parentf930a2394303b902e2973f4308f96529f736b8bc (diff)
downloadgit-304a50adff6480ede46b68f7545baab542cbfb46.zip
git-304a50adff6480ede46b68f7545baab542cbfb46.tar.gz
git-304a50adff6480ede46b68f7545baab542cbfb46.tar.bz2
pretty: restrict input lengths for padding and wrapping formats
Both the padding and wrapping formatting directives allow the caller to specify an integer that ultimately leads to us adding this many chars to the result buffer. As a consequence, it is trivial to e.g. allocate 2GB of RAM via a single formatting directive and cause resource exhaustion on the machine executing this logic. Furthermore, it is debatable whether there are any sane usecases that require the user to pad data to 2GB boundaries or to indent wrapped data by 2GB. Restrict the input sizes to 16 kilobytes at a maximum to limit the amount of bytes that can be requested by the user. This is not meant as a fix because there are ways to trivially amplify the amount of data we generate via formatting directives; the real protection is achieved by the changes in previous steps to catch and avoid integer wraparound that causes us to under-allocate and access beyond the end of allocated memory reagions. But having such a limit significantly helps fuzzing the pretty format, because the fuzzer is otherwise quite fast to run out-of-memory as it discovers these formatters. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pretty.c')
-rw-r--r--pretty.c26
1 files changed, 26 insertions, 0 deletions
diff --git a/pretty.c b/pretty.c
index aae6e79..e228557 100644
--- a/pretty.c
+++ b/pretty.c
@@ -13,6 +13,13 @@
#include "gpg-interface.h"
#include "trailer.h"
+/*
+ * The limit for formatting directives, which enable the caller to append
+ * arbitrarily many bytes to the formatted buffer. This includes padding
+ * and wrapping formatters.
+ */
+#define FORMATTING_LIMIT (16 * 1024)
+
static char *user_format;
static struct cmt_fmt_map {
const char *name;
@@ -1046,6 +1053,15 @@ static size_t parse_padding_placeholder(const char *placeholder,
if (!*end || end == start)
return 0;
width = strtol(start, &next, 10);
+
+ /*
+ * We need to limit the amount of padding, or otherwise this
+ * would allow the user to pad the buffer by arbitrarily many
+ * bytes and thus cause resource exhaustion.
+ */
+ if (width < -FORMATTING_LIMIT || width > FORMATTING_LIMIT)
+ return 0;
+
if (next == start || width == 0)
return 0;
if (width < 0) {
@@ -1205,6 +1221,16 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
if (*next != ')')
return 0;
}
+
+ /*
+ * We need to limit the format here as it allows the
+ * user to prepend arbitrarily many bytes to the buffer
+ * when rewrapping.
+ */
+ if (width > FORMATTING_LIMIT ||
+ indent1 > FORMATTING_LIMIT ||
+ indent2 > FORMATTING_LIMIT)
+ return 0;
rewrap_message_tail(sb, c, width, indent1, indent2);
return end - placeholder + 1;
} else