mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-03-06 12:58:22 +03:00
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.
This commit is contained in:
parent
f0136e0922
commit
052c57f132
@ -141,6 +141,11 @@ static int server_process_entry(
|
|||||||
}
|
}
|
||||||
|
|
||||||
/* A property follows */
|
/* 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 */
|
/* n existing properties, 1 new, +1 for _TRANSPORT */
|
||||||
if (!GREEDY_REALLOC(iovec, m,
|
if (!GREEDY_REALLOC(iovec, m,
|
||||||
|
@ -21,6 +21,9 @@
|
|||||||
#endif
|
#endif
|
||||||
#define LINE_CHUNK 8*1024u
|
#define LINE_CHUNK 8*1024u
|
||||||
|
|
||||||
|
/* The maximum number of fields in an entry */
|
||||||
|
#define ENTRY_FIELD_COUNT_MAX 1024
|
||||||
|
|
||||||
struct iovec_wrapper {
|
struct iovec_wrapper {
|
||||||
struct iovec *iovec;
|
struct iovec *iovec;
|
||||||
size_t size_bytes;
|
size_t size_bytes;
|
||||||
|
Loading…
x
Reference in New Issue
Block a user