Yu Watanabe [Tue, 1 Feb 2022 04:00:51 +0000 (13:00 +0900)]
network: xfrm: refuse zero interface ID
Since kernel 5.17-rc1, 5.16.3, and 5.15.17 (more specifically,
https://github.com/torvalds/linux/commit/8dce43919566f06e865f7e8949f5c10d8c2493f5)
the kernel refuses to create an xfrm interface with zero ID.
Yu Watanabe [Sun, 30 Jan 2022 20:04:52 +0000 (05:04 +0900)]
sd-dhcp-lease: fix reading unaligned memory
The destination address was read twice, one is for prefixlen, and
other is for destination address itself. And for prefixlen, the address
might be read from unaligned buffer.
Frantisek Sumsal [Mon, 31 Jan 2022 13:19:09 +0000 (14:19 +0100)]
test: copy portable profiles into the image if they don't exist there
If we're built with `-Dportable=false`, the portable profiles won't get
installed into the image. Since we need only the profile files and
nothing else, let's copy them into the image explicitly in such case.
Frantisek Sumsal [Mon, 31 Jan 2022 16:11:06 +0000 (17:11 +0100)]
test: use ~/.bashrc instead of /etc/bash.bashrc
/etc/bash.bashrc appears to be Debian-specific[0] (or specific to bash
versions compiled with -DSYS_BASHRC), which doesn't seem to be the case
for C8S. Let's use ~/.bashrc instead to make the CIs happy again.
Luca Boccassi [Fri, 28 Jan 2022 22:56:10 +0000 (22:56 +0000)]
core: don't fail on EEXIST when creating mount point
systemd[1016]: Failed to mount /tmp/app1 (type n/a) on /run/systemd/unit-extensions/1 (MS_BIND ): No such file or directory
systemd[1016]: Failed to create destination mount point node '/run/systemd/unit-extensions/1': File exists
James Hilliard [Mon, 31 Jan 2022 02:33:55 +0000 (19:33 -0700)]
meson: set minimum clang/llvm versions for bpf support
The minimum clang/llvm-strip version needed for building libbpf based
programs is 10.0.0, this is documented here:
https://github.com/libbpf/libbpf/tree/v0.6.1#bpf-co-re-compile-once--run-everywhere
Using an older version such as 9.0.0 will generate objects that
bpftool will not be able to generate skeletons for.
This fixes the following build fail on current Fedora Rawhide:
```
../src/basic/meson.build:389:8: ERROR: Problem encountered: found unknown filesystem(s) defined in kernel headers:
Filesystem found in kernel header but not in filesystems-gperf.gperf: CIFS_SUPER_MAGIC
Filesystem found in kernel header but not in filesystems-gperf.gperf: SMB2_SUPER_MAGIC
```
Davide Cavalca [Sun, 30 Jan 2022 17:28:52 +0000 (09:28 -0800)]
hwdb: add new database file for PDA devices
Add a new database for handhelds (PDAs, calculators, etc.) that should be
accessible the seat owner.
The database is initially populated with Texas Instruments calculators
and linking cables, which removes the need to installing dedicated udev
rules for them.
Donald Chan [Fri, 28 Jan 2022 22:53:46 +0000 (22:53 +0000)]
basic: mac_[selinux,smack]_apply_fd does not work when applying labels
Commit a7fdc6c introduced a regression where file descriptors are opened
using O_PATH option. mac_smack_apply_fd() calls fsetxattr() and would fail
with a -EBADF (Bad file descriptor) error.
Use FORMAT_PROC_FD_PATH(fd) to convert the fd back into a full path and
call setxattr() or setfilecon() instead.
The idea behind this action is to make it possible to compare the
latest fuzz targets with PRs to figure out whether bugs are really
reproducible in PRs only. Since forks (including systemd-stable) are
usually based on the upstream repository where almost all the bugs
are fixed before releases are cut it should be safe to assume that
if CFLite finds bugs in PRs they are most likely introduced in those
PRs.
It should probably be brought back once https://github.com/google/clusterfuzzlite/issues/84
is fixed.
Dmitry V. Levin [Sat, 29 Jan 2022 20:00:00 +0000 (20:00 +0000)]
tmpfiles: avoid double specifier expansion in L lines
Starting with commit 2f3b873a4973, when the path contains a specifier
and the argument is omitted, tmpfiles used to perform specifier
expansions twice: first specifier expansion was applied to the path
itself, and afterwards the result of the first expansion was used
in the constructed argument and expanded once again.
Resolves: #26244 Fixes: 2f3b873a4973 ("tmpfiles: copy/link /usr/share/factory/ files when the source argument is omitted")
Dmitry V. Levin [Thu, 27 Jan 2022 20:00:00 +0000 (20:00 +0000)]
tmpfiles: fix specifier expansion in arguments of C lines
Make sure the argument of "C" type undergoes specifier expansion
before it's checked for validity. In particular, starting with
commit ce610af143b2, the check for path existence used to fail
in case of presence of any specifier in the argument.
Also, starting with commit 2f3b873a4973, when the path contains
a specifier and the argument is omitted, tmpfiles used to perform
specifier expansions twice: first specifier expansion was applied
to the path itself, and afterwards the result of the first expansion
was used in the constructed argument and expanded once again.
Finally, starting with commit 849958d1ba35, when the argument begins
with %h specifier, tmpfiles used to complain that the source path
is not absolute.
Resolves: #25381 Fixes: ce610af143b2 ('tmpfiles: in C lines, make missing source graceful error') Fixes: 2f3b873a4973 ('tmpfiles: copy/link /usr/share/factory/ files when the source argument is omitted') Fixes: 849958d1ba35 ('tmpfiles: add new "C" line for copying files or directories')
ci: use CFLite to test forks (including systemd-stable)
It's like CIFuzz but unlike CIFuzz it's compatible with forks and
it should make it possible to run the fuzzers to make sure that
patches backported to them are backported correctly without introducing
new bugs and regressions.
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
Turns out that part of systemd isn't covered by any fuzz targets and
that's not ideal considering that it parses data sent remotely. The
fuzzer triggers an infinite loop in lease_parse_routes as soon as it
starts so it seems to be working :-)
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 23620602
INFO: Loaded 2 modules (182073 inline 8-bit counters): 176548 [0x7fdf511fc8d0, 0x7fdf51227a74), 5525 [0x5f6ef0, 0x5f8485),
INFO: Loaded 2 PC tables (182073 PCs): 176548 [0x7fdf51227a78,0x7fdf514d94b8), 5525 [0x5f8488,0x60ddd8),
./build/fuzz-dhcp-client: Running 1 inputs 1 time(s) each.
Running: test/fuzz/fuzz-dhcp-client/timeout-ed34161922c7075c4773f2ada3dee8685d220980
ALARM: working on the last Unit for 31 seconds
and the timeout value is 30 (use -timeout=N to change)
==80731== ERROR: libFuzzer: timeout after 31 seconds
#0 0x51b32e in __sanitizer_print_stack_trace (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51b32e)
#1 0x4689e9 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x4689e9)
#2 0x44a0f4 in fuzzer::Fuzzer::StaticAlarmCallback() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a0f4)
#3 0x7fdf4f8b474f (/lib64/libc.so.6+0x4274f)
#4 0x465fee in __sanitizer_cov_trace_const_cmp4 (/home/vagrant/systemd/build/fuzz-dhcp-client+0x465fee)
#5 0x57eee5 in lease_parse_routes /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:495:23
#6 0x57baf3 in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:701:21
#7 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#8 0x571cea in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:381:21
#9 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#10 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:78:9
#11 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#12 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#13 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#14 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#15 0x7fdf4f89f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#16 0x7fdf4f89f60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#17 0x421fd4 in _start (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421fd4)
The general approach of kernel-install was that each plugin would drop in some
files into the entry directory. But this doesn't scale well, because if we have
multiple initrd generators, or multiple initrds, each generator would need to
recreate the logic to put the generated files in the right place.
Also, effective cleanup is impossible if anything goes wrong on the way, so we
could end up with unused files in $BOOT.
So let's invert the process: plugins drop files into $KERNEL_INSTALL_STAGING_AREA,
and at the end 90-loaderentry.install DTRT with those files.
This allow new plugins like 50-mkosi-initrd.install to be significantly simpler.
kernel-install: prefix errors with "Error:", exit immediately
kernel-install would continue after errors… We don't want this, as it
makes the results totally unpredicatable. If we didn't install the kernel
or didn't do some important part of the setup, let's just return an error
and let the user deal with it.
When looking at output, the error was often hard to distinguish, esp.
with -v. Add "Error:" everywhere to make the output easier to parse.