bus-message: fix skipping of array fields in !gvariant messages
We copied part of the string into a buffer that was off by two.
If the element signature had length one, we'd copy 0 bytes and crash when
looking at the "first" byte. Otherwise, we would crash because strncpy would
not terminate the string.
bus-message: fix calculation of offsets table for arrays
This is similar to the grandparent commit 'fix calculation of offsets table',
except that now the change is for array elements. Same story as before: we need
to make sure that the offsets increase enough taking alignment into account.
While at it, rename 'p' to 'previous' to match similar code in other places.
The offsets specify the ends of variable length data. We would trust the
incoming data, putting the offsets specified in our message
into the offsets tables after doing some superficial verification.
But when actually reading the data we apply alignment, so we would take
the previous offset, align it, making it bigger then current offset, and
then we'd try to read data of negative length.
In the attached example, the message specifies the following offsets:
[1, 4]
but the alignment of those items is
[1, 8]
so we'd calculate the second item as starting at 8 and ending at 4.
bus-message: avoid an infinite loop on empty structures
The alternative would be to treat gvariant and !gvariant messages differently.
But this is a problem because we check signatures is variuos places before we
have an actual message, for example in sd_bus_add_object_vtable(). It seems
better to treat things consistent (i.e. follow the lowest common denominator)
and disallow empty structures everywhere.
sd-bus: unify three code-paths which free struct bus_container
We didn't free one of the fields in two of the places.
$ valgrind --show-leak-kinds=all --leak-check=full \
build/fuzz-bus-message \
test/fuzz/fuzz-bus-message/leak-c09c0e2256d43bc5e2d02748c8d8760e7bc25d20
...
==14457== HEAP SUMMARY:
==14457== in use at exit: 3 bytes in 1 blocks
==14457== total heap usage: 509 allocs, 508 frees, 51,016 bytes allocated
==14457==
==14457== 3 bytes in 1 blocks are definitely lost in loss record 1 of 1
==14457== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==14457== by 0x53AFE79: strndup (in /usr/lib64/libc-2.27.so)
==14457== by 0x4F52EB8: free_and_strndup (string-util.c:1039)
==14457== by 0x4F8E1AB: sd_bus_message_peek_type (bus-message.c:4193)
==14457== by 0x4F76CB5: bus_message_dump (bus-dump.c:144)
==14457== by 0x108F12: LLVMFuzzerTestOneInput (fuzz-bus-message.c:24)
==14457== by 0x1090F7: main (fuzz-main.c:34)
==14457==
==14457== LEAK SUMMARY:
==14457== definitely lost: 3 bytes in 1 blocks
Introduce free_and_strndup and use it in bus-message.c
v2: fix error in free_and_strndup()
When the orignal and copied message were the same, but shorter than specified
length l, memory read past the end of the buffer would be performed. A test
case is included: a string that had an embedded NUL ("q\0") is used to replace
"q".
v3: Fix one more bug in free_and_strndup and add tests.
v4: Some style fixed based on review, one more use of free_and_replace, and
make the tests more comprehensive.
318/365 fuzz-bus-message:crash-26bba7182dedc8848939931d9fcefcb7922f2e56:address OK 0.03 s
319/365 fuzz-bus-message:crash-29ed3c202e0ffade3cad42c8bbeb6cc68a21eb8e:address OK 0.03 s
320/365 fuzz-bus-message:crash-b88ad9ecf4aacf4a0caca5b5543953265367f084:address OK 0.03 s
321/365 fuzz-bus-message:crash-c1b37b4729b42c0c05b23cba4eed5d8102498a1e:address OK 0.03 s
322/365 fuzz-bus-message:crash-d8f3941c74219b4c03532c9b244d5ea539c61af5:address OK 0.03 s
323/365 fuzz-bus-message:crash-e1b811da5ca494e494b77c6bd8e1c2f2989425c5:address OK 0.03 s
324/365 fuzz-bus-message:leak-c09c0e2256d43bc5e2d02748c8d8760e7bc25d20:address OK 0.04 s
325/365 fuzz-bus-message:message1:address OK 0.03 s
326/365 fuzz-bus-message:timeout-08ee8f6446a4064db064e8e0b3d220147f7d0b5b:address OK 0.03 s
327/365 fuzz-dhcp-server:discover-existing:address OK 0.04 s
328/365 fuzz-dhcp-server:discover-new:address OK 0.03 s
329/365 fuzz-dhcp-server:release:address OK 0.04 s
330/365 fuzz-dhcp-server:request-existing:address OK 0.03 s
331/365 fuzz-dhcp-server:request-new:address OK 0.03 s
332/365 fuzz-dhcp-server:request-reboot:address OK 0.03 s
333/365 fuzz-dhcp-server:request-renew:address OK 0.03 s
334/365 fuzz-dns-packet:issue-7888:address OK 0.03 s
335/365 fuzz-dns-packet:oss-fuzz-5465:address OK 0.03 s
336/365 fuzz-journal-remote:crash-5a8f03d4c3a46fcded39527084f437e8e4b54b76:address OK 0.06 s
337/365 fuzz-journal-remote:crash-96dee870ea66d03e89ac321eee28ea63a9b9aa45:address OK 0.04 s
338/365 fuzz-journal-remote:invalid-ts.txt:address OK 0.04 s
339/365 fuzz-journal-remote:oss-fuzz-8659:address OK 0.06 s
340/365 fuzz-journal-remote:oss-fuzz-8686:address OK 0.04 s
341/365 fuzz-journal-remote:sample.txt:address OK 0.07 s
342/365 fuzz-unit-file:directives.service:address OK 0.03 s
343/365 fuzz-unit-file:empty.scope:address OK 0.04 s
344/365 fuzz-unit-file:machine.slice:address OK 0.03 s
345/365 fuzz-unit-file:oss-fuzz-6884:address OK 0.05 s
346/365 fuzz-unit-file:oss-fuzz-6885:address OK 0.03 s
347/365 fuzz-unit-file:oss-fuzz-6886:address OK 0.04 s
348/365 fuzz-unit-file:oss-fuzz-6892:address OK 0.03 s
349/365 fuzz-unit-file:oss-fuzz-6897:address OK 0.05 s
350/365 fuzz-unit-file:oss-fuzz-6897-evverx:address OK 0.04 s
351/365 fuzz-unit-file:oss-fuzz-6908:address OK 0.05 s
352/365 fuzz-unit-file:oss-fuzz-6917:address OK 0.06 s
353/365 fuzz-unit-file:oss-fuzz-6977:address OK 0.08 s
354/365 fuzz-unit-file:oss-fuzz-6977-unminimized:address OK 0.10 s
355/365 fuzz-unit-file:oss-fuzz-7004:address OK 0.03 s
356/365 fuzz-unit-file:oss-fuzz-8064:address OK 0.03 s
357/365 fuzz-unit-file:oss-fuzz-8827:address OK 0.50 s
358/365 fuzz-unit-file:proc-sys-fs-binfmt_misc.automount:address OK 0.03 s
359/365 fuzz-unit-file:syslog.socket:address OK 0.03 s
360/365 fuzz-unit-file:systemd-ask-password-console.path:address OK 0.03 s
361/365 fuzz-unit-file:systemd-machined.service:address OK 0.03 s
362/365 fuzz-unit-file:systemd-resolved.service:address OK 0.03 s
363/365 fuzz-unit-file:systemd-tmpfiles-clean.timer:address OK 0.03 s
364/365 fuzz-unit-file:timers.target:address OK 0.03 s
365/365 fuzz-unit-file:var-lib-machines.mount:address OK 0.04 s
This gives us slightly nicer coverage in the normal test run.
When in a git repo, git ls-files is used to get a list of files known to git.
This mirrors what update-man-rules does for man files. Only looking at files
known to git makes it easier to not forget to commit the test file to git,
and also makes bisecting easier if some files are left in repo.
When outside of a git repo, we expect to be unpacked from a tarball, so just
using all files reported by ls is OK.
In the main meson.build file, .source_root() and .current_source_dir() are
equivalent, but it seems more appropriate to use .source_root() when we are appending
a path which is by design relative to repo root.
The justification is the same as for -Dvalgrind: setting config in
meson in this way is easier, because when the value is changed stuff
that should be rebuilt is rebuilt.
fuzz: unify the "fuzz-regressions" directory with the main corpus
There isn't really much need to keep them separate. Anything which is a good
corpus entry can be used as a smoke test, and anything which which is a
regression test can just as well be inserted into the corpus.
The only functional difference from this patch (apart from different paths in
output) is that the regression tests are now zipped together with the rest of
the corpus.
$ meson configure build -Dslow-tests=true && ninja -C build test
...
307/325 fuzz-dns-packet:issue-7888:address OK 0.06 s
308/325 fuzz-dns-packet:oss-fuzz-5465:address OK 0.04 s
309/325 fuzz-journal-remote:crash-5a8f03d4c3a46fcded39527084f437e8e4b54b76:address OK 0.07 s
310/325 fuzz-journal-remote:crash-96dee870ea66d03e89ac321eee28ea63a9b9aa45:address OK 0.05 s
311/325 fuzz-journal-remote:oss-fuzz-8659:address OK 0.05 s
312/325 fuzz-journal-remote:oss-fuzz-8686:address OK 0.07 s
313/325 fuzz-unit-file:oss-fuzz-6884:address OK 0.06 s
314/325 fuzz-unit-file:oss-fuzz-6885:address OK 0.05 s
315/325 fuzz-unit-file:oss-fuzz-6886:address OK 0.05 s
316/325 fuzz-unit-file:oss-fuzz-6892:address OK 0.05 s
317/325 fuzz-unit-file:oss-fuzz-6897:address OK 0.05 s
318/325 fuzz-unit-file:oss-fuzz-6897-evverx:address OK 0.06 s
319/325 fuzz-unit-file:oss-fuzz-6908:address OK 0.07 s
320/325 fuzz-unit-file:oss-fuzz-6917:address OK 0.07 s
321/325 fuzz-unit-file:oss-fuzz-6977:address OK 0.13 s
322/325 fuzz-unit-file:oss-fuzz-6977-unminimized:address OK 0.12 s
323/325 fuzz-unit-file:oss-fuzz-7004:address OK 0.05 s
324/325 fuzz-unit-file:oss-fuzz-8064:address OK 0.05 s
325/325 fuzz-unit-file:oss-fuzz-8827:address OK 0.52 s
Add a simple code of conduct based on ruby community guidelines
This was discussed at the systemd hackfest during ASG2018, and
we agreed to use the Ruby text [1] with the enforcement clause based on
the "contributor covenant". I obviously modified the text where applicable
to refer to systemd.
Helmut Grohne [Thu, 27 Sep 2018 15:17:37 +0000 (17:17 +0200)]
meson: use the host architecture compiler/linker for src/boot/efi
cross building systemd to arm64 presently fails, because the build
system uses plain gcc and plain ld (build architecture compiler and
linker respectively) for building src/boot/efi. These values come from
the efi-cc and efi-ld options respectively. It rather should be using
host tools here.
Fixes: b710072da441 ("add support for building efi modules")
nspawn: when --quiet is passed, simply downgrade log messages to LOG_DEBUG (#10181)
With this change almost all log messages that are suppressed through
--quiet are not actually suppressed anymore, but simply downgraded to
LOG_DEBUG. Previously we did it this way for some log messages and fully
suppressed them for others. With this it's pretty much systematic.
udev/net: add support for the equivalent of "ethtool advertise" to .link files
This work adds support for the equivalent of "ethtool advertise" to .link files?
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030112.html
tests: add a reproducer for an infinite loop in ndisc_handle_datagram
=0 ndisc_router_parse (rt=0x60d000000110) at ../src/libsystemd-network/ndisc-router.c:126
=1 0x000055555558dc67 in ndisc_handle_datagram (nd=0x608000000020, rt=0x60d000000110) at ../src/libsystemd-network/sd-ndisc.c:170
=2 0x000055555558e65d in ndisc_recv (s=0x611000000040, fd=4, revents=1, userdata=0x608000000020) at ../src/libsystemd-network/sd-ndisc.c:233
=3 0x00007ffff63913a8 in source_dispatch (s=0x611000000040) at ../src/libsystemd/sd-event/sd-event.c:3042
=4 0x00007ffff6395eab in sd_event_dispatch (e=0x617000000080) at ../src/libsystemd/sd-event/sd-event.c:3455
=5 0x00007ffff6396b12 in sd_event_run (e=0x617000000080, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3512
=6 0x0000555555583f5c in LLVMFuzzerTestOneInput (data=0x6060000000e0 "\206", size=53) at ../src/fuzz/fuzz-ndisc-rs.c:422
=7 0x0000555555586356 in main (argc=2, argv=0x7fffffffe3d8) at ../src/fuzz/fuzz-main.c:33
emergency: make sure console password agents don't interfere with the emergency shell
If for any reason local-fs.target fails at startup while a password is
requested by systemd-cryptsetup@.service, we end up with the emergency shell
competing with systemd-ask-password-console.service for the console.
This patch makes sure that:
- systemd-ask-password-console.service is stopped before entering in emergency
mode so it won't make any access to the console while the emergency shell is
running.
- systemd-ask-password-console.path is also stopped so any attempts to restart
systemd-cryptsetup in the emergency shell won't restart
systemd-ask-password-console.service and kill the emergency shell.
- systemd-ask-password-wall.path is stopped so
systemd-ask-password-wall.service won't be started as this service pulls
the default dependencies in.
networkd-dhcp6: Set initial value of route to NULL
Start with route set to NULL should there be no route created. Remove
the explicit route_free as the _cleanup_ will take care of that after
the continue;.
William Douglas [Mon, 10 Sep 2018 19:07:29 +0000 (12:07 -0700)]
RFC tmpfiles: Allow configuration to ignore execution errors
This is an implementation that covers making errors encountered when writing
file content optionally fatal. If this is something that folks would want I'll
add handling of this for all the other directives. I'd appreciate suggestions
on how this might better be structured as well (use of a goto fail or such) as
I'm not super happy with the approach.
Let's make sure we convert 16bit values to 32bit before shifting them by
10bit to the left, to avoid overflows.
Let's avoid comparisons between signed literals and unsigned variables,
in particular if the literals are outside of the minimum range C
requires for "int".
Let's avoid a few casts in the function. Also, let's drop the "const"
when returning the string, for similar reasons as strchr() and friends
drop it: so that we don't add a const if the user passes in a non-const
string.
Make bzip2 an optional dependency for systemd-importd
Yes, there are still a lot of users of bzip2, but it's fallen out of
favour after LZMA/xz, which can compress a lot more and often
decompresses faster than bzip2 too.