IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33881.
Not only we would duplicate unknown input on the stack, we would do it
over and over. So let's first check that the input has reasonable length,
but also allocate just one fixed size buffer.
(cherry picked from commit e17c95af8e450caacde692875b30675cea75211f)
(cherry picked from commit 5172ef4a58bda5be18dcdbbe0abd2c6bb4f08743)
(cherry picked from commit 7e0f374aaca4d964c880d5966811ce2ecfdda94f)
Today this is v248 with 938bdfc0fa737d86eb3ecc70506e11e5f740e0dc, which,
if you don't know about the github webflow key fails to configure with
meson.build:724:8: ERROR: String "gpg: Signature made Tue 30 Mar 2021 22:59:02 CEST\ngpg: using RSA key 4AEE18F83AFDEB23\ngpg: Can't check signature: No public key\n1617137942\n" cannot be converted to int
or, if you do, with
meson.build:724:8: ERROR: String 'gpg: Signature made Tue 30 Mar 2021 22:59:02 CEST\ngpg: using RSA key 4AEE18F83AFDEB23\ngpg: Good signature from "GitHub (web-flow commit signing) <noreply@github.com>" [unknown]\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg: There is no indication that the signature belongs to the owner.\nPrimary key fingerprint: 5DE3 E050 9C47 EA3C F04A 42D3 4AEE 18F8 3AFD EB23\n1617137942\n' cannot be converted to int
(cherry picked from commit 2d945027244c02fab8d388353f034a2d82ca151b)
(cherry picked from commit 964a13d17be3426ecf539a5155e2cb8b4c16fb31)
(cherry picked from commit c37bb626c8eac47ce8614ea0331a2f4f7a43cc76)
(cherry picked from commit ed52cce33f588bbeb3d7f5d7f5e76a85cf6e4f89)
(cherry picked from commit 8b881617609e530b846faa27a32db070536fb0d4)
(cherry picked from commit 50ec6a9ec04da8c76afda2e458f9f3ea1df7727d)
(cherry picked from commit f282ce20aaa767f5395b065f2be587cdef3e5491)
(cherry picked from commit 179a92c9d8b2df688764095ce1d242de20ee72fa)
(cherry picked from commit d1e06f70368ac4b08c2804f3ecfa7cb3ed874fac)
Similar to `ProcessSizeMax`. The defaults in percentages can be misunderstood to mean the values for these parameters will be in percentages.
(cherry picked from commit 88c2c8a0ba13de31061a22a352410c18ffacab9a)
(cherry picked from commit a9ab73ca9f79d0830e71716359a9710fc165ccca)
(cherry picked from commit b761e7e472b41fc82c591f79148af47381c0c6b4)
(cherry picked from commit 96ae72ce1ad41674078e45b197df35ad18041dc2)
(cherry picked from commit 59cde3bba171abfefd8bf25e4ed07d43700c5e84)
(cherry picked from commit 41e4a4f3df5966c9d36e511728dd7ca1c0e4261c)
Otherwise a coredump started at the inconvinient moment can stop
shutdown.target leaving the system in a halfway-down state:
Pulling in shutdown.target/start from systemd-poweroff.service/start
Added job shutdown.target/start to transaction.
...
Keeping job shutdown.target/start because of systemd-poweroff.service/start
...
[ OK ] Stopped target Remote File Systems.
shutdown.target: starting held back, waiting for: systemd-networkd.socket
sysinit.target: stopping held back, waiting for: remount_tmp.service
systemd-coredump.socket: Incoming traffic
...
systemd-coredump@0-243-0.service: Trying to enqueue job systemd-coredump@0-243-0.service/start/replace
Added job systemd-coredump@0-243-0.service/start to transaction.
Pulling in systemd-journald.socket/start from systemd-coredump@0-243-0.service/start
Added job systemd-journald.socket/start to transaction.
Pulling in system.slice/start from systemd-journald.socket/start
Added job system.slice/start to transaction.
Pulling in -.slice/start from system.slice/start
Added job -.slice/start to transaction.
Pulling in system-systemd\x2dcoredump.slice/start from systemd-coredump@0-243-0.service/start
Added job system-systemd\x2dcoredump.slice/start to transaction.
Pulling in system.slice/start from system-systemd\x2dcoredump.slice/start
Pulling in shutdown.target/stop from system-systemd\x2dcoredump.slice/start
Added job shutdown.target/stop to transaction.
...
Keeping job systemd-poweroff.service/stop because of umount.target/stop
Keeping job shutdown.target/stop because of systemd-coredump@0-243-0.service/start
(cherry picked from commit 4e947bd04944e58df4103eee4cb8180b5008f143)
(cherry picked from commit e11d3ec13c1ee7af65893e94d09d8b3b66cd99c9)
(cherry picked from commit c8491deca6911eda63b9f06172d2c956762ba1b6)
(cherry picked from commit e558d4f47a9c01b007fc193cabcf0dea8370a5f1)
(cherry picked from commit 0881deb1951a55701cf6ea743132458459e3a650)
(cherry picked from commit b91e1cde447d08b8a72102b08e23cfefdd62601f)
The error is harmless, and will be ignored. Let's downgrade log level.
(cherry picked from commit 83e7c37b19bd36c78b235ac3047b758fcf82ad78)
(cherry picked from commit 1db3be80337b79e3b9afda9d50c61e6aed5aff28)
(cherry picked from commit 23f2ff3143317022f61a15397e6f2178d46126a2)
We were duplicating setting flags for the message and a combination of
NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
dynamically create neighbors prior to us adding an entry. Otherwise, we
can end up with cases where the message will time out after ~25s even
though the neighbor still gets added. This delays the rest of the setup
of the interface even though the error is ultimately ignored.
(cherry picked from commit 192a9d95ea3e058afd824d38a9cea16ad0a84a57)
(cherry picked from commit cbbe6f78b7839bae605e0296f5d2ae2e3baa04a9)
These were added to eficonex.h in gnu-efi 3.0.13. Let's move them
to missing_efi.h behind an appropriate guard to fix the build with
recent versions of gnu-efi.
(cherry picked from commit 95ba433a5f34baf92921fb58051bc8241f908c0e)
(cherry picked from commit 48fff0a2af3f62acd446ebec8081b039b72caad8)
https://bugzilla.redhat.com/show_bug.cgi?id=1944171
Thread 1 (Thread 0x7fb5f0341b80 (LWP 1974)):
№0 selabel_lookup_common (rec=0x0, translating=0, key=0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service", type=40960) at label.c:167
'rec' is the handle that we passed.
№1 0x00007fb5f13ae87f in selabel_lookup_raw (rec=<optimized out>, con=con@entry=0x7fffef307380, key=key@entry=0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service", type=type@entry=40960) at label.c:256
lr = <optimized out>
'rec' is passed through as is to selabel_lookup_common().
№2 0x00007fb5f1561b2d in selinux_create_file_prepare_abspath (abspath=0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service", mode=40960) at ../src/basic/selinux-util.c:368
filecon = 0x0
r = <optimized out>
__PRETTY_FUNCTION__ = "selinux_create_file_prepare_abspath"
__func__ = "selinux_create_file_prepare_abspath"
№3 0x00007fb5f1561ec3 in mac_selinux_create_file_prepare (path=<optimized out>, mode=40960) at ../src/basic/selinux-util.c:431
r = 0
abspath = 0x55f616ac4750 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service"
__PRETTY_FUNCTION__ = "mac_selinux_create_file_prepare"
We checked label_hnd != NULL, but then we apparently called
avc_netlink_check_nb(), which reset label_hnd. Yay for global state!
№4 0x00007fb5f1549950 in symlink_atomic_label (from=0x55f6169d8b50 "69a8dcf7a7ac46b29306f2fddbed3edc", to=0x55f616ab8380 "/run/user/1000/systemd/units/invocation:systemd-tmpfiles-clean.service") at ../src/basic/label.c:55
r = <optimized out>
__PRETTY_FUNCTION__ = "symlink_atomic_label"
In the logs:
Mar 29 14:48:44 fedorapad.home systemd[1974]: selinux: avc: received policyload notice (seqno=2)
Mar 29 14:48:44 fedorapad.home systemd[1974]: Failed to initialize SELinux labeling handle: No such file or directory
Mar 29 14:48:44 fedorapad.home systemd[1974]: selinux: avc: received policyload notice (seqno=3)
Mar 29 14:48:44 fedorapad.home systemd[1974]: selinux: avc: received setenforce notice (enforcing=0)
Alternative title: Replace get_process_cmdline()'s fopen()/fread() with
read_full_virtual_file().
When RLIMIT_STACK is set to infinity:infinity, _SC_ARG_MAX will
return 4611686018427387903 (depending on the system, but definitely
something larger than most systems have). It's impractical to allocate this
in one go when most cmdlines are much shorter than that.
Instead use read_full_virtual_file() which seems to increase the buffer
depending on the size of the contents.
(cherry picked from commit 7b7a060e83d6c7de8705904d71978ba4664f0a65)
(cherry picked from commit fca334fb072545e2db8a81a51f8d1ab343fb610f)
The generated string may include %, which will confuse both the
xprintf call, and the VA_FORMAT_ADVANCE macro.
Pass the generated string as an argument to a "%s" format string
instead.
(cherry picked from commit 7325a2b2d15af09a9389723d6153050130c0bd36)
(cherry picked from commit 0d4ba1519552761baeb4b464fad8854b24497193)
The encapsulation limit of IPv6 tunnel can not be set to 4, which is the default value of the encapsulation limit.
(cherry picked from commit 6b1ed5e7e68fc5992a7bdabe4a05a7a3e1e1d898)
(cherry picked from commit 5678859dfd2eb1d018a0f5d468131367d152bbe2)
Linux is pretty lenient here, but we should specify the access mode.
(cherry picked from commit 86b86107942e84de4eb22944251694c0ae21b3ee)
(cherry picked from commit 857533a523d058e9833a553f6ef192ff1ab33b15)
See commit 1f0958f640b87175cd547c1e69084cfe54a22e9d .
(cherry picked from commit f055cf77862bc580f3afbfaac161d1c060f39411)
(cherry picked from commit c86f4f5f287258938d0c30354040c3b034b0c066)
When trying to calculate the next firing of 'Sun *-*-* 01:00:00', we'd fall
into an infinite loop, because mktime() moves us "backwards":
Before this patch:
tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00
tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00
tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00
...
We rely on mktime() normalizing the time. The man page does not say that it'll
move the time forward, but our algorithm relies on this. So let's catch this
case explicitly.
With this patch:
$ TZ=Europe/Dublin faketime 2021-03-21 build/systemd-analyze calendar --iterations=5 'Sun *-*-* 01:00:00'
Normalized form: Sun *-*-* 01:00:00
Next elapse: Sun 2021-03-21 01:00:00 GMT
(in UTC): Sun 2021-03-21 01:00:00 UTC
From now: 59min left
Iter. #2: Sun 2021-04-04 01:00:00 IST
(in UTC): Sun 2021-04-04 00:00:00 UTC
From now: 1 weeks 6 days left <---- note the 2 week jump here
Iter. #3: Sun 2021-04-11 01:00:00 IST
(in UTC): Sun 2021-04-11 00:00:00 UTC
From now: 2 weeks 6 days left
Iter. #4: Sun 2021-04-18 01:00:00 IST
(in UTC): Sun 2021-04-18 00:00:00 UTC
From now: 3 weeks 6 days left
Iter. #5: Sun 2021-04-25 01:00:00 IST
(in UTC): Sun 2021-04-25 00:00:00 UTC
From now: 1 months 4 days left
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1941335.
(cherry picked from commit 129cb6e249bef30dc33e08f98f0b27a6de976f6f)
(cherry picked from commit e5cf86ff98a21b427e1439a001d8e6b81c07b19c)
We have a bug where we seem to enter an infinite loop when running in the
Europe/Dublin timezone. The timezone is "special" because it has negative SAVE
values. The handling of this should obviously be fixed, but let's use a
belt-and-suspenders approach, and gracefully fail if we fail to find an answer
within a specific number of attempts. The code in this function is rather
complex, and it's hard to rule out another bug in the future.
(cherry picked from commit 169615c9a8cdc54d748d4dfc8279be9b3c2bec44)
(cherry picked from commit f14b80e09e225ccf7cfd8a85578b7e64c3fdebb9)
Commit 0b1f3c768ce1bd1490a5e53f539976dcef8ca765 has introduced log_open()
calls after exec fails post-fork. However, the log_open() call itself could
change the value of errno, which, for me, manifested in:
$ coredumpctl gdb
...
Failed to invoke gdb: Success
Fix this by using PROTECT_ERRNO in log_open().
(cherry picked from commit 0e557eef37c9ebcc8f5c19fc6fc44b6fd617cc5d)
(cherry picked from commit dabf9f2109e5b8cc26d9e0d9188deebff3edf8c2)
Closes#19044.
(cherry picked from commit c23bb96b388f371e44c4f1756801dec2b4e72307)
(cherry picked from commit e60fe377e449f402b61237d6476cde6dadd2e03f)
I'm not sure if all options listed in this patch are already there in v246… But
at least --slice-inherit which was originally requested in #19044 is here.
Worst case, users will get completion to some options which are not there yet.
Let's copy out the string we need from the dirent, there's no reason to
believe the dirent struct might live for longer than one loop iteration.
(cherry picked from commit c68fc3514ddd53abd7ecfd22afb07aa0ad785c5c)
(cherry picked from commit 928ab001fb77fea95ee833fe27e1913f043587ff)
This fixes the --size= switch, i.e. where we grow a disk image: after
growing it we need to expand the partition table so that its idea of the
the medium size matches the new reality. Otherwise our disk size
calculations in the subsequent steps might still use the original
ungrown size.
(This used to work, I guess this was borked when libfdisk learnt the
concept of "minimized" partition tables)
(cherry picked from commit f9b3afae96c72564cd4cd766555845f17e3c12a9)
(cherry picked from commit b132bca9f6dc6ed4965c0ac48bac90e9fc443a9e)
When the test suite is being run in a foreign environment,
/sys/fs/cgroup might not be set up in a way that we recognize.
Returning ENOMEDIUM causes the tests to be skipped in this case.
Bug: https://bugs.gentoo.org/771819
(cherry picked from commit 2156061fb33811aedb160d1b476793a5b845b143)
(cherry picked from commit 84ed68f5f0c393db3824dbbb2bc2118cf6e03722)
Prompted by #9473.
(cherry picked from commit b63dae3168209a06cefe2b9916667b7754b7de34)
(cherry picked from commit 438777cc00ccf2c05f8a05fa02907aa7be547719)
The integer overflow happens when utf8_encoded_valid_unichar() returns an error
code. The error code is a negative number: -22. This overflows when it is
assigned to `z` (type `size_t`). This can cause an infinite loop if the value
of `q` is 22 or larger.
To reproduce the bug, you need to run `systemd-ask-password` and enter an
invalid unicode character, followed by a backspace character.
GHSL-2021-052
(cherry picked from commit 37ca78a35cd1b9f13e584ccf3d332413c7875e40)
(cherry picked from commit 069525e84a67375e27429cb490e8d28af78e673a)
We generally operate on the assumption that a source is "gone" as soon
as we unref it. This is generally true because we have the only reference.
But if something else holds the reference, our unref doesn't really stop
the source and it could fire again.
In particular, on_query_timeout() is called with DnsQuery* as userdata, and
it calls dns_query_stop() which invalidates that pointer. If it was ever
called again, we'd be accessing already-freed memory.
I don't see what would hold the reference. sd-event takes a temporary reference,
but on the sd_event object, not on the individual sources. And our sources
are non-floating, so there is no reference from the sd_event object to the
sources.
For #18427.
(cherry picked from commit 97935302283729c9206b84f5e00b1aff0f78ad19)
(cherry picked from commit 78a43c33c8847ebbc2d3cf530ebe304924c58b32)
e.g.:
./src/shared/dissect-image.c:2218:39: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"/usr/lib/os-release\0",
^
../src/shared/dissect-image.c:2217:39: note: place parentheses around the string literal to silence warning
[META_OS_RELEASE] = "/etc/os-release\0"
^
1 error generated.
See: https://reviews.llvm.org/D85545
(cherry picked from commit 8762049792024df1be9f0b219438220bb9ee547d)
(cherry picked from commit 6345ef607976ce0311d01a38ee30855f5416ff1f)
This reverts commit 876c75fe870846b09b54423a6b719d80bc879b27.
The patch seems to cause usb devices to get some attributes set from the parent
PCI device. 'hwdb' builtin has support for breaking iteration upwards on usb
devices. But when '--subsystem=foo' is specified, iteration is continued. I'm
sure it *could* be figured out, but it seems hard to get all the combinations
correct. So let's revert to functional status quo ante, even if does the lookup
more than once unnecessarily.
Fixes#18125.
(cherry picked from commit 451ba55fecd8b494add2001b3ca3c1915c8fd655)
(cherry picked from commit f69a0fd38938b20e0b390f7876f8474daa66a100)
Reading file '/usr/lib/systemd/ntp-units.d/80-systemd-timesync.list'
Failed to add NTP service "# This file is part of systemd.", ignoring: Invalid argument
Failed to add NTP service "# See systemd-timedated.service(8) for more information.", ignoring: Invalid argument
:(
(cherry picked from commit 03a81441b1a490f8fc2a19aeb9b23299657c380c)
(cherry picked from commit 279c24e155df495164b68905bfe6340b5de1c797)
C.f. 9793530228.
We'd crash when trying to access an already-deallocated object:
Thread no. 1 (7 frames)
#2 log_assert_failed_realm at ../src/basic/log.c:844
#3 event_inotify_data_drop at ../src/libsystemd/sd-event/sd-event.c:3035
#4 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:3250
#5 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:3631
#6 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:3689
#7 sd_event_loop at ../src/libsystemd/sd-event/sd-event.c:3711
#8 run at ../src/home/homed.c:47
The source in question is an inotify source, and the messages are:
systemd-homed[1340]: /home/ moved or renamed, recreating watch and rescanning.
systemd-homed[1340]: Assertion '*_head == _item' failed at src/libsystemd/sd-event/sd-event.c:3035, function event_inotify_data_drop(). Aborting.
on_home_inotify() got called, then manager_watch_home(), which unrefs the
existing inotify_event_source. I assume that the source gets dispatched again
because it was still in the pending queue.
I can't reproduce the issue (timing?), but this should
fix#17824, https://bugzilla.redhat.com/show_bug.cgi?id=1899264.
(cherry picked from commit cf5366387b24633284ee92285ea64a282270d591)
(cherry picked from commit 668554d9dbfa9f240dd18455a52c68f3f48bdb81)
I'm getting the following error under valgrind:
==305970== Invalid free() / delete / delete[] / realloc()
==305970== at 0x483E9F1: free (vg_replace_malloc.c:538)
==305970== by 0x4012CD: mfree (alloc-util.h:48)
==305970== by 0x4012EF: freep (alloc-util.h:83)
==305970== by 0x4017F4: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970== Address 0x59972f0 is 0 bytes inside a block of size 8,192 free'd
==305970== at 0x483FCE4: realloc (vg_replace_malloc.c:834)
==305970== by 0x4C986F7: _IO_mem_finish (in /usr/lib64/libc-2.33.so)
==305970== by 0x4C8F5E0: fclose@@GLIBC_2.2.5 (in /usr/lib64/libc-2.33.so)
==305970== by 0x49D2CDB: fclose_nointr (fd-util.c:108)
==305970== by 0x49D2D3D: safe_fclose (fd-util.c:124)
==305970== by 0x4A4BCCC: fclosep (fd-util.h:41)
==305970== by 0x4A4E00F: bus_match_to_string (bus-match.c:859)
==305970== by 0x4016C2: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970== Block was alloc'd at
==305970== at 0x483FAE5: calloc (vg_replace_malloc.c:760)
==305970== by 0x4C98787: open_memstream (in /usr/lib64/libc-2.33.so)
==305970== by 0x49D56D6: open_memstream_unlocked (fileio.c:97)
==305970== by 0x4A4DEC5: bus_match_to_string (bus-match.c:859)
==305970== by 0x4016C2: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970==
So the fclose() which is called from _cleanup_fclose_ clearly reallocates the
buffer (maybe to save memory?). open_memstream(3) says:
The locations referred to by these pointers are updated each time the
stream is flushed (fflush(3)) and when the stream is closed (fclose(3)).
This seems to mean that we should close the stream first before grabbing the
buffer pointer.
(cherry picked from commit 5963e6f43c4f33d5255ef0fb887cdf382bd51c9e)
(cherry picked from commit f8fd75183bcf9cd6b55c3f8e752863d0083ed772)
Nominally, the bug was in unit_load_dropin(), which just took the last mtime
instead of calculating the maximum. But instead of adding code to wrap the
loop, this patch goes in the other direction.
All (correct) callers of config_parse() followed a very similar pattern to
calculate the maximum mtime. So let's simplify things by making config_parse()
assume that mtime is initialized and update it to the maximum. This makes all
the callers that care about mtime simpler and also fixes the issue in
unit_load_dropin().
config_parse_many_nulstr() and config_parse_many() are different, because it
makes sense to call them just once, and current ret_mtime behaviour make sense.
Fixes#17730, https://bugzilla.redhat.com/show_bug.cgi?id=1933137.
(cherry picked from commit da46a1bc3cd28ac36114002c216196dae004b05c)
(cherry picked from commit b29181eaa50a0fd9cefc4bcfbd0e6949038b65c9)
BPF filtering accesses fields in the netlink header that are
only filled in by libudev, never by the kernel. Therefore adding
BPF filters for kernel monitors is pointless. Even false filtering
of kernel events might be possible; at least it's hard to prove that
it can't occur.
(cherry picked from commit d8ce385fe3e5be91b6f414415e10f8897e41d942)
(cherry picked from commit 8f67d7ba3af72b1b3750530c123702246f35987f)
Let's add a special tweak to the btrfs builtin: if /dev/btrfs-control is
not there, let's consider all btrfs file systems as SYSTEMD_READY=0.
This is useful in initrds, where btrfs.ko might be missing. After the
initrd → host transition we can then retigger the device and undo the
SYSTEMD_READY=0 marking.
(cherry picked from commit 97e535c7248cc0457395e2d62b6e7d6c342a0bd2)
(cherry picked from commit 3f94149a9bdf7267453f614aa85f1735913d91a2)
Let's generate the warning on a unit that actually needs the BPF
firewall, and not confusingly already for a sibling of one.
(cherry picked from commit a437c5e4da666d16f15649461ce45e0e6d735148)
(cherry picked from commit 6349fb59858618bf9b92e4abb77dc4027b2fd35f)
The firmware spec doesn't really say whether FilePath of the LoadedImage
protocol may be NULL or not. So far we assumed it to be non-NULL, but
apparently the FreeBSD UEFI chainloader sets it to NULL. Handle this
gracefully.
(Noticed and tracked down by Alexander Schreiber)
Fixes: #18733
(cherry picked from commit 685097b9cadf92d21dfa857c3a7ddc1ba115088e)
(cherry picked from commit 151c62b5bcb7124ec43fbd7e21872974e1d9e500)
