File 0001-journald-set-a-limit-on-the-number-of-fields-1k.patch of Package systemd.9885

From 5817f55160c000c1a53244dee0d351141f09fdca 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 1/1] 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.

[fbui: adjust context]
[fbui: fixes bsc#1120323]
[fbui: fixes CVE-2018-16865]
---
 src/journal/journald-native.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index 45d1003f3d..9a3f964f3a 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -38,6 +38,9 @@
 #define ENTRY_SIZE_MAX (1024*1024*770u)
 #define DATA_SIZE_MAX (1024*1024*768u)
 
+/* The maximum number of fields in an entry */
+#define ENTRY_FIELD_COUNT_MAX 1024
+
 static bool valid_user_field(const char *p, size_t l) {
         const char *a;
 
@@ -137,6 +140,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 received properties, +1 for _TRANSPORT */
                 if (!GREEDY_REALLOC(iovec, m, n + 1 + N_IOVEC_META_FIELDS +
-- 
2.19.0