From 9dbac61cf123a57c1f39a2f134389f1a5877dc29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
Date: Thu, 3 Jan 2019 16:09:05 +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.
Resolves: #1657792
---
src/journal/journal-file.h | 3 +++
src/journal/journald-native.c | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/src/journal/journal-file.h b/src/journal/journal-file.h
index dd8ef52d2a..37749c4459 100644
--- a/src/journal/journal-file.h
+++ b/src/journal/journal-file.h
@@ -158,6 +158,9 @@ int journal_file_open_reliably(
* files without adding too many zeros. */
#define OFSfmt "%06"PRIx64
+/* The maximum number of fields in an entry */
+#define ENTRY_FIELD_COUNT_MAX 1024
+
static inline bool VALID_REALTIME(uint64_t u) {
/* This considers timestamps until the year 3112 valid. That should be plenty room... */
return u > 0 && u < (1ULL << 55);
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index cf3349393f..0c451274f7 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -134,6 +134,10 @@ void server_process_native_message(
}
/* 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.");
+ goto finish;
+ }
/* n existing properties, 1 new, +1 for _TRANSPORT */
if (!GREEDY_REALLOC(iovec, m, n + 2 + N_IOVEC_META_FIELDS + N_IOVEC_OBJECT_FIELDS)) {