The current check checks for n_sigbus_queue
being greater than or equal to SIGBUS_QUEUE_MAX,
when it should be just greater than as
n_sigbus_queue being SIGBUS_QUEUE_MAX indicates
that the queue is full, but not overflowed.
Distributions apparently only compile a subset of TPM2 drivers into the
kernel. For those not compiled it but provided as kmod we need a
synchronization point: we must wait before the first TPM2 interaction
until the driver is available and accessible.
This adds a tpm2.target unit as such a synchronization point. It's
ordered after /dev/tpmrm0, and is pulled in by a generator whenever we
detect that the kernel reported a TPM2 to exist but we have no device
for it yet.
This should solve the issue, but might create problems: if there are TPM
devices supported by firmware that we don't have Linux drivers for we'll
hang for a bit. Hence let's add a kernel cmdline switch to disable (or
alternatively force) this logic.
Fixes: #30164
Triggering assert_return() should be a bug in general, and we should
really fix that. But, previously, it is hard to notice such bug, as
it was not critical.
This is for making CI or our testing environment fail if we unexpectedly
trigger assert_return(). So, hopefully we can easily find such bugs.
it's not entirely clear to me if the manual NUL termination is
necessary, but let's better be safe than sorry, since this is apparently
up to the LSMs, and I am not sure we can trust them all.
A lot of other code (such as dbus-broker) patches in the NUL byte, hence
let's be rather safe-then-sorry, it's trivial after all.
This is gets the resource limits off a specified process, and is very
similar to prlimit() with a NULL new_rlimit argument. In fact, it tries
that first. However, it then falls back to use /proc/$PID/limits. Why?
Simply because Linux prohibits access to prlimit() for processes with a
different UID, but /proc/$PID/limits still works.
This is preparation to allow nspawn to run unprivileged.
When [Link] MTU= is specified in a .network file, we have no idea about
that what kind of interface will be configured with the .network file.
The maximum and minimum MTU size depend on the kind of interface.
So, we should not filter MTU eagerly in the parser.
Closes#30140.
fuzzers randomly fail with the following:
```
==172==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f41169cb39b in update_argv /work/build/../../src/systemd/src/basic/argv-util.c:96:13
#1 0x7f41169cb39b in rename_process /work/build/../../src/systemd/src/basic/argv-util.c:210:16
#2 0x7f4116b6824e in safe_fork_full /work/build/../../src/systemd/src/basic/process-util.c:1516:21
#3 0x7f4116bffa36 in safe_fork /work/build/../../src/systemd/src/basic/process-util.h:191:16
#4 0x7f4116bffa36 in parse_timestamp /work/build/../../src/systemd/src/basic/time-util.c:1047:13
#5 0x4a61e6 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-time-util.c:16:16
#6 0x4c4a13 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#7 0x4c41fa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#8 0x4c58c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#9 0x4c6595 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#10 0x4b58ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#11 0x4def52 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#12 0x7f4115ea3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: e678fe54a5d2c2092f8e47eb0b33105e380f7340)
#13 0x41f5ad in _start (build-out/fuzz-time-util+0x41f5ad)
DEDUP_TOKEN: update_argv--rename_process--safe_fork_full
Uninitialized value was created by an allocation of 'fv' in the stack frame of function 'have_effective_cap'
#0 0x7f41169d3540 in have_effective_cap /work/build/../../src/systemd/src/basic/capability-util.c:21
```
This should make sure our log lines look nice even if the tty we are
connected to is in raw mode. Normally, it's the TTY's job to turn an NL
we output into a CRNL and interpret it accordingly. However, if the tty
is in "raw" mode it won't do that. Specifically, this is controlled by
the ONLCR flag on the TTY. A TTY might be in raw mode if our "ptyfwd"
logic is used for example, where a 2nd tty is bi-directionally connected
to the primary tty, and duplicate processing is not desired.
Hence, let's just write out the CR on our own. This will make sure that
whenever we output something subsequent output always continues on the
beginning of the next line again, regardless the mode the TTY is in. Of
course, if the TTY is *not* in raw mode, then the extra CR we now
generate is redundant, but it shouldn't hurt either, as it just moves
the cursor to the front of the line even though already is just there.
We only to that if we actually talk to a TTY though, since we don't want
the extra CRs if we are redirected to a pipe or file or so. We are not
on Windows after all.
Fixes: #30155
Mike Yuan
Lennart Poettering
Rose
Frantisek Sumsal
Yu Watanabe
Vladimir Stoiakin
Luca Boccassi