]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
journald: set a limit on the number of fields (1k)
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Wed, 5 Dec 2018 21:45:02 +0000 (22:45 +0100)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Wed, 9 Jan 2019 22:41:53 +0000 (23:41 +0100)
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.

src/journal/journald-native.c
src/shared/journal-importer.h

index e86178ed775a038935d6d54a895d5eaa4ed8329b..d0fee2a797c5aa85335029c0030829380e6dd458 100644 (file)
@@ -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,
index 53354b7c786e679d289fded149543179444424ae..7914c0cf5fbc88176fc25c632150f74b1f73d18c 100644 (file)
@@ -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;