sd_bus_message_append() returns 0 on success, but the convert helpers are
expected to return 1 when the assignment was handled. Returning 0 here was
harmless for callers that only check for errors, but it is inconsistent with
the other helpers and it would trip the new serialization test.
(cherry picked from commit 5b578462bc66795ea7f3a20ff1d21e0ae2afee28)
The test only constructs messages locally and never sends them, so a real
connection is not needed. Create the bus with sd_bus_new() and fake the state,
like test-bus-util does, so that the test is never skipped when no bus is
available.
(cherry picked from commit 970993efbebb6a302417b593a3935f28bab7c192)
RestrictRealtime= only filtered sched_setscheduler(). sched_setattr()
can switch a task to SCHED_FIFO and SCHED_RR as well, and is the only
way to get SCHED_DEADLINE, so a process that is otherwise allowed to use
realtime scheduling (CAP_SYS_NICE, or a non-zero RLIMIT_RTPRIO) could
bypass the restriction.
The policy is passed in a struct sched_attr by pointer, which seccomp
cannot inspect, so refuse the syscall altogether. This also affects
non-realtime callers of sched_setattr() (nice, utilization clamps),
which now get the same error as the refused policies. Document this in
systemd.exec(5) and extend the test.
CPUSchedulingPolicy= is applied through sched_setattr(), so a service
manager running under RestrictRealtime=yes (e.g. in a container) could
no longer start units with a non-realtime policy. Fall back to
sched_setscheduler() on EPERM, which the filter still allows for these
policies. This is not possible with CPUSchedulingResetOnFork=yes, as the
filter refuses SCHED_RESET_ON_FORK too, so setting the policy still
fails in that case.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
(cherry picked from commit 590ff29a641a4ddb736ea59303af9721fc6c1400)
varlinkctl no longer stays silent if an object is empty, and that broke
some tests
(cherry picked from commit 8904b844a43e21530d82a39bbd51c3d9847e5426)
Previously, sd-varlink was inconsistent about what it did with
empty/missing/null parameters in a Varlink call or reply: when
dispatching to a callback, it would always construct an empty object and
hand over the empty object to the handler (good!). But when returning
the value directly (i.e. with sd_varlink_call), it would return NULL
when parameters were omitted and a JSON null when the paramerters were
null.
This inconsistency is a violation of UAPI.20, which states that
receivers of Varlink messages MUST treat omitted/null/empty parameters
on Varlink calls and replies equivalently, where senders only SHOULD
prefer to omit the parameters.
This commit makes sd-varlink normalize the parameters to an empty object
whenever it is null or omitted, which brings sd-varlink into compliance
with this rule in UAPI.20
(cherry picked from commit 34db99971e728e2c4f155c01d43d24f3fe313bef)
This mirrors SD_JSON_FORMAT_EMPTY_ARRAY
We also removed the assertion that a non-null variant is passed into
sd_json_variant_format. It _is_ actually valid to pass a null variant
through to sd_json_variant_dump. If neither SD_JSON_FORMAT_EMPTY_* flag
is set, then sd_json_variant_format will simply return an empty string.
The removal of the assertion fixes a crash in 'varlinkctl --exec call'
(cherry picked from commit 7e70352bf10c2fad0099f69e0c451ff1ce8dc362)
musl libc got a overhaul in it's locale support funded by NLnet,
as part the default search paths were set to search in
/etc/musl/locale, /usr/share/musl/locale, /share/musl/locale/.
Also change the behaviour on musl to search for multiple directories,
and include the old path as a fallback.
See https://www.openwall.com/lists/musl/2026/10/02/1
(cherry picked from commit 0f655ffc7b3318abae41869ca192e1817586a985)
Since being online is a privileged operation, it’s better to fail-safe
and make the `Context` offline by default unless explicitly initialised
(e.g. with `context_from_cmdline()` or an explicit initialisation of
`.offline = false`).
There are a few instances where `.offline = true` is set explicitly.
I’ve left those in place, even though they’re now redundant, as
documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
(cherry picked from commit 97183383af03279c43d9c270af5832d36d527d01)
Currently, `CONTEXT_NULL` initialises `.offline` to false, so helper
contexts are being accidentally run in online mode. Fix that.
The following commit will rework this to be safe by default, but let’s
fix the individual instances first.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
(cherry picked from commit 4212fba4a4258a19057642d13a0ae52181675e23)
I’m about to refactor it slightly and it would be nice to have a little
test coverage to check against.
(cherry picked from commit 8433ed1c7a66ee575621cde027a890017769252c)
The domain and protocol arguments of socket() are ints, but are passed
to the kernel in 64-bit registers, and the kernel truncates them to the
low 32 bits. The rule that makes socket(AF_NETLINK, *, NETLINK_AUDIT)
fail compared the full 64-bit registers with SCMP_CMP_EQ, so setting any
bit above bit 31 in either argument let an audit socket be created.
Use SCMP_CMP_MASKED_EQ with a 32-bit mask for both comparisons.
Follow-up for #44134
Signed-off-by: Ricardo Branco <rbranco@suse.de>
(cherry picked from commit 03e27922cae696af7a15b5375e1820e868284286)
The nstype argument of setns() is an int, but it is passed to the kernel
in a 64-bit register, and the kernel truncates it to the low 32 bits.
The rule that blocks setns() with nstype == 0 compared the full 64-bit
register with SCMP_CMP_EQ, so setting any bit above bit 31 let the call
through, and the kernel then joined whichever namespace the fd referred
to, even one that RestrictNamespaces= is supposed to deny.
Use SCMP_CMP_MASKED_EQ with a 32-bit mask so we match on the same value
the kernel does.
Add a test that issues setns() via syscall() with an upper bit set.
Follow-up for #44134
Signed-off-by: Ricardo Branco <rbranco@suse.de>
(cherry picked from commit da72537164910f9050793055fef030711c00b954)
The domain argument of socket() is an int, but it is passed to the kernel
in a 64-bit register, and the kernel truncates it to the low 32 bits.
The deny-list rules we install compared the full 64-bit register with
SCMP_CMP_EQ, so setting any bit above bit 31 (e.g. AF_VSOCK | 1UL << 32)
let a denied family through unfiltered.
Use SCMP_CMP_MASKED_EQ with a 32-bit mask so we match on the same value
the kernel does.
The allow-list path is not affected: it relies on the LT/GT range checks,
which compare as unsigned 64-bit, so values with upper bits set are
always rejected.
Add a test that issues socket() via syscall() with an upper bit set.
Fixes: #44134
Signed-off-by: Ricardo Branco <rbranco@suse.de>
(cherry picked from commit 62eb6cd8eab6a35a408b2c6547526645bda55ffa)
Data and field objects are only ever appended, and a new object is
always linked after the current tail of its hash chain, so a valid
next_hash_offset is either 0 or larger than the offset of the object
itself. A new data object is also prepended to the list of data objects
of its field, so a valid next_field_offset is always smaller than the
offset of the object itself. Nothing checks either of these when an
object is read, so if a chain loops back on itself, everything that
walks it loops forever:
- "journalctl --verify" spins in data_object_in_hash_table() instead of
reporting the file as corrupted,
- journal_file_punch_holes() never returns when the file is archived,
so it is never offlined,
- sd_journal_enumerate_fields() returns the same field over and over,
so "journalctl --fields" never finishes,
- sd_journal_enumerate_unique() returns the same value over and over,
so "journalctl -F FIELD" never finishes.
A single flipped bit in next_hash_offset or next_field_offset is enough
for any of these.
Check both in check_object(), like we already do for
next_entry_array_offset, so that all readers are covered.
(cherry picked from commit a1bf29afbeed5e4c702f58ea5a9038e433c99c11)
Since a couple of days the pcrlock subtest fails intermittently on
debian-testing and arch CI runs (unrelated PRs: #44152 and others), with
"systemd-pcrlock is-supported" printing "partial" and exiting with 97,
i.e. TPM2_SUPPORT_FIRMWARE is missing.
The console output of the affected boots shows that the TPM already
breaks down while the firmware runs:
EFI stub: WARNING: Failed to measure data for event 1: 0x8000000000000007
EFI stub: WARNING: Failed to measure data for event 0: 0x8000000000000007
i.e. the TCG2 protocol is there, but all measurements fail with
EFI_DEVICE_ERROR, systemd-stub reports no active PCR banks in
LoaderTpm2ActivePcrBanks, and ConditionSecurity=measured-os is hence
false for the whole boot. pcrlock can't do anything useful in that case,
so let's skip the subtest instead of failing, and log what
"systemd-analyze has-tpm2" reports so that this remains visible.
(cherry picked from commit 09fdbf4d715e962cc13fd678760754e59d0aeeaf)
dir_cleanup() stores the result of xstatx_full() in r, which is also the
function's return value. If a file is removed between readdir() and
statx(), it is skipped, but when it was the last entry r stays -ENOENT
and --clean fails with EX_CANTCREAT without logging anything. A
successful statx() also overwrote errors recorded for earlier entries.
Use a separate variable for the statx() result.
Reproducer:
d=$(mktemp -d)
echo "d $d - - - 1d" >$d.conf
while :; do touch $d/f{1..200}; rm -f $d/f*; done &
for i in $(seq 200); do systemd-tmpfiles --clean $d.conf; echo $?; done | sort | uniq -c
kill %1
Before:
177 0
23 73
After:
200 0
Follow-up for a98a6eb95c.
Follow-up for 10072d8be4.
(cherry picked from commit 4c250e3f1325f91cdee047f7daeaf532abe4af6f)
When namespace_enter_full() is called with namespaces that the current
process is already a part of, skip the setns() call on the user
namespace. This allows the function to succeed without CAP_SYS_ADMIN.
Follow-up for 211c3c9d41
(cherry picked from commit 27b1fd3a1e2e6c28bb09ec79cb3dc949a4ba416d)
tpm2_parse_luks2_json() only insists on "tpm2_pubkey" being present when
"tpm2_pubkey_pcrs" is set, but happily accepts a token carrying
"tpm2_pubkey_ref" without a public key. tpm2_unseal() then trips over its
assert(!pubkey_policy_ref || iovec_is_set(pubkey)), i.e. a crafted LUKS2
header aborts whatever tries to unlock it instead of being rejected.
tpm2_make_luks2_json() never writes that combination (it asserts the same
invariant), hence refuse it when parsing, as is already done for a PCR
mask without a public key. This matters more now that systemd-dissect,
systemd-nspawn and systemd-sysext unlock images via these tokens, as the
headers they see are less trusted than the host's own volumes.
(cherry picked from commit 3520b44f7e398f924c267ee4527941924297c6bc)
Since 7da67c3f8b ("vconsole-setup: skip setfont(8) when the console
driver lacks font support") font_load_and_wait() probes the font with
KDFONTOP before running setfont(8). The kernel returns EINVAL for a vc
that is not in KD_TEXT, which is not treated as "no font support", so
systemd-vconsole-setup now fails with
Failed to check '/dev/tty1' has font support: Invalid argument
when run on an explicitly specified vc that a graphical splash (e.g.
plymouth) occupies, for instance from a unit ordered after getty@tty1.
Previously setfont(8) silently ignored this case: verify_source_vc()
accepts it with a notice that the font settings likely won't be applied,
and setup_remaining_vcs() skips such vcs. Do the same here, skip the
font setup and still load the keymap.
(cherry picked from commit 4a3ece0b733d41eab9baad25648c8a921c590ed2)
The tag separator can only appear as the last path component, hence
start the search there.
Fixes an issue reproducible through:
```
> /usr/lib/systemd/systemd-pull oci quay.io:443/fedora/fedora fedora-without-tag
OCI ref 'quay.io:443/fedora/fedora' is invalid.
```
(cherry picked from commit fe9fe613d92f2acffdf3f8b96d3af027f19d6b7e)
GetMemberships with both keys only filtered groupName and could return
other members.
Reproduce with a non-member and a group that has members:
varlinkctl call --more SOCKET io.systemd.UserDatabase.GetMemberships
'{"userName":"nonmember","groupName":"GROUP","service":"io.systemd.Multiplexer"}'
(cherry picked from commit 2126abeb6d4905f95b963c7f5c5bc4bd92444ba5)
If sources are already pending, sd_event_prepare() calls
sd_event_wait(e, 0). Since fd69f22475 this returns 0 when a ratelimit
expiry callback was invoked, so that sources re-enabled by the callback
are evaluated in the next iteration. However, sd_event_prepare() then
returned 0 ("nothing pending"), so sd_event_run() blocked in epoll_wait()
forever, as the pending sources never make the epoll fd readable.
PID 1 can hit this via the ratelimited mount event source, which hangs
the boot, e.g. in the initrd after sysroot.mount.
Fix this by remembering in the sd_event object that a ratelimit expiry
callback was invoked in this iteration. In that case sd_event_wait()
reports the loop as pending, and sd_event_dispatch() returns right away
without dispatching anything, so that the caller goes directly for
sd_event_prepare() again, and no other callback is dispatched in the
same iteration.
Add a test that reproduces the issue.
Follow-up for fd69f22475.
Fixes#44107
(cherry picked from commit 1a60b10de9e4a3fe59a2efa3c6a58fd72c305807)
NvPCRs persist across boots, so on almost every boot NV_DefineSpace()
failed with TPM2_RC_NV_DEFINED before we fell back to reusing the
index, and the TSS logged that as an error. Check for an existing
index first and only define a new one if there is none.
Signed-off-by: Paul Meyer <katexochen0@gmail.com>
(cherry picked from commit 3c59c8daec12c445f446237c260594e4f5eb6b34)
Pass the digest of the init branch to the NvPCR define and write policy
helpers instead of the PCR public key and policy ref, bundle what is
needed to satisfy the init branch into a struct, and split opening the
write session into an init and an extend variant. No functional change.
This prepares for supporting a second kind of init policy.
Signed-off-by: Paul Meyer <katexochen0@gmail.com>
(cherry picked from commit 13c417c1faa372a5c7f32d01385f741bc6e5cf57)
THe limits are hit with valid configurations, hence raise the limits
4x.
Fixes: #44125
(cherry picked from commit 116981d536f52279715df266098bf3093037fc3f)
Since dac2b39405 ("compress: strictly check if stream finished on
decompress") the gzip branch of decompressor_push() no longer loops
"while (avail_in > 0)", but loops until inflate() can make no further
progress, so that we can properly detect truncated streams and trailing
garbage. This means inflate() may now be called with no input left.
If a previous iteration happened to fill the output buffer exactly
(avail_out == 0) while also consuming the last input byte (avail_in ==
0), we go around once more, and inflate() then has nothing to do and
returns Z_BUF_ERROR. This is documented zlib behaviour and not an error
condition: it merely indicates that no progress was possible. However,
we treated anything other than Z_OK/Z_STREAM_END as a corrupted stream
and returned -EBADMSG, hence valid gzip data was refused whenever the
input chunk boundaries happened to line up with the output buffer size
in this way.
Accept Z_BUF_ERROR if all input has been consumed, and let the existing
avail_in/avail_out check that follows decide whether we are done with
the current input, or whether the stream is truncated (in the size == 0
finalization case). If input is left, Z_BUF_ERROR still results in
-EBADMSG, so that we never loop forever without making progress.
Whether the boundary condition is hit depends on the data being
decompressed and on how it is chunked. This showed up in CI here:
https://github.com/systemd/systemd/actions/runs/38428217767/job/115403151687?pr=44163
Add a test that decompresses incompressible data split at every offset
around COMPRESS_PIPE_BUFFER_SIZE, which reliably triggers the condition
for gzip, and checks the other algorithms the same way for good measure.
Follow-up for: dac2b39405
(cherry picked from commit 4128feb9f29e01ccd1f6b7594acc4af579ba4534)
EV_EFI_HANDOFF_TABLES and EV_EFI_HANDOFF_TABLES2 are both defined with
the same name.
(cherry picked from commit 195a17c59b22f5b0fa626fdb4917107cdc281bac)
The order of fds in fdstore may not be preserved.
Set a name for the stored fd, then find the fd by name.
(cherry picked from commit b5372aef629c12266d9a87bafcb1192c697e5d86)
- if 'set +e' is called in a trap (except for EXIT), then call
'set -e' at the end.
- added several missing cleanups.
(cherry picked from commit a7de35462a3df6a30e7eba2d36d1b8bd2fd92aaf)
"systemctl is-system-running --wait" installs a match rule for the
StartupFinished signal, but never calls the manager's Subscribe()
method. PID 1 broadcasts manager signals unconditionally only on direct
(private) bus connections; on the API bus it emits them only while at
least one client is subscribed (see bus_foreach_bus()).
When run as non-root, systemctl talks to PID 1 via the system bus and
only receives StartupFinished if some unrelated client happens to be
subscribed at that moment. Otherwise it keeps waiting after boot has
completed, even though the system state is already "running" or
"degraded".
Call Subscribe() after installing the match and before querying the
current state, so the signal cannot be missed in between. This is a
no-op on direct connections, and the subscription is dropped
automatically when the connection closes.
Fixes: #44150
(cherry picked from commit 9ac5e0b4ee9e87d9ce671a70354dbab2b06c254b)
Then, added explanations for the missing arguments. Also mentioned that
the memfd is sealed by the function.
(cherry picked from commit 20604d980057da1a606339fb7a660242e8d2db02)
sd_bus_message_append_array_memfd() and
sd_bus_message_append_string_memfd() are public functions, hence the
passed fd may be already sealed by the caller. Let's gracefully handle
such case.
(cherry picked from commit 16025762d9055ec56694e4a1d74344029061b7c2)
Previously, readlink_malloc() was used to find the target device.
However, devlink is a relative symbolic link, hence the path obtained by
readlink_malloc() never matched with the one by sd_device_get_devname().
Also path_startswith(target, "/dev/") was always negative.
Let's use chase_and_stat() to obtain the absolute path to the target
device that the devlink currently points to.
Fixes the following spurious logs on remove event:
(udev-worker)[2338]: loop1p1: Processing device (SEQNUM=2231, ACTION=remove)
(udev-worker)[2338]: Notify message sent to '@4814750286313953891': "INOTIFY_WATCH_REMOVE=1"
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/udevtest/x2' points to '../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/udevtest/x2', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-diskseq/9-part1' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-diskseq/9-part1', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-label/udevtest-b-fs1' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-label/udevtest-b-fs1', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-uuid/221d135f-7bf7-45b8-abeb-d9b3afb2c215' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-uuid/221d135f-7bf7-45b8-abeb-d9b3afb2c215', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-partlabel/udevtest-b-part1' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-partlabel/udevtest-b-part1', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/udevtest/b1' points to '../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/udevtest/b1', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/udevtest/x1' points to '../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/udevtest/x1', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-partuuid/5ef627b6-95f1-a942-8d7a-bd4ac53485ac' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-partuuid/5ef627b6-95f1-a942-8d7a-bd4ac53485ac', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/udevtest/b3' points to '../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/udevtest/b3', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-loop-inode/0:36-13-part1' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-loop-inode/0:36-13-part1', removing
(udev-worker)[2338]: loop1p1: Symbolic link '/dev/disk/by-loop-ref/\x2ftmp\x2fudevtest-b.img-part1' points to '../../loop1p1' which is outside of '/dev/', updating it.
(udev-worker)[2338]: loop1p1: No reference left for '/dev/disk/by-loop-ref/\x2ftmp\x2fudevtest-b.img-part1', removing
(udev-worker)[2338]: loop1p1: Device processed (SEQNUM=2231, ACTION=remove)
(cherry picked from commit 03a65741d77d61929b98977d1bfdf2b470e14b55)
A verity signature partition carries a JSON object that must be followed by
NUL bytes only, up to the end of the partition (dissect refuses anything
else). The split-out artifact repart generates for it however is trimmed of
that padding since b54ef83414, so that it is a plain JSON text file (which
jq nowadays insists on).
sysupdate installs such a file into a partition by simply writing it at the
partition's offset, leaving whatever follows in place. Hence, once a shorter
signature (e.g. after rotating to a different key type) is installed into a
partition that previously held a longer one, the tail of the old signature
survives right after the new JSON object, and the partition becomes
unparsable.
Add a new PartitionZeroFill= boolean setting to the [Target] section, which
makes the importer continue writing zeroes up to the end of the partition
once the payload has been written, by passing --zero-fill= to systemd-import
and systemd-pull. It defaults to off, except for verity signature partitions
(which are tiny, hence this is cheap) where it defaults to on.
Fixes: #43567
(cherry picked from commit d3b6d765a5b320d6d864591c6a7b87e1047d0c78)
When writing a raw image into a section of an existing file or block device
(i.e. with --offset= and --size-max=, as sysupdate does when updating a
partition), we so far wrote precisely as many bytes as the payload was
large, leaving whatever followed in the destination range untouched. For
some payloads that's a problem: a verity signature partition for example
must carry NUL bytes only after the JSON object, and if a shorter signature
is written over a longer one, the tail of the old one survives.
Add a --zero-fill= boolean switch to both "systemd-import raw" and
"systemd-pull raw", which fills up the remainder of the destination range
(from the end of the payload up to --size-max=) with zeroes once the payload
has been written, via blockdev_zero_out(). It defaults to off, and requires
both --offset= and --size-max= to be specified.
(cherry picked from commit aff5aff407d421fbedc9eb0229c40996ca5570a1)
blockdev_zero_out() overwrites a byte range of a block device (or a regular
file, e.g. a disk image) with zeroes. On block devices we try to let the
kernel do the work via BLKZEROOUT, which it might be able to offload to the
device. That ioctl operates on whole sectors only however, hence incomplete
sectors at the beginning and the end of the range are filled with explicit
zeroes, and only the aligned middle part is handed to the ioctl. If that
fails, explicit zeroes are written for that part too. On regular files a
hole is punched instead (which reads back as zeroes and keeps the file
sparse), falling back to explicit zeroes if the file system doesn't support
that.
(cherry picked from commit eb98b03118f27f33d3834ef8322f38391eb2c238)
On kernels lacking CLONE_INTO_CGROUP sd-executor is forked into the
service manager's cgroup, logs a few messages from there, and only then
attaches itself to the unit's cgroup and connects stdout/stderr to
journald. Since we cache client metadata per PID and only refresh it
after 1s, log output on such a stream was attributed to init.scope
rather than to the unit, and hence "journalctl -u" (and thus
"systemd-run -v", "systemctl -v start", "systemctl -v wait") would not
show it.
Hence, if a stream tells us the unit it belongs to, and that doesn't
match what we have cached, refresh the cached data.
(cherry picked from commit 44a9316bf49967164567a7c716b79af7edf53d03)
The job map owns its keys, but the error path added in commit 1d0a8e5dbd
only frees the value when it unregisters the job. Free the key as well,
like dispatch_pending_job() does.
Signed-off-by: Martin Pitt <martin@amutable.com>
(cherry picked from commit 67b4f43a54f29b3c0fd5a455b4f956613eae8668)
Jörg Behrmann
Zbigniew Jędrzejewski-Szmek
Ricardo Branco
Adrian Vovk
Achill Gilgenast
Ivan Kruglov
Philip Withnall
Armaan Sandhu
Lennart Poettering
Daniel Sedlak
Nick
Skye Soss
Adrian Reber
Egor Ignatov
Siteshwar Vashisht
lucia-huang7
xinlongchen
Paul Meyer
Chris Coulson
Yu Watanabe
Alexandru N. Onea
Martin Pitt