ask-password: prevent buffer overflow when reading from keyring

When we read from keyring, a temporary buffer is allocated in order to
determine the size needed for the entire data. However, when zeroing that area,
we use the data size returned by the read instead of the lesser size allocate
for the buffer.

That will cause memory corruption that causes systemd-cryptsetup to crash
either when a single large password is used or when multiple passwords have
already been pushed to the keyring.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
(cherry picked from commit 59c55e73eaee345e1ee67c23eace8895ed499693)

Gbp-Pq: Name ask-password-prevent-buffer-overflow-when-reading-from-ke.patch

random-util: eat up bad RDRAND values seen on AMD CPUs

An ugly, ugly work-around for #11810. And no, we shouldn't have to do
this. This is something for AMD, the firmware or the kernel to
fix/work-around, not us. But nonetheless, this should do it for now.

Fixes: #11810
(cherry picked from commit 1c53d4a070edbec8ad2d384ba0014d0eb6bae077)

Gbp-Pq: Name random-util-eat-up-bad-RDRAND-values-seen-on-AMD-CPUs.patch

Drop support for /usr/sbin/halt.local

/usr/sbin/halt.local is a Fedora/Red Hat anachronism from pre-systemd
times.

(cherry picked from commit 44508946534eee032927c263b79464832656dd6e)

Gbp-Pq: Name Drop-support-for-usr-sbin-halt.local.patch

meson: stop creating .wants directories for {multi-user,getty}.target (#12569)

Since preset is supposed to be used to enable the services, there is no
need to pre-create those directories either.

Follow-up for #12164

(cherry picked from commit dadc7f2e43b163dd740832abd73b83245f716c1e)

Gbp-Pq: Name meson-stop-creating-.wants-directories-for-multi-user-get.patch

test: add test for flush_accept()

Fixes: #12335
(cherry picked from commit 5b116c37e14582ee6550c9157445d6bbd4ce1813)

Gbp-Pq: Name test-add-test-for-flush_accept.patch

socket-util: make sure flush_accept() doesn't hang on unexpected EOPNOTSUPP

So apparently there are two reasons why accept() can return EOPNOTSUPP:
because the socket is not a listening stream socket (or similar), or
because the incoming TCP connection for some reason wasn't acceptable to
the host. THe latter should be a transient error, as suggested on
accept(2). The former however should be considered fatal for
flush_accept(). Let's fix this by explicitly checking whether the socket
is a listening socket beforehand.

(cherry picked from commit f3d75364fbebf2ddb6393e54db5e10b6f6234e14)

Gbp-Pq: Name socket-util-make-sure-flush_accept-doesn-t-hang-on-unexpe.patch

systemd (242-4) unstable; urgency=medium

  * Upload to unstable

[dgit import unpatched systemd 242-4]

Import systemd_242-4.debian.tar.xz

[dgit import tarball systemd 242-4 systemd_242-4.debian.tar.xz]

Import systemd_242.orig.tar.gz

[dgit import orig systemd_242.orig.tar.gz]