blob: df1ed806a4ee9f762d5232849de4f9058eea511a [file] [log] [blame]
From 052c57f132f04a3cf4148f87561618da1a6908b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
Date: Wed, 5 Dec 2018 22:45:02 +0100
Subject: [PATCH] journald: set a limit on the number of fields (1k)
We allocate a iovec entry for each field, so with many short entries,
our memory usage and processing time can be large, even with a relatively
small message size. Let's refuse overly long entries.
CVE-2018-16865
https://bugzilla.redhat.com/show_bug.cgi?id=1653861
What from I can see, the problem is not from an alloca, despite what the CVE
description says, but from the attack multiplication that comes from creating
many very small iovecs: (void* + size_t) for each three bytes of input message.
[james.hilliard1@gmail.com: backport from upstream commit
052c57f132f04a3cf4148f87561618da1a6908b4]
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
src/journal/journald-native.c | 5 +++++
src/shared/journal-importer.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index e86178e..d0fee2a 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -141,6 +141,11 @@ static int server_process_entry(
}
/* A property follows */
+ if (n > ENTRY_FIELD_COUNT_MAX) {
+ log_debug("Received an entry that has more than " STRINGIFY(ENTRY_FIELD_COUNT_MAX) " fields, ignoring entry.");
+ r = 1;
+ goto finish;
+ }
/* n existing properties, 1 new, +1 for _TRANSPORT */
if (!GREEDY_REALLOC(iovec, m,
diff --git a/src/shared/journal-importer.h b/src/shared/journal-importer.h
index 53354b7..7914c0c 100644
--- a/src/shared/journal-importer.h
+++ b/src/shared/journal-importer.h
@@ -21,6 +21,9 @@
#endif
#define LINE_CHUNK 8*1024u
+/* The maximum number of fields in an entry */
+#define ENTRY_FIELD_COUNT_MAX 1024
+
struct iovec_wrapper {
struct iovec *iovec;
size_t size_bytes;
--
2.7.4