When a slot is disconnected, previously we tried to remove the slot from
the hashmap with a wrong key. Hence, the pointer to the freed slot object
remained in the hashmap.
(cherry picked from commit 6fb1698e3b)
(cherry picked from commit 184238636d)
The cleanup destructor for VarlinkServerSocket only freed ss->address and
the struct, leaking ss->event_source. If sd_varlink_server_listen_address()
hits OOM at free_and_strdup() after the io-source was already armed, the
source stays registered in the event loop with userdata pointing at the
freed socket. Disable it before freeing; the call is a no-op when the
source was never armed, so the other freep sites are unaffected.
Follow-up for c14e841f31
Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit 36562b721e)
(cherry picked from commit 606ec729dd)
bus_message_map_all_properties() fed the peer-supplied wire signature straight
into the variant dispatch and never compared it against the declared
prop->signature, so map_basic() wrote at the wire type's native width into a
slot sized for the declared type (over-wide numeric writes, peer-controlled
pointers into char** slots later freed by strv_free()). Compare against
prop->signature and skip the variant on mismatch.
This is in practice not a problem as the servers are trusted, and this
only affects clients.
Follow-up for 9f6eb1cd58
Assisted-by: kres (claude-opus-4-7)
Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit 39bc1dfa0f)
(cherry picked from commit e537b243ac)
The SoftRebootsCount entry in the boot-times map declared signature "t" but the
manager exports it as "u". The mismatch was harmless while the declared signature
was never checked, but becomes a dropped property once it is enforced. Declare "u".
Follow-up for 259046cfe8
(cherry picked from commit 7cc0f65d63)
(cherry picked from commit d35d1c538b)
The SystemCallFilter entry in the security info map declared signature "(as)" but
its property_read_system_call_filter callback reads a "(bas)" (the manager exports
it as "(bas)"), matching the sibling RestrictAddressFamilies entry. The mismatch was
harmless while the declared signature was never checked, but becomes a dropped
property once it is enforced. Declare "(bas)".
Follow-up for ec16f3b6dd
(cherry picked from commit 7827db326f)
(cherry picked from commit 7fd06b2f3e)
The InvocationID entry in status_map declared signature "s" but its bus_map_id128
callback reads an "ay" (the manager exports it as "ay"), matching the other
bus_map_id128 callers. The mismatch was harmless while the declared signature was
never checked, but becomes a dropped property once it is enforced. Declare "ay".
Follow-up for f1d345ed76
(cherry picked from commit 441514184f)
(cherry picked from commit fec1515923)
The UEFI specification only defines A/C/I/M/Zicsr/Zifencei as mandatory
extensions in boot services. However, on systems with everything built
with F/D support, its difficult to disable F/D without changing a
toolchain. In addition, both EDK2 and U-Boot enable F/D on boot,
although they neither enable nor disable V. EDK2 comments even claim the
enablement of FPU is "to be compliant with UEFI spec" despite the spec
requires dynamic detection before using F/D.
Add corresponding -march flags to prevent systemd-boot from using other
extensions on RISC-V, and a comment for the temporary enablement of F/D.
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
(cherry picked from commit a1190f5c99)
(cherry picked from commit b8923aa654)
The message is stale (this is about UserNamespacePath=, not PrivateUsers=) and
this should be an error, not notice given we are going to fail.
(cherry picked from commit fb1e76c674)
(cherry picked from commit edb7b372d5)
These also need to set exit_status so that sd-executor returns the right
thing to pid1.
(cherry picked from commit bfaecf37cc)
(cherry picked from commit 380a4c95e3)
Originally reported on yeswehack.com as YWH-PGM9780-82
Follow-up for 1e448731f5
(cherry picked from commit 5d31694318)
(cherry picked from commit 913e7288ca)
strv_split_full() returns the number of parsed entries, which was
assigned to r, the variable that also holds the run's exit status.
With TESTFUNCS set, a passing run of only void tests then exited with
the entry count (e.g. 1) instead of EXIT_SUCCESS. Use a separate
variable for the split result.
Before:
$ env TESTFUNCS=test_copy_tree meson test -C build -v test-copy
1/1 test - systemd:test-copy FAIL 0.01s exit status 1
$ env TESTFUNCS=test_copy_tree:test_copy_file_fd meson test -C build -v test-copy
1/1 test - systemd:test-copy FAIL 0.01s exit status 2
Now:
$ env TESTFUNCS=test_copy_tree:test_copy_file_fd meson test -C build -v test-copy
1/1 test - systemd:test-copy OK 0.01s
Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Paul Meyer <katexochen0@gmail.com>
(cherry picked from commit ce31ff043e)
(cherry picked from commit e7e6689ef4)
The test is flaky and times out lately in ppc64el CI runners:
exec-dynamicuser-statedir.service: Control group is empty.
exec-dynamicuser-statedir.service: User lookup succeeded: uid=65325 gid=65325
Test timeout when testing exec-dynamicuser-statedir.service
Bump the timeout also when in a CI, as they are often over subscribed
(cherry picked from commit 3b00327fe6)
(cherry picked from commit 698b2b3073)
`UkifyConfig.sbat` is an optional list, so the default of
`config_set_if_unset` would only accept a single value.
Further, it is defined with an empty list as a default, causing
configuration values to always be ignored, as the default is not
`None`.
Set its `config_push` to `ConfigItem.config_list_prepend` to collect
the `SBAT` lines from the config.
Signed-off-by: Wolfgang Bumiller <w.bumiller@errno.eu>
(cherry picked from commit 345acde398)
(cherry picked from commit 114f963b92)
`ConfigItem.config_list_prepend` assumed that the passed value was a
list. This just happens to be the case for the `--initrd` and
`--devicetree-auto` parameters, as those get special treatment in
`ConfigItem.apply_config` as they use space separated lists.
However, this is not generally the case: When trying to set
`UKI/Firmware` the following error occurred:
Traceback (most recent call last):
File "/usr/bin/ukify", line 2565, in <module>
main()
~~~~^^
File "/usr/bin/ukify", line 2548, in main
opts = UkifyConfig.from_namespace(parse_args())
~~~~~~~~~~^^
File "/usr/bin/ukify", line 2542, in parse_args
apply_config(opts)
~~~~~~~~~~~~^^^^^^
File "/usr/bin/ukify", line 2295, in apply_config
item.apply_config(namespace, section_name, group, key, value)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/ukify", line 1892, in apply_config
self.config_push(namespace, group, dest, value)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/ukify", line 1765, in config_list_prepend
setattr(namespace, dest, value + old)
~~~~~~^~~~~
TypeError: unsupported operand type(s) for +: 'PosixPath' and 'list'
Since we can thus get both lists and strings, check the type and
convert non-list values to `[value]`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@errno.eu>
(cherry picked from commit 5d5f9429fe)
(cherry picked from commit 23b4de703f)
Validate input parameter immediately during initial parsing
Follow-up for 9de5e32136
(cherry picked from commit cde88c4ea3)
(cherry picked from commit 1b2a891e31)
A bind mount inherits the mount flags of the file system the source
directory resides on. For root=bind: the source typically lives below
/run/ (e.g. a freshly unpacked tar image in /run/machines/), which is
mounted nosuid,nodev, so those flags propagated to /sysroot and broke
suid binaries (e.g. sudo) and device nodes on the booted system.
Default bind root mounts to dev,suid,exec instead, unless the user
overrides this via rootflags=.
Fixes: https://github.com/systemd/systemd/issues/41352
Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit b77be9f072)
(cherry picked from commit 413e4f34a7)
keyfile-erase only erases a key file explicitly configured in the third
field of crypttab. Key files automatically discovered in
/etc/cryptsetup-keys.d/ and /run/cryptsetup-keys.d/ are considered shared
resources not owned by an individual volume, and are never erased. Make
this explicit in the documentation and add a code comment clarifying the
intent.
Fixes: https://github.com/systemd/systemd/issues/41127
Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit c280a16ab7)
(cherry picked from commit d10acbe6be)
$ mkdir /var/tmp/files
$ touch /var/tmp/files/a
$ mkdir /var/tmp/conf
$ cat >>/var/tmp/conf/esp.conf
[Partition]
Type=esp
Format=vfat
CopyFiles=/var/tmp/files:/
$ truncate /var/tmp/disk -s 300M
$ sudo systemd-repart --dry-run=no --empty=require --definitions=/var/tmp/conf /var/tmp/disk
...
Populating vfat filesystem.
Failed to copy '...' to '/run/systemd/mount-root/': Operation not permitted
(sd-copy) failed with exit status 1.
The issue is that if there's a file owned by non-root and we try to copy
it into a newly-created DOS partition, fchown fails:
fchown(11</run/systemd/mount-root/...>, 1000, 1000) = -1 EPERM (Operation not permitted)
We want to ignore file ownership in such cases, so pass our own UID/GID
to copy_tree_at(), which turns the fchown into a noop and let's the
operation pass through.
Fixes#38863.
(cherry picked from commit fe2b35bd58)
(cherry picked from commit 3a5c0df5c9)
These asserts don't make sense and actually break the FIDO2 support in
systemd-cryptsetup.
Follow-up for bd141bd818
(cherry picked from commit c6bfcf0977)
(cherry picked from commit 53e5268e06)
2026-05-29T18:00:43.7496388Z ../src/core/dynamic-user.c: In function ‘dynamic_user_realize’:
2026-05-29T18:00:43.7497098Z ../src/core/dynamic-user.c:436:29: error: ‘new_uid’ may be used uninitialized [-Werror=maybe-uninitialized]
2026-05-29T18:00:43.7497758Z 436 | num = new_uid;
2026-05-29T18:00:43.7498026Z | ~~~~^~~~~~~~~
2026-05-29T18:00:43.7498465Z ../src/core/dynamic-user.c:361:23: note: ‘new_uid’ was declared here
2026-05-29T18:00:43.7498802Z 361 | uid_t new_uid;
2026-05-29T18:00:43.7499039Z | ^~~~~~~
2026-05-29T18:00:43.7499315Z In file included from ../src/core/dynamic-user.c:23:
2026-05-29T18:00:43.7499651Z In function ‘dynamic_user_push’,
2026-05-29T18:00:43.7500063Z inlined from ‘dynamic_user_realize’ at ../src/core/dynamic-user.c:453:13:
2026-05-29T18:00:43.7501021Z ../src/basic/socket-util.h:131:63: error: ‘new_uid_lock_fd’ may be used uninitialized [-Werror=maybe-uninitialized]
2026-05-29T18:00:43.7501897Z 131 | #define send_one_fd_iov(transport_fd, fd, iov, iovlen, flags) send_one_fd_iov_sa(transport_fd, fd, iov, iovlen, NULL, 0, flags)
2026-05-29T18:00:43.7502530Z | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2026-05-29T18:00:43.7503145Z ../src/core/dynamic-user.c:320:16: note: in expansion of macro ‘send_one_fd_iov’
2026-05-29T18:00:43.7503647Z 320 | return send_one_fd_iov(d->storage_socket[1], lock_fd, &iov, 1, MSG_DONTWAIT);
2026-05-29T18:00:43.7504027Z | ^~~~~~~~~~~~~~~
2026-05-29T18:00:43.7504397Z ../src/core/dynamic-user.c: In function ‘dynamic_user_realize’:
2026-05-29T18:00:43.7504888Z ../src/core/dynamic-user.c:360:21: note: ‘new_uid_lock_fd’ was declared here
2026-05-29T18:00:43.7505256Z 360 | int new_uid_lock_fd;
2026-05-29T18:00:43.7505511Z | ^~~~~~~~~~~~~~~
2026-05-29T18:00:43.7505882Z ../src/core/dynamic-user.c: In function ‘dynamic_user_current’:
2026-05-29T18:00:43.7506461Z ../src/core/dynamic-user.c:468:15: error: ‘uid’ may be used uninitialized [-Werror=maybe-uninitialized]
2026-05-29T18:00:43.7506895Z 468 | uid_t uid;
2026-05-29T18:00:43.7507096Z | ^~~
2026-05-29T18:26:14.2420944Z In function ‘dynamic_user_push’,
2026-05-29T18:26:14.2421730Z inlined from ‘dynamic_user_realize’ at ../src/core/dynamic-user.c:453:13:
2026-05-29T18:26:14.2435240Z ../src/basic/socket-util.h:131:63: error: ‘new_uid_lock_fd’ may be used uninitialized [-Werror=maybe-uninitialized]
2026-05-29T18:26:14.2440497Z 131 | #define send_one_fd_iov(transport_fd, fd, iov, iovlen, flags) send_one_fd_iov_sa(transport_fd, fd, iov, iovlen, NULL, 0, flags)
2026-05-29T18:26:14.2442511Z | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2026-05-29T18:26:14.2445002Z ../src/core/dynamic-user.c:320:16: note: in expansion of macro ‘send_one_fd_iov’
2026-05-29T18:26:14.2445727Z 320 | return send_one_fd_iov(d->storage_socket[1], lock_fd, &iov, 1, MSG_DONTWAIT);
2026-05-29T18:26:14.2448345Z | ^~~~~~~~~~~~~~~
2026-05-29T18:26:14.2448952Z ../src/core/dynamic-user.c: In function ‘dynamic_user_realize’:
2026-05-29T18:26:14.2451781Z ../src/core/dynamic-user.c:360:21: note: ‘new_uid_lock_fd’ was declared here
2026-05-29T18:26:14.2452287Z 360 | int new_uid_lock_fd;
2026-05-29T18:26:14.2454430Z | ^~~~~~~~~~~~~~~
2026-05-29T18:26:14.2454960Z ../src/core/dynamic-user.c: In function ‘dynamic_user_current’:
2026-05-29T18:26:14.2457632Z ../src/core/dynamic-user.c:468:15: error: ‘uid’ may be used uninitialized [-Werror=maybe-uninitialized]
2026-05-29T18:26:14.2458207Z 468 | uid_t uid;
2026-05-29T18:26:14.2460327Z | ^~~
(cherry picked from commit a46ec24ddb)
(cherry picked from commit 0066a4bbb5)
resolved watches networkd state changes and RTNL updates separately. RTNL is
currently processed at SD_EVENT_PRIORITY_IMPORTANT, while networkd state
changes are processed later at SD_EVENT_PRIORITY_IMPORTANT+5.
If both are pending, an RTM_NEWADDR update can make a link relevant for
LLMNR/mDNS scope allocation before resolved has consumed the corresponding
networkd state update. This can let scope recalculation use stale per-link
settings until the networkd event is processed.
Run the networkd monitor source before RTNL by using
SD_EVENT_PRIORITY_IMPORTANT-5. This lets resolved consume current link settings
before reacting to RTNL address updates in the same event loop iteration.
Fixes#42079
Co-developed-by: OpenAI Codex <noreply@openai.com>
(cherry picked from commit 87b81528a8)
(cherry picked from commit c7483cac7f)
These tests run native tools on foreign ELF files, so they fail,
just skip them when cross-compiling
(cherry picked from commit 595d3d593c)
(cherry picked from commit 1e9c2b0a19)
When the accumulated trie key exceeds the fixed-size line buffer,
linebuf_get() returns NULL. trie_fnmatch_f() passed that NULL straight
into fnmatch() as the pattern, causing a SIGSEGV on a crafted hwdb.bin
(reachable now that recursion is capped rather than overflowing the
stack first). Treat the NULL like the other corruption checks and
return -EBADMSG.
Follow-up for 73fea38cf1
Fixes https://github.com/systemd/systemd/issues/42376
Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit 3db89cbf0e)
(cherry picked from commit 138565f8d6)
When ssh-ing into a VM, you generally do not want to log
in as your user from the host. Let's default to the root
user unless a user is explicitly specified.
(cherry picked from commit 6ec161c5b9)
(cherry picked from commit 7bb2d4af65)
A hostile but structurally valid 382-byte PE32+ "EFI application" with a
single section whose VirtualSize is ~4 GiB and SizeOfRawData is 0 drives
uki_hash() into ~4.17 M iterations of SHA-256 over 1024 bytes of zeros
— wedging the parser for >10 s. Nine more slow-units share the same
shape. A separate MSAN finding from the new fuzzer (CIFuzz, memory
sanitizer) shows pe_load_headers() reading uninitialised heap memory
when SizeOfOptionalHeader is too small to actually contain
NumberOfRvaAndSizes.
Three tightenings in src/shared/pe-binary.c:
1. In pe_load_sections, reject sections whose PointerToRawData +
SizeOfRawData exceeds the actual file size. Raw section data must
fit inside the file; this is the parser-wide invariant
pe_hash / uki_hash / pe_read_section_data rely on.
2. In uki_hash, cap the (VirtualSize - SizeOfRawData) zero-padding
hash loop at 64 MiB. Real UKIs do not pad sections with tens of
MiB of zero-equivalent data; anything above this cap is a
malformed PE.
3. In pe_load_headers, reject a PE whose SizeOfOptionalHeader is too
small to cover up to NumberOfRvaAndSizes. Without this guard the
subsequent size-mismatch check reads uninitialised optional-header
bytes, caught by MSAN under CIFuzz.
Add the 382 B canonical reproducer (plus two structural siblings) and
the MSAN reproducer to test/fuzz/fuzz-pe-binary/. Also add a libFuzzer
harness in src/fuzz/fuzz-pe-binary.c and unit tests in
src/test/test-pe-binary.c that exercise each fix branch in isolation.
The 64 MiB hash boundary test is gated behind SYSTEMD_SLOW_TESTS so it
doesn't slow down emulated-arch CI.
This is a robustness fix, not a security fix: PE binaries consumed by
bootctl / systemd-stub / pcrlock / kernel-install / systemd-measure are
already trusted and signed at the consumer side, so the worst pre-fix
behaviour is wasted CPU on a UKI install / measure / inspect call.
Closes#42344.
Reported-by: AI-assisted libFuzzer campaign
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit 0c5cba6420)
(cherry picked from commit 6b0830b25c)
We currently log at warning level:
/usr/lib/systemd/system/systemd-udevd.service:56: System call bpf cannot be
resolved as libseccomp is not available, ignoring: Operation not supported
In the initrd, or in minimal installations, not installing libseccomp is
reasonable, depending on various other choices. We shouldn't make fuss
about this.
C.f. https://bugzilla.redhat.com/show_bug.cgi?id=2463540.
(cherry picked from commit 97a0ec135b)
(cherry picked from commit bfd3697aed)
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>
(cherry picked from commit 73fea38cf1)
(cherry picked from commit a3189e6e3d)
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>
(cherry picked from commit 6f31db9b07)
(cherry picked from commit 55d0e4aca0)
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>
(cherry picked from commit 004401fd06)
(cherry picked from commit 955eb5f8bb)
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>
(cherry picked from commit 779a3a13ae)
(cherry picked from commit 44275007bd)
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.
(cherry picked from commit e329ef572d)
(cherry picked from commit 75dc008c75)
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.
(cherry picked from commit d096763827)
(cherry picked from commit 42b356b0e0)
When adding new groups, putgrent_with_members() is called with the newly
constructed group n, but the error path logs gr->gr_name. gr belongs to
the
earlier loop over the existing group file and may be NULL after EOF.
Log n.gr_name instead.
Found by Linux Verification Center (linuxtesting.org) with Svace.
(cherry picked from commit f50c3f548b)
(cherry picked from commit 52fbac7c56)
The fix for the corrupted state when units become aliased on reload
leaks the now-aliased unit's resources, which become untracked and
essentially lost.
While fixing the state corruption is of course necessary, leaking
processes/etc. is not ideal for a system and service manager, so
instead attempt to keep track of them by creating stub units
on-the-fly as replacements.
This way resources are not leaked, there are clear indications of
where they moved, and all state can be tracked as expected.
Ignore timers/sockets/paths as those are internal resources/triggers.
Follow-up for a77c7a8224
(cherry picked from commit 4f7089f0c7)
(cherry picked from commit 02b3d7381e)
If a unit has active jobs, when it gets serialized there are job
subsections, each with their own empty line marker. The skipping
function ignores this and skips until the marker, but then leaves
the job in place, breaking deserialization.
Consume jobs subsections too.
This shows up now that there's TEST-07-PID1.alias-corruption,
which occasionally fails when the aliased unit happens to
still have a job when the reexec happens.
[ 967.551630] TEST-07-PID1.sh[179]: + echo 'Testing with: systemctl daemon-reexec'
[ 967.551630] TEST-07-PID1.sh[179]: Testing with: systemctl daemon-reexec
[ 968.405274] TEST-07-PID1.sh[179]: + echo '--- Attempt 1/3 ---'
[ 968.405274] TEST-07-PID1.sh[179]: --- Attempt 1/3 ---
[ 968.698641] TEST-07-PID1.sh[179]: + echo 'Running daemon-reexec...'
[ 968.698641] TEST-07-PID1.sh[179]: Running daemon-reexec...
[ 969.130261] TEST-07-PID1.sh[179]: + echo 'legit.service PID remains 1282. Attempt 1 passed.'
[ 969.130261] TEST-07-PID1.sh[179]: legit.service PID remains 1282. Attempt 1 passed.
[ 970.870456] TEST-07-PID1.sh[179]: + echo '--- Attempt 2/3 ---'
[ 970.870456] TEST-07-PID1.sh[179]: --- Attempt 2/3 ---
[ 971.267205] TEST-07-PID1.sh[179]: + echo 'Running daemon-reexec...'
[ 971.267205] TEST-07-PID1.sh[179]: Running daemon-reexec...
[ 971.715743] TEST-07-PID1.sh[179]: + echo 'legit.service PID changed from 1282 to 1643!'
[ 971.715743] TEST-07-PID1.sh[179]: legit.service PID changed from 1282 to 1643!
Follow-up for a77c7a8224
Follow-up for 0742986650
(cherry picked from commit 4394046ee6)
(cherry picked from commit c7d523d37a)
Four *_attach_event helpers swallow sd_event_default() failures and
return success while leaving obj->event NULL:
sd_dhcp_client_attach_event (sd-dhcp-client.c)
sd_dhcp6_client_attach_event (sd-dhcp6-client.c)
sd_ndisc_attach_event (sd-ndisc.c)
sd_radv_attach_event (sd-radv.c)
Each contains the same copy-pasted typo in the NULL-event branch:
r = sd_event_default(&obj->event);
if (r < 0)
return 0; /* swallows -ENOMEM / -ECHILD */
The caller is told the attach succeeded, but obj->event is still
NULL. A subsequent *_start() then trips assert_return(obj->event,
-EINVAL) and returns a spurious -EINVAL (or aborts on assert-abort
builds), and any consumer of *_get_event() dereferences NULL.
The sibling helper sd_dhcp_server_attach_event already uses the
correct pattern:
r = sd_event_default(&server->event);
if (r < 0)
return r;
Fix by returning r instead of 0 at each of the four sites so the
sd_event_default() errno is propagated to the caller and ownership
stays with the caller.
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason <clm@meta.com>
(cherry picked from commit 3f0aa5852e)
(cherry picked from commit 725e2d205c)
apply_syscall_filter() unconditionally inserts the write() syscall
into c->syscall_filter when exec_fd or handoff_timestamp_fd is in
use, so the parent can receive the exec status / handoff timestamp
from the child. When the unit configured a positive
SystemCallFilter= allow-list that deliberately omits write(), the
resulting widening of the operator's policy happens silently with
no trace in the journal.
Emit a log_debug() before the seccomp_filter_set_add_by_name() call
when syscall_allow_list is true, so the widening is at least
observable to operators inspecting the unit's debug log.
While here, document that mutating c->syscall_filter through a
'const ExecContext *c' is intentional: apply_syscall_filter() runs
only in the post-fork child, which owns a private copy of the
address space, so the hashmap change is never observed by the
manager.
No functional change for the allow-list itself; write() is still
added exactly as before.
Fixes: 84b79215cc ("core: do not filter out write() if required in the very late stage")
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason <clm@meta.com>
(cherry picked from commit 99aff23783)
(cherry picked from commit aa0dd02f45)
apply_root_directory() calls chroot() but never pairs it with a
chdir("/"). Moving cwd into the new root is left to the subsequent
apply_working_directory() call. That delegation breaks when the unit
sets WorkingDirectory=-/path (working_directory_missing_ok):
apply_root_directory() apply_working_directory()
chroot(new_root) --> chdir(wd) fails (ENOENT)
return 0 return 0 /* missing_ok */
chroot(2) changes only the process root, not cwd. With cwd still
resolving to the pre-chroot host dentry, the process runs with the
kernel root pointing at the new root while relative-path accesses
and /proc/self/cwd reach paths outside RootDirectory=.
Only the chroot-only branch (exec_needs_mount_namespace() == false)
is affected. The mount-namespace branch uses pivot_root(), which
restructures the mount tree and makes the pre-chroot dentry
unreachable.
Fix by issuing chdir("/") immediately after the successful chroot()
in apply_root_directory() and propagating any failure with
EXIT_CHROOT, matching the standard chroot+chdir idiom and making
the chroot self-contained regardless of how
apply_working_directory() later handles a missing directory.
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason <clm@meta.com>
(cherry picked from commit 4e02162a6e)
(cherry picked from commit 1209b10ca8)
sd_dhcp6_client_add_option() and sd_dhcp6_client_add_vendor_option()
store the caller's sd_dhcp6_option in an ordered container whose value
destructor is sd_dhcp6_option_unref, registered via
DEFINE_HASH_OPS_WITH_VALUE_DESTRUCTOR in dhcp6_option_hash_ops. The
container therefore owns exactly one ref per stored slot.
Both helpers guarded the ref bump only on r < 0:
r = ordered_{hashmap,set}_ensure_put(..., v);
if (r < 0)
return r;
sd_dhcp6_option_ref(v);
ordered_hashmap_ensure_put() (and the ordered_set wrapper) forward the
underlying hashmap_put_boldly tri-state verbatim: 1 on fresh insert, 0
when the identical key+value pair is already stored (no new slot
allocated), <0 on error. The r == 0 path fell through and bumped the
refcount without a corresponding slot.
The extra ref is permanently stranded once the container's destructor
runs. In a long-running networkd that reapplies .network files on
reload this leaks one sd_dhcp6_option allocation per duplicate-add.
Fix by tightening the guard to r <= 0 in both helpers, so
sd_dhcp6_option_ref(v) is reached only on a genuine new slot (r == 1).
Propagate the tri-valued result by returning r from both helpers
instead of a hard-coded constant.
sd_dhcp6_client_add_vendor_option() is a public libsystemd sd_ API;
its success return changes from a constant 1 to {0, 1}.
sd_dhcp6_client_add_option() now also propagates the tri-valued
result (previously a hard-coded 0 on success), giving the two parallel
helpers identical return contracts.
The sole non-fuzz in-tree callers are both in dhcp6_configure()
(src/network/networkd-dhcp6.c), which treat any r >= 0 as success and
do not distinguish 0 from 1, so the contract widening is caller-safe.
Fixes: e7d5fe17db ("DHCP client: make SendOption work for DHCPv6 too.")
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason <clm@meta.com>
(cherry picked from commit 700d8e73d4)
(cherry picked from commit 48f4863b1c)
Yu Watanabe