pid1 serialization/deserialization fixes #10519
Conversation
keszybz
added
the
good-to-merge/waiting-for-ci 👍
|
This pull request introduces 1 alert when merging 134dbf5 into 4e412d2 - view on LGTM.com new alerts:
Comment posted by LGTM.com |
keszybz
removed
the
good-to-merge/waiting-for-ci 👍
src/basic/exec-util.c
Outdated
| if (k < 0) | ||
| log_error_errno(k, "Invalid line \"%s\": %m", line); | ||
| return k; |
There was a problem hiding this comment.
LGTM is right, the condition is borked here.
keszybz
added
the
reviewed/needs-rework 🔨
This should be much better than fgets(), as we can read substantially longer lines and overly long lines result in proper errors. Fixes a vulnerability discovered by Jann Horn at Google. CVE-2018-15686 LP: #1796402 https://bugzilla.redhat.com/show_bug.cgi?id=1639071
Let's better be safe than sorry, and put a limit on what we receive.
let's prefer "unsigned long" rather than "unsigned", in case there are archs that have 32bit int, but 64bit dev_t. (Also one cast was wrong anyway.)
Let's use plain strjoin() instead.
…te function The predicate function manager_timestamp_shall_serialize() simply says whether to serialize or not serialize a timestamp, and should make things a bit easier to read.
Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
poettering
force-pushed
the
serialize-fixes
branch
from
134dbf5
to
b507423
Compare
|
I force-pushed a new version now, that hopefully fixes the LGTM issue. No changes besides this, i.e. not changes outside of exec-util.c |
poettering
removed
the
reviewed/needs-rework 🔨
|
|
||
| - Don't use fgets(), it's too hard to properly handle errors such as overly | ||
| long lines. Use read_line() instead, which is our own function that handles | ||
| this much nicer. |
There was a problem hiding this comment.
I've just opened #10533, which should help to enforce this rule more or less automatically.
|
CVE-2018-15686 was assigned for this issue |
|
@poettering |
|
I realize I might not express it clearly enough. |
|
@ChenQi1989 BTW, v239-stable branch has included this PR. https://github.com/systemd/systemd-stable/commits/v239-stable |
|
This is the first time that I know there exists a systemd-stable repo... Thanks for the info. |
|
@yuwata which commits, in particular, fix this issue in 239? is systemd/systemd-stable@1a05ff4 sufficient? |
No description provided.