From 94809b687fbb1c43b07ed8aa966070079cdcb063 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= 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 dd8ef52d2..37749c445 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 cf3349393..0c451274f 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)) {