v252 batch #304
Merged
v252 batch #304
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
==8036==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x4a10bc in __interceptor_realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:85:3
systemd#1 0x4deef1 in realloc (/build/fuzz-unit-file+0x4deef1)
systemd#2 0x7ffa35abfe23 in greedy_realloc /work/build/../../src/systemd/src/basic/alloc-util.c:70:13
systemd#3 0x7ffa35aefad2 in parse_env_file_internal /work/build/../../src/systemd/src/basic/env-file.c:127:38
systemd#4 0x7ffa35af08a6 in parse_env_file_fdv /work/build/../../src/systemd/src/basic/env-file.c:374:13
systemd#5 0x7ffa35b6391e in parse_extension_release_atv /work/build/../../src/systemd/src/basic/os-util.c:323:16
systemd#6 0x7ffa35b63c8a in parse_extension_release_sentinel /work/build/../../src/systemd/src/basic/os-util.c:360:13
systemd#7 0x7ffa35a5e3f5 in parse_os_release_specifier /work/build/../../src/systemd/src/shared/specifier.c:292:13
systemd#8 0x7ffa35a5e3f5 in specifier_os_id /work/build/../../src/systemd/src/shared/specifier.c:303:16
systemd#9 0x7ffa35a5c7f5 in specifier_printf /work/build/../../src/systemd/src/shared/specifier.c:70:45
systemd#10 0x7ffa3690b279 in unit_full_printf_full /work/build/../../src/systemd/src/core/unit-printf.c:264:16
systemd#11 0x7ffa367de795 in config_parse_bus_name /work/build/../../src/systemd/src/core/load-fragment.c:2401:13
systemd#12 0x7ffa358fe5ec in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:151:24
systemd#13 0x7ffa358fe5ec in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:257:16
systemd#14 0x7ffa358fd653 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:400:21
systemd#15 0x4de828 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/core/fuzz-unit-file.c:72:16
systemd#16 0x4df208 in NaloFuzzerTestOneInput (/build/fuzz-unit-file+0x4df208)
systemd#17 0x4fe213 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
systemd#18 0x4fd9fa 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
systemd#19 0x4ff0c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
systemd#20 0x4ffd95 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
systemd#21 0x4ef0ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
systemd#22 0x4ef9c8 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
systemd#23 0x4df485 in main (/build/fuzz-unit-file+0x4df485)
systemd#24 0x7ffa35232082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
DEDUP_TOKEN: __interceptor_realloc--realloc--greedy_realloc
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
Found by Nallocfuzz.
(cherry picked from commit 6c13a39)
(cherry picked from commit b4c9a9b)
If we fail any allocation prior adding the lease to the server lease
hashmap.
==2103==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x4a203e in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
systemd#1 0x4f6341 in calloc (/build/fuzz-dhcp-server+0x4f6341)
systemd#2 0x4ec818 in add_lease /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-server.c:26:9
systemd#3 0x4ec2bf in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-server.c:75:9
systemd#4 0x4f68a8 in NaloFuzzerTestOneInput (/build/fuzz-dhcp-server+0x4f68a8)
systemd#5 0x5158b3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
systemd#6 0x51509a 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
systemd#7 0x516769 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
systemd#8 0x517435 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
systemd#9 0x50679f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
systemd#10 0x507068 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
systemd#11 0x4f6b25 in main (/build/fuzz-dhcp-server+0x4f6b25)
systemd#12 0x7f16084e3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
DEDUP_TOKEN: __interceptor_calloc--calloc--add_lease
SUMMARY: AddressSanitizer: 128 byte(s) leaked in 2 allocation(s).
Found by Nallocufzz.
(cherry picked from commit aca607d)
(cherry picked from commit 18e08a4)
The kernel may be syncing a file system or doing something else that requires more time. So make the delay a bit longer, but provide some feedback and also grow the delay exponentially (though with a long exponent). If the kernel is doing something else, no need to repeat so often. With 38 attempts, we get a total of slightly above 5000 ms. I wrote this when I thought that the the delay is not long enough. It turned out that we were blocking the file system on the loop device, so waiting longer wasn't helpful. But I think it's nicer to do it this way anyway. (cherry picked from commit afbe20b) (cherry picked from commit 6e88e59)
All users of loopback_setup() ignore the return values (with the notable exception of the test cases). Hence let's adjust the log messaging to always log at LOG_WARNING level at most, and suffix messages with ", ignoring", to make clear these failures are ignored. (cherry picked from commit 53d883d) (cherry picked from commit 9f87cb2)
In test-execute, only the unit was started, not the slice. Because of that the slice cgroup was pruned even if it was still needed. From what I can tell, this is because, in the test, we don't have all the mechanics that starts the slice for a service. To fix the issue the slice is started manually. (cherry picked from commit fc6172b) (cherry picked from commit 0ff6da9)
We check for homed stuff in the test itself, but this is way too late, since we already started a unit that Requires=systemd-homed.service (testsuite-46.service). For now this doesn't matter, but with #27852 the offending transaction is dropped from the job queue, making the test fail. Spotted in #27852 in Ubuntu CI. (cherry picked from commit 4c709f3) (cherry picked from commit ea24185)
…ring
I'm definitely a fan of precision, but in this case it's a bit too much:
$ systemd-run --unit=test --socket-property=ListenFIFO=/tmp/foo --socket-property=SocketMode=0644 true
$ systemctl cat test.socket
# /run/systemd/transient/test.socket
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=/usr/bin/true
[Socket]
ListenFIFO=/tmp/foo
SocketMode=0000000000000000000000000000000000000644
(cherry picked from commit b86ed7f)
(cherry picked from commit 47edca1)
`sd_journal_print_with_location` and similar functions behave
inconsistently compared to their documentation, which says:
sd_journal_print_with_location(), sd_journal_printv_with_location(),
sd_journal_send_with_location(), sd_journal_sendv_with_location(),
and sd_journal_perror_with_location() [...] accept additional
parameters to explicitly set the source file name, function, and
line. Those arguments must contain valid journal entries including
the variable name, e.g. "CODE_FILE=src/foo.c", "CODE_LINE=666",
"CODE_FUNC=myfunc".
Calling e.g. `sd_journal_sendv_with_location` with
`CODE_FUNC=myfunction` as the value of the argument `func` results in
"CODE_FUNC" : "CODE_FUNC=myfunction"
because `sd_journal_*_with_location` implicitly prefix the argument
`func` with `CODE_FUNC=`. For example:
_public_ int sd_journal_sendv_with_location(
const char *file, const char *line,
const char *func,
const struct iovec *iov, int n) {
[...]
char *f;
[...]
niov = newa(struct iovec, n + 3);
[...]
ALLOCA_CODE_FUNC(f, func);
[...]
niov[n++] = IOVEC_MAKE_STRING(f);
return sd_journal_sendv(niov, n);
}
where `ALLOCA_CODE_FUNC` is:
#define ALLOCA_CODE_FUNC(f, func) \
do { \
size_t _fl; \
const char *_func = (func); \
char **_f = &(f); \
_fl = strlen(_func) + 1; \
*_f = newa(char, _fl + 10); \
memcpy(*_f, "CODE_FUNC=", 10); \
memcpy(*_f + 10, _func, _fl); \
} while (false)
The arguments `file` and `line` are _not_ prefixed similarly but
expected to be prefixed already with `CODE_FILE=` and `CODE_LINE=`
respectively and sent as is like the documentation describes.
That is, the argument `func` is treated differently and behaves
inconsistently compared to the arguments `file` and `line`. The behavior
seems still intentional:
_public_ int sd_journal_printv_with_location(int priority, const char *file, const char *line, const char *func, const char *format, va_list ap) {
[...]
/* func is initialized from __func__ which is not a macro, but
* a static const char[], hence cannot easily be prefixed with
* CODE_FUNC=, hence let's do it manually here. */
ALLOCA_CODE_FUNC(f, func);
[...]
}
Thus, change the documentation to match the actual behavior.
Note: `sd_journal_{print,send}` and `sd_journal_{print,send}v` work as
expected as they only pass the function name (i.e. without `CODE_FUNC=`)
to the `func` argument of the `sd_journal_*_with_location` functions
they call. For example:
#define sd_journal_print(priority, ...) sd_journal_print_with_location(priority, "CODE_FILE=" __FILE__, "CODE_LINE=" _SD_STRINGIFY(__LINE__), __func__, __VA_ARGS__)
(cherry picked from commit 673ed95)
(cherry picked from commit 121bbb5)
==1==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x7fc096c7243b in strdup (/lib64/libasan.so.8+0x7243b)
systemd#1 0x7fc095db3899 in bus_socket_set_transient_property ../src/core/dbus-socket.c:386
systemd#2 0x7fc095db5140 in bus_socket_set_property ../src/core/dbus-socket.c:460
systemd#3 0x7fc095dd20f1 in bus_unit_set_properties ../src/core/dbus-unit.c:2473
systemd#4 0x7fc095d87d53 in transient_unit_from_message ../src/core/dbus-manager.c:1025
systemd#5 0x7fc095d8872f in method_start_transient_unit ../src/core/dbus-manager.c:1112
systemd#6 0x7fc0944ddf4f in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406
systemd#7 0x7fc0944e7854 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319
systemd#8 0x7fc0944e8f03 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439
systemd#9 0x7fc09454ad78 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3011
systemd#10 0x7fc09454b302 in process_running ../src/libsystemd/sd-bus/sd-bus.c:3053
systemd#11 0x7fc09454e158 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3273
systemd#12 0x7fc09454e2f2 in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3300
systemd#13 0x7fc094551a59 in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3642
systemd#14 0x7fc094727830 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187
systemd#15 0x7fc094731009 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808
systemd#16 0x7fc094732124 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869
systemd#17 0x7fc095f7af9f in manager_loop ../src/core/manager.c:3242
systemd#18 0x41cc7c in invoke_main_loop ../src/core/main.c:1937
systemd#19 0x4252e0 in main ../src/core/main.c:3072
systemd#20 0x7fc092a4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 17 byte(s) leaked in 1 allocation(s).
(cherry picked from commit f8b21a0)
(cherry picked from commit 98d2a09)
Some options were renamed and some options with default values are not shown unless -d(etails) is repeated. See: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=1215e9d3862387353d8672296cb4c6c16e8cbb72 (cherry picked from commit a5e478b) (cherry picked from commit 67aaab3)
When we request an address that already exists and is under removing, we need to wait for the address being removed. Otherwise, configuration of a route whose preferred source is the address will fail. Fixes #28009. Replaces #28088. (cherry picked from commit 6e8477e) (cherry picked from commit ea05cd2)
When the credential dir is backed by an fs that supports ACLs we must be more careful with adjusting the 'x' bit of the directory, as any chmod() call on the dir will reset the mask entry of the ACL entirely which we don't want. Hence, do a manual set of ACL changes, that only add/drop the 'x' bit but otherwise leave the ACL as it is. This matters if we use tmpfs rather than ramfs to store credentials. (cherry picked from commit f76ce81) (cherry picked from commit ee3ed28)
quality_check_password() used to return the same value 0 in two different cases: when pwq_allocate_context() failed with a ERRNO_IS_NOT_SUPPORTED() code, and when pwquality_check() rejected the password. As result, users of quality_check_password() used to report password weakness also in case when the underlying library was not available. Fix this by changing quality_check_password() to forward the ERRNO_IS_NOT_SUPPORTED() code to its callers, and change the callers to handle this case gracefully. (cherry picked from commit 7fc3f9c) (cherry picked from commit 9ebacd3)
As logging password suggestions might leak sensitive information, print it instead. Suggested-by: Yu Watanabe <[email protected]> (cherry picked from commit 0351d56) (cherry picked from commit ff63a08)
Some distributions still use glibc's libcrypt. In that case, libcrypt.pc does not exist and dependency() will fail. Also, even if libxcrypt is used, there may not be a symlink from libcrypt.pc to libxcrypt.pc. So, let's add a secondary name. Follow-up for d625f71. Fixes #28289. [ fixed to fallback to extra dependency() call as multiple deps require meson 0.60 ] (cherry picked from commit 5557378) (cherry picked from commit 087b9a7)
git restore -s origin/main hwdb.d/ test/hwdb.d test/hwdb-test.sh (cherry picked from commit 04e0ed9)
github-actions
bot
added
documentation
hwdb
journal
network
portable
resolve
udev
units
labels
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.