Many *at()-style helpers accept a directory fd that may be either a
regular, valid fd (>= 0) or one of the special AT_FDCWD/XAT_FDROOT
wildcard values, and open-code that check in their assertions. Add a
wildcard_fd_is_valid() helper for it and use it tree-wide.
When both --private-users and --network-namespace-path are
specified, systemd-nspawn fails to start with "Operation not
permitted" during the setns() call.
This occurs because of the following execution sequence:
1. The outer child calls raw_clone() with CLONE_NEWUSER to create
the new user namespace.
2. The inner child is spawned inside this new user namespace.
3. The inner child then attempts to call setns() to join the
external network namespace.
Because the inner child is already running inside
the restricted user namespace, the kernel rejects
the setns() call to join a network namespace owned by
a different (host/more privileged) user namespace.
Fix this by moving the setns() call to the outer child, executing it
just before the raw_clone() call. This ensures the network namespace
is joined while the process still has the necessary privileges, which
also aligns with the inner child's expectation that the network
namespace is already set up upon entry.
The file name of the reproducer is used for test name, and the test name
is messed when the file name is too long.
Also, the mentioned issues are not regressions, but long standing bugs.
Follow-up for 73fea38cf1.
Fixes a family of OOB reads in the trie walker where attacker-controlled
offsets are loaded from a (possibly hostile) hwdb.bin and added to
hwdb->map without first checking that the resulting pointer stays inside
the mapping. Crash sites:
- trie_fnmatch_f sd-hwdb.c:187 (#42340)
- trie_search_f sd-hwdb.c:233 (#42341)
- trie_children_cmp_f /bsearch sd-hwdb.c:94 (#42342)
- hwdb_add_property sd-hwdb.c:121 (#42343)
- trie_node_from_off (UBSAN) sd-hwdb.c:83
- trie_fnmatch_f stack overflow on cyclic children (CIFuzz finding)
Commit b45a897edc ("hwdb: reject out-of-bounds fnmatch prefixes")
plugged the first site only at the prefix_off-content level, but the
crash on the read of node->prefix_off itself still happens when node is
already OOB. This is the structural fix: a single hwdb_at() helper
validates that [off, off + size) lies inside the mapping, and
trie_node_from_off() / trie_string() return NULL on OOB; every caller
treats the result as nullable and surfaces -EBADMSG.
trie_fnmatch_f() additionally caps its recursion depth at 2048; without
the cap a corrupt trie whose child offsets form a cycle (or just a deep
linear chain) drives the parser into stack-overflow rather than
returning -EBADMSG (caught by CIFuzz address sanitizer on this branch).
Additions:
- A fuzz-hwdb libFuzzer harness that drives sd_hwdb_new_from_path,
sd_hwdb_get, sd_hwdb_seek, and sd_hwdb_enumerate on attacker bytes.
- Five hand-crafted unit tests in test-sd-hwdb.c (one per crash
bucket, plus the cyclic-trie recursion case) that build a malformed
in-memory hwdb.bin and assert -EBADMSG rather than SIGSEGV /
stack-overflow.
- Regression corpus files under test/fuzz/fuzz-hwdb/ pinning each
fixed bucket, including the CIFuzz stack-overflow reproducer.
Closes#42340.
Closes#42341.
Closes#42342.
Closes#42343.
Reported-by: AI-assisted libFuzzer campaign
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
test_oomd_cgroup_context_acquire_and_insert sets c1->pgscan = UINT64_MAX
and c1->last_had_mem_reclaim = 888 before re-inserting via
oomd_insert_cgroup_context(h1, h2, cgroup), then asserts that c2 carries
over last_had_mem_reclaim == 888.
The assumption was that, because c1->pgscan (which becomes c2->last_pgscan)
is UINT64_MAX and is therefore strictly greater than the freshly-acquired
c2->pgscan, oomd_pgscan_rate() in oomd_insert_cgroup_context() would
return 0 and leave last_had_mem_reclaim untouched. But the function
treats last_pgscan > pgscan as "cgroup was recreated", resets last_pgscan
to 0, and returns pgscan - 0 == pgscan. So when the kernel records any
non-zero pgscan on the live cgroup of the test unit, the rate is > 0 and
last_had_mem_reclaim is overwritten with now(CLOCK_MONOTONIC).
From src/oom/oomd-util.c:
uint64_t oomd_pgscan_rate(const OomdCGroupContext *c) {
[...]
last_pgscan = c->last_pgscan;
if (c->last_pgscan > c->pgscan) {
log_debug("Last pgscan %"PRIu64" greater than current pgscan %"PRIu64" for %s. Using last pgscan of zero.",
c->last_pgscan, c->pgscan, c->path);
last_pgscan = 0;
}
return c->pgscan - last_pgscan;
}
int oomd_insert_cgroup_context(Hashmap *old_h, Hashmap *new_h, const char *path) {
[...]
if (oomd_pgscan_rate(curr_ctx) > 0)
curr_ctx->last_had_mem_reclaim = now(CLOCK_MONOTONIC);
Under sanitizers the test can be slow enough that the kernel scans the
test service cgroup at least once between the two acquisitions, which
triggers the failure:
[ 1898.159455] test-oomd-util[2606]: /* test_oomd_cgroup_context_acquire_and_insert */
[ 1898.161247] test-oomd-util[2606]: Last pgscan 18446744073709551615 greater than current pgscan 2 for /system.slice/test-oomd-util.service. Using last pgscan of zero.
[ 1898.161330] test-oomd-util[2606]: src/oom/test-oomd-util.c:322: Assertion failed: Expected "c2->last_had_mem_reclaim == 888u", but 1898161250 != 888
(1898161250 matches the monotonic timestamp of the log line, confirming
that last_had_mem_reclaim was overwritten with now(CLOCK_MONOTONIC).)
The propagation of last_had_mem_reclaim is already covered
deterministically by TEST(oomd_update_cgroup_contexts_between_hashmaps),
which builds OomdCGroupContext structs directly with matching pgscan
values so that oomd_pgscan_rate() returns exactly 0. So just drop the
racy setup and assertion here.
Follow-up for df637ede7b
Fixes https://github.com/systemd/systemd/issues/38543
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Reject malformed RSA DNSKEY data before reading the extended exponent
header, and add a regression test.
Co-developed-by: GitHub Copilot (GPT 5.5) <copilot@github.com>
If this runs on a slow or busy machine, then we may not get enough
pressure to trigger the event sources. In such case, the test does not
finish. It is problematic when the test is _not_ run with 'meson test',
e.g. debian/ubuntu CIs.
Let's introduce a timeout for each event loop, and skip test cases
gracefully.
I got infos from product_name:
$ cat /sys/class/dmi/id/product_name
X+ Piccolo
Turns out the modalias has a little difference:
$ cat /sys/class/dmi/id/modalias
dmi:bvnAmericanMegatrendsInternational,LLC.:bvr5.27:bd09/10/2025:br5.27:svnX-Plus.tech:pnX+Piccolo:pvrDefaultstring:rvnX-Plus:rnXPLUS-SERIES81x-DEV:rvrDefaultstring:cvnDefaultstring:ct10:cvrDefaultstring:skuSeries81x:pfaPiccoloSeries:
So let's remove the extra space. Crossing fingers... 🤞
Fixes: 033be1a41b
When rename_netif() failed for a reason other than -EBUSY (e.g. -EEXIST
because NAME= conflicts with an existing interface), the revert path
rewrote the on-disk udev database from dev_db_clone (the pre-rules
snapshot) and then returned the error. The caller in
udev_event_execute_rules() bailed out before reaching the final
device_update_db(dev), so every property the rules had attached to the
device during this event (including ENV{}= assignments made alongside
the failing NAME=) was silently dropped from /run/udev/data/.
Persist 'dev' from inside the revert block, after its syspath and
INTERFACE have been restored. The cloned snapshot is still written
first to clear ID_RENAMING/ID_PROCESSING; the subsequent dev write
keeps the rule-applied properties without resurrecting the new name.
Only persist when r < 0, since the -EBUSY path returns success and the
caller will write the DB itself.
Add a TEST-17-UDEV.rename-netif regression test that pre-creates the
rename target, then triggers rules that set three ENV{}= properties
(one on a rule line before the failing NAME=, one on the same line as
NAME=, and one on a rule line after) and asserts all three are still
visible via udevadm info on the source interface. The neighbouring
test_netif_renaming_conflict already exercises the same -EEXIST revert
path but only checks the SYSTEMD_ALIAS broadcast, which is why this
regression went unnoticed.
Verified against unpatched origin/main (b4aff10ac0): the new test
fails, udevadm reports only kernel-supplied fields for the source
interface, and /run/udev/data/n<ifindex> is 0 bytes. With this patch
applied all three properties survive regardless of whether they were
set before, on, or after the failing NAME= rule line.
Downstream impact (NetworkManager managing an interface that rules had
marked NM_UNMANAGED=1): https://redhat.atlassian.net/browse/RHEL-178481
Fixes: https://github.com/systemd/systemd/issues/42331
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
This reverts commit 62e17483aa.
The failure should be caused by PATH_TEST() macro introduced by
fc7a32df38 and QMP_TEST() macro by
742733440f, and now they are dropped.
The workaround should not be necessary anymore.
Similar to the previous commit for test-path.
The macro confuses gcc/gcov/lcov:
```
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_qmp_client_basic_body at
/home/runner/work/systemd/systemd/src/test/test-qmp-client.c:204:
204 -> 224 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-qmp-client.p/src_test_test-qmp-client.c.gcno
```
The macro itself is not bad, but does not reduce lines so much.
Let's stop using the macro.
The macro was introduced by fc7a32df38,
but unfortunately gcc/gcov/lcov are confused by the macro:
```
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_path_exists_body at
/home/runner/work/systemd/systemd/src/test/test-path.c:158:
158 -> 185 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-path.p/src_test_test-path.c.gcno
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
```
The macro deos nothing spurious, hence it should be a bug in gcc.
But, the macro just reduces the lines for calling setup_test(), and
does not simplify test cases so much.
Let's call it in each test cases, and stop using the macro.
Unit-level Condition…= / Assert…= directives that fail prevent activation
entirely, so SuccessAction= / FailureAction= never fire. An ExecCondition=
skip in [Service] runs as part of the activation transition itself, so
the unit goes active → inactive and SuccessAction= is honored.
This asymmetry has tripped users up; document it explicitly in both
systemd.service(5) (ExecCondition= section) and systemd.unit(5)
(SuccessAction= / FailureAction= section) with cross-references.
Fixes: https://github.com/systemd/systemd/issues/42035
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
It has been failing for a few days:
```
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_path_exists_body at /home/runner/work/systemd/systemd/src/test/test-path.c:158: 158 -> 185 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-path.p/src_test_test-path.c.gcno
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
```
The systemd-oomd-defaults rpm installed on Fedora/CentOS images via
mkosi/mkosi.conf.d/centos-fedora/mkosi.conf ships
/usr/lib/systemd/system/system.slice.d/10-oomd-per-slice-defaults.conf:
[Slice]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=80%
https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c10s/10-oomd-per-slice-defaults.conf
In a recent flaky CI run on centos-10, the following sequence was
recorded in test/journal/TEST-55-OOMD-1.journal:
[ 77.740597] systemd-oomd[659]: Memory pressure for /system.slice is 85.03% > 80.00% for > 2s with reclaim activity
[ 77.745326] TEST-55-OOMD.sh[1292]: + journalctl --sync
[ 77.749125] systemd-oomd[659]: Considered 19 cgroups for killing, top candidates were:
[ 77.749128] systemd-oomd[659]: Path: /system.slice/systemd-journald.service
[ 77.749134] systemd-oomd[659]: Current Memory Usage: 55.5M
[ 77.749597] systemd-oomd[659]: oomd attempting to kill 407 with KILL
[ 77.749670] systemd-oomd[659]: Marked /system.slice/systemd-journald.service for killing due to memory pressure for /system.slice being 85.03% > 80.00% for > 2s with reclaim activity
[ 77.752252] systemd[1]: systemd-journald.service: systemd-oomd killed 1 process(es) in this unit.
[ 77.752293] systemd[1]: systemd-journald.service: Changed running -> stop-sigterm
[ 329.922401] systemd[1]: systemd-journald.service: Main process exited, code=killed, status=9/KILL
PID 1292 (the test script) never logged anything after the
`journalctl --sync` line at [77.745326], and the unit stayed in
stop-sigterm until [329.922401].
Override /system.slice to ManagedOOMMemoryPressure=auto in the test
setup so the test does not rely on whichever per-slice oomd defaults
the distro happens to ship.
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_path_exists_body at /home/runner/work/systemd/systemd/src/test/test-path.c:158: 158 -> 185 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-path.p/src_test_test-path.c.gcno
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
Other places that read credentials filer out ENXIO:
$ journalctl -b -u systemd-imds-early-network.service -o short-monotonic --no-hostname --no-pager -p warning
[ 5.477675] systemd-imdsd[473]: Failed to read credential 'imds.vendor', ignoring: No such device or address
[ 5.477687] systemd-imdsd[473]: Failed to read credential 'imds.vendor_token', ignoring: No such device or address
[ 5.477693] systemd-imdsd[473]: Failed to read credential 'imds.refresh_header_name', ignoring: No such device or address
[ 5.477699] systemd-imdsd[473]: Failed to read credential 'imds.data_url', ignoring: No such device or address
[ 5.477704] systemd-imdsd[473]: Failed to read credential 'imds.data_url_suffix', ignoring: No such device or address
[ 5.477710] systemd-imdsd[473]: Failed to read credential 'imds.token_header_name', ignoring: No such device or address
[ 5.477714] systemd-imdsd[473]: Failed to read credential 'imds.extra_header', ignoring: No such device or address
[ 5.477720] systemd-imdsd[473]: Failed to read credential 'imds.extra_header2', ignoring: No such device or address
[ 5.477730] systemd-imdsd[473]: Failed to read credential 'imds.extra_header3', ignoring: No such device or address
[ 5.477736] systemd-imdsd[473]: Failed to read credential 'imds.extra_header4', ignoring: No such device or address
[ 5.477742] systemd-imdsd[473]: Failed to read credential 'imds.extra_header5', ignoring: No such device or address
[ 5.477747] systemd-imdsd[473]: Failed to read credential 'imds.extra_header6', ignoring: No such device or address
[ 5.477751] systemd-imdsd[473]: Failed to read credential 'imds.extra_header7', ignoring: No such device or address
[ 5.477757] systemd-imdsd[473]: Failed to read credential 'imds.extra_header8', ignoring: No such device or address
[ 5.477763] systemd-imdsd[473]: Failed to read credential 'imds.extra_header9', ignoring: No such device or address
[ 5.477768] systemd-imdsd[473]: Failed to read credential 'imds.extra_header10', ignoring: No such device or address
[ 5.477774] systemd-imdsd[473]: Failed to read credential 'imds.extra_header11', ignoring: No such device or address
[ 5.477779] systemd-imdsd[473]: Failed to read credential 'imds.extra_header12', ignoring: No such device or address
[ 5.477784] systemd-imdsd[473]: Failed to read credential 'imds.extra_header13', ignoring: No such device or address
[ 5.477789] systemd-imdsd[473]: Failed to read credential 'imds.extra_header14', ignoring: No such device or address
[ 5.477799] systemd-imdsd[473]: Failed to read credential 'imds.extra_header15', ignoring: No such device or address
[ 5.477804] systemd-imdsd[473]: Failed to read credential 'imds.extra_header16', ignoring: No such device or address
[ 5.477810] systemd-imdsd[473]: Failed to read credential 'imds.extra_header17', ignoring: No such device or address
[ 5.477815] systemd-imdsd[473]: Failed to read credential 'imds.extra_header18', ignoring: No such device or address
[ 5.477820] systemd-imdsd[473]: Failed to read credential 'imds.extra_header19', ignoring: No such device or address
[ 5.477825] systemd-imdsd[473]: Failed to read credential 'imds.extra_header20', ignoring: No such device or address
[ 5.477830] systemd-imdsd[473]: Failed to read credential 'imds.extra_header21', ignoring: No such device or address
[ 5.477835] systemd-imdsd[473]: Failed to read credential 'imds.extra_header22', ignoring: No such device or address
[ 5.477840] systemd-imdsd[473]: Failed to read credential 'imds.extra_header23', ignoring: No such device or address
[ 5.477845] systemd-imdsd[473]: Failed to read credential 'imds.extra_header24', ignoring: No such device or address
[ 5.477851] systemd-imdsd[473]: Failed to read credential 'imds.extra_header25', ignoring: No such device or address
[ 5.477856] systemd-imdsd[473]: Failed to read credential 'imds.extra_header26', ignoring: No such device or address
[ 5.477865] systemd-imdsd[473]: Failed to read credential 'imds.extra_header27', ignoring: No such device or address
[ 5.477869] systemd-imdsd[473]: Failed to read credential 'imds.extra_header28', ignoring: No such device or address
[ 5.477874] systemd-imdsd[473]: Failed to read credential 'imds.extra_header29', ignoring: No such device or address
[ 5.477881] systemd-imdsd[473]: Failed to read credential 'imds.extra_header30', ignoring: No such device or address
[ 5.477885] systemd-imdsd[473]: Failed to read credential 'imds.extra_header31', ignoring: No such device or address
[ 5.477890] systemd-imdsd[473]: Failed to read credential 'imds.extra_header32', ignoring: No such device or address
[ 5.477896] systemd-imdsd[473]: Failed to read credential 'imds.extra_header33', ignoring: No such device or address
[ 5.477901] systemd-imdsd[473]: Failed to read credential 'imds.extra_header34', ignoring: No such device or address
[ 5.477906] systemd-imdsd[473]: Failed to read credential 'imds.extra_header35', ignoring: No such device or address
[ 5.477913] systemd-imdsd[473]: Failed to read credential 'imds.extra_header36', ignoring: No such device or address
[ 5.477917] systemd-imdsd[473]: Failed to read credential 'imds.extra_header37', ignoring: No such device or address
[ 5.477922] systemd-imdsd[473]: Failed to read credential 'imds.extra_header38', ignoring: No such device or address
[ 5.477931] systemd-imdsd[473]: Failed to read credential 'imds.extra_header39', ignoring: No such device or address
[ 5.477935] systemd-imdsd[473]: Failed to read credential 'imds.extra_header40', ignoring: No such device or address
[ 5.477940] systemd-imdsd[473]: Failed to read credential 'imds.extra_header41', ignoring: No such device or address
[ 5.477945] systemd-imdsd[473]: Failed to read credential 'imds.extra_header42', ignoring: No such device or address
[ 5.477951] systemd-imdsd[473]: Failed to read credential 'imds.extra_header43', ignoring: No such device or address
[ 5.477956] systemd-imdsd[473]: Failed to read credential 'imds.extra_header44', ignoring: No such device or address
[ 5.477962] systemd-imdsd[473]: Failed to read credential 'imds.extra_header45', ignoring: No such device or address
[ 5.477967] systemd-imdsd[473]: Failed to read credential 'imds.extra_header46', ignoring: No such device or address
[ 5.477972] systemd-imdsd[473]: Failed to read credential 'imds.extra_header47', ignoring: No such device or address
[ 5.477978] systemd-imdsd[473]: Failed to read credential 'imds.extra_header48', ignoring: No such device or address
[ 5.477982] systemd-imdsd[473]: Failed to read credential 'imds.extra_header49', ignoring: No such device or address
[ 5.477988] systemd-imdsd[473]: Failed to read credential 'imds.extra_header50', ignoring: No such device or address
[ 5.477995] systemd-imdsd[473]: Failed to read credential 'imds.extra_header51', ignoring: No such device or address
[ 5.477999] systemd-imdsd[473]: Failed to read credential 'imds.extra_header52', ignoring: No such device or address
[ 5.478022] systemd-imdsd[473]: Failed to read credential 'imds.extra_header53', ignoring: No such device or address
[ 5.478028] systemd-imdsd[473]: Failed to read credential 'imds.extra_header54', ignoring: No such device or address
[ 5.478033] systemd-imdsd[473]: Failed to read credential 'imds.extra_header55', ignoring: No such device or address
[ 5.478039] systemd-imdsd[473]: Failed to read credential 'imds.extra_header56', ignoring: No such device or address
[ 5.478044] systemd-imdsd[473]: Failed to read credential 'imds.extra_header57', ignoring: No such device or address
[ 5.478050] systemd-imdsd[473]: Failed to read credential 'imds.extra_header58', ignoring: No such device or address
[ 5.478055] systemd-imdsd[473]: Failed to read credential 'imds.extra_header59', ignoring: No such device or address
[ 5.478060] systemd-imdsd[473]: Failed to read credential 'imds.extra_header60', ignoring: No such device or address
[ 5.478066] systemd-imdsd[473]: Failed to read credential 'imds.extra_header61', ignoring: No such device or address
[ 5.478071] systemd-imdsd[473]: Failed to read credential 'imds.extra_header62', ignoring: No such device or address
[ 5.478079] systemd-imdsd[473]: Failed to read credential 'imds.extra_header63', ignoring: No such device or address
[ 5.478086] systemd-imdsd[473]: Failed read IPv4 address from credential 'imds.address_ipv4', ignoring: No such device or address
[ 5.478091] systemd-imdsd[473]: Failed read IPv6 address from credential 'imds.address_ipv6', ignoring: No such device or address
[ 5.478097] systemd-imdsd[473]: Failed to read credential 'imds.key_hostname', ignoring: No such device or address
[ 5.478102] systemd-imdsd[473]: Failed to read credential 'imds.key_region', ignoring: No such device or address
[ 5.478107] systemd-imdsd[473]: Failed to read credential 'imds.key_zone', ignoring: No such device or address
[ 5.478113] systemd-imdsd[473]: Failed to read credential 'imds.key_ipv4_public', ignoring: No such device or address
[ 5.478119] systemd-imdsd[473]: Failed to read credential 'imds.key_ipv6_public', ignoring: No such device or address
[ 5.478123] systemd-imdsd[473]: Failed to read credential 'imds.key_ssh_key', ignoring: No such device or address
[ 5.478128] systemd-imdsd[473]: Failed to read credential 'imds.key_userdata', ignoring: No such device or address
[ 5.478134] systemd-imdsd[473]: Failed to read credential 'imds.key_userdata_base', ignoring: No such device or address
[ 5.478137] systemd-imdsd[473]: Failed to read credential 'imds.key_userdata_base64', ignoring: No such device or address
In https://bugzilla.redhat.com/show_bug.cgi?id=2481466, it is reported
that systemd-imds-early-network.service fails on AWS EC2 instance with:
> No IMDS endpoint information provided or detected, cannot operate.
The service will be started on various systems where it doesn't have
enough configuration to run. The systemd-imds-generator only does some
superficial checks, so the tool should not mark the boot as failed
it turns out that IMDS is not supported.
Since a62cd5a153, when an invalid property
is being added, device_add_property() refuses it with -EINVAL.
Before the commit, the function could fail with only -ENOMEM, and if it fails,
processing udev rules was aborted.
Let's not hard fail when udev rules or udev builtins try to add an invalid
property, and let's just log and ignore the failure.
Follow-up for a62cd5a153.
Fixes#41339 and #41296.
* 9cb09470c9 Version 261~rc1
* 7d16ad00bd Fix compilation with openssl 4.0
* 3770fa7c92 Revert "Use dlopen-notes to automatically generate library Recommends/Requires/Suggests"
* 8b3d1726f5 Add back various explit Requires
* d8abb91805 Drop scriptlet workarounds for upgrades from versions < 247
* ee6d0b9d27 Use dlopen-notes to automatically generate library Recommends/Requires/Suggests
* 32a2038627 spec: drop duplicated line
* ab743db0fe Downgrade kbd dependency to Recommends
* 400494ada4 Update conditionals for RHEL 11
This test often fails because the VM reboots (eg: kernel panic) and the
previous state is left unclean. Do the cleanups at the beginning too,
to try and reduce flakiness.
After looking at the unit, I'm not sure if systemd-imds-import.service
is supposed to run in the host system or not. But if it is supposed to
only run in the initrd, then the static condition in the unit file gives
as the worst behaviour: the generator does not do any checks if we are
in the initrd or not, and if it enabled the unit, it'll influence the
transaction ordering (possibly causing loops or additional work) and
then the unit will be unconditionally skipped. So replace the static
condition by a check in the generator. If the user specifies
systemd.imds.import on the commandline, it'll be honoured also in the
host.
The imds services are (very-) early boot services, ordered before
sysinit.target. OTOH, network-online.target is something that is often
established very late [1]. In fact, we always recommended to _not_
depend on it for things that are ordered before the usual targets that
allow user logins (e.g. graphical.target). So we certainly cannot add
early-boot ordering for it. Currently systemd-imds-imports.service
is conditionalized to only run in the initrd. But if the unit is enabled
in the host system, it would affect the transaction there, so we should
drop this bogus ordering everywhere.
(I think this might have been added by mistake. After all,
systemd-imds-import.service itself shouldn't care about the network.)
This fixes boot ordering issues reported upstream and in Fedora [2, 3].
[1] https://systemd.io/NETWORK_ONLINE/#network-connectivity-has-been-established-network-onlinetarget
[2] https://github.com/systemd/systemd/pull/40980#discussion_r2949473028
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2481304
This reverts commit a17efef137 ("test: try to detect SIGILL in stress-ng
and skip TEST-55-OOMD gracefully") and replaces it with a single
check to skip the test cases.
The previous check was not reliable as stress-ng can catch SIGILL
itself and exist with an error:
stress-ng[1068]: stress-ng: debug: [1068] caught SIGILL, address \
0x00005632f8330140 (ILL_ILLOPN)
stress-ng[1068]: stress-ng: debug: [1068] stress-ng: info: \
0x00005632f8330140:<62>71 fd 48 6f 2d 36 14 1c 00 c5 d1 ef ed 49 29
...
stress-ng[1053]: stress-ng: error: [1053] vm: [1061] terminated \
with an error, exit status=2 (stressor failed)
...
systemd[1]: TEST-55-OOMD-slowrule.service: Main process exited, \
code=exited, status=2/INVALIDARGUMENT
systemd[1]: TEST-55-OOMD-slowrule.service: Failed with result \
'exit-code'.
Try to detect at the beginning of the test and skip the test case if it
happens.
di is allocated while iterating over p.partitions. If the array is
empty,
the loop is skipped and di remains NULL, but the code still assigns
image
metadata through it.
Return EBADMSG before accessing di in this case.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Lennart Poettering
Malformed C
Yu Watanabe
Daan De Meyer
jeffhuang
Luca Boccassi
Christian Hesse
Chris Patterson
Frantisek Sumsal
Martin Srebotnjak
Priit Jõerüüt
Henri Aunin
Zbigniew Jędrzejewski-Szmek
Rocker Zhang
nikstur
Mikhail Nogin
