System Down: A systemd-journald exploit
> If we send a large "native" message to /run/systemd/journal/socket
... the maximum size of a "native" entry is 768MB<p>Why does journal allow such large messages over a socket? That alone might be a denial-of-service attack; are real messages delayed/blocked if someone sends spawns a bunch of processes that send 768MB of junk to that socket?<p><pre><code>    commit c4aa09b06f835c91cea9e021df4c3605cff2318d
    Date:   Mon Apr 8 20:32:03 2013 +0200
    ...
    -#define ENTRY_SIZE_MAX (1024*1024*64)
    -#define DATA_SIZE_MAX (1024*1024*64)
    ...
    +#define ENTRY_SIZE_MAX (1024*1024*768)
    +#define DATA_SIZE_MAX (1024*1024*768)
</code></pre>
WTF? Why would you need to increase the max size so much? What are you intending to send over that socket?! Oh. From the commit[1], the missing lines at the 2nd "...":<p><pre><code>    +/* Make sure not to make this smaller than the maximum coredump
    + * size. See COREDUMP_MAX in coredump.c */
</code></pre>
Why would you send coredumps over a socket? Just write them to a file and send the file's path to journald. Increasing the max message size 1200% just to avoid writing a core file is crazy.<p>[1] <a href="https://github.com/systemd/systemd/commit/c4aa09b06f835c91cea9e021df4c3605cff2318d" rel="nofollow">https://github.com/systemd/systemd/commit/c4aa09b06f835c91ce...</a>