-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-26:26.hastd Errata Notice
The FreeBSD Project
Topic: Multiple issues in hastd(8)
Category: core
Module: hastd
Announced: 2026-10-14
Credits: Alessandro Sagratini, Martin Vidovic, Glen Barber
Affects: All supported versions of FreeBSD.
Corrected: 2026-09-20 17:07:37 UTC (stable/15, 15.1-STABLE)
2026-10-14 16:04:32 UTC (releng/15.1, 15.1-RELEASE-p5)
2026-09-20 17:07:56 UTC (stable/14, 14.5-STABLE)
2026-10-14 16:04:08 UTC (releng/14.5, 14.5-RELEASE-p2)
2026-10-14 16:03:50 UTC (releng/14.4, 14.4-RELEASE-p11)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
.
I. Background
hastd(8) allows transparent replication of a block of storage (the
resource) between a pair of systems connected over a TCP/IP network.
At any given time, only one system (the primary node) can access the
resource. Writes performed on the primary node are continuously
transmitted to the other system (the secondary node).
hastctl(8) is a command-line program used to control a hastd(8)
instance on the same machine.
II. Problem Description
All communication between hastd nodes, between hastd and hastctl, and
between the main hastd process and its child processes relies on a
shared set of networking routines and an early implementation of
name-value pair lists similar to but distinct from libnv(3), which was
a later development.
1. Control messages between hastd and hastctl can be empty, consisting
solely of a header with no payload. However, after receiving the
header, the function used to receive control messages asserts that
buffer space for the payload was successfully allocated. When
there is no payload, this assertion fails.
2. The nvpair implementation used by hastd and hastctl pads names and
values out to multiples of eight bytes, but does not initialize the
padding. As a result, small amounts of data from reused heap
allocations can find their way into that padding.
3. The main hastd process uses local domain sockets to communicate
with its workers. When the main hastd process hands off an
incoming connection to a worker, it first sends a variable-length
string indicating the type of socket. The child receives this
message using a function which does not allow short reads. This
previously worked due to a bug in the local domain socket code
which forced a short read if a normal message was followed by one
that passed a descriptor.
III. Impact
1. Depending on the exact configuration, certain hastctl commands may
result in an empty response from hastd, causing hastctl to print an
error message and abort. This does not affect the operation of
hastd itself, but may make it difficult to inquire into its status
or change its mode of operation.
2. The most obvious symptom of the padding issue is that small amounts
of text from the configuration file end up embedded in the metadata
at the start of the backing store for a HAST resource, because the
memory that was first used to read the configuration is later
reused to assemble the metadata before writing it out.
Small amounts of hastd memory, potentially including data
previously written to the resource, may also end up embedded in
network messages passed between hastd nodes.
3. As a pair of HAST nodes transition from initialization to
operation, the primary node will attempt to establish a network
connection to the secondary node. The secondary node accepts the
connection, then hands the socket off to a worker child. The
worker child then hangs forever trying to read the socket type,
preventing the node from transitioning to secondary. The pair
remains forever in degraded mode, where the primary is able to
operate normally but no replication to the secondary occurs.
IV. Workaround
No workaround is available, but systems that do not use hastd(8) are not
affected.
V. Solution
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date. Restart hastd(8), or
reboot the system.
Perform one of the following:
1) To update your system installed from base system packages:
Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or
arm64 platforms, which were installed using base system packages, can be
updated via the pkg(8) utility:
# pkg upgrade -r FreeBSD-base
2) To update your system installed from binary distribution sets:
Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms
which were not installed using base system packages can be updated via the
freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
3) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch https://security.FreeBSD.org/patches/EN-26:26/hastd.patch
# fetch https://security.FreeBSD.org/patches/EN-26:26/hastd.patch.asc
# gpg --verify hastd.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch -E -p0 < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
Restart hastd(8), or reboot the system.
VI. Correction details
This issue is corrected as of the corresponding Git commit hash in the
following stable and release branches:
Branch/path Hash Revision
- -------------------------------------------------------------------------
stable/15/ cd8eef45d2d0 stable/15-n285597
releng/15.1/ c8fe55b4726a releng/15.1-n283631
stable/14/ 9401bfb06108 stable/14-n275205
releng/14.5/ 49baaf01c26a releng/14.5-n274888
releng/14.4/ 1c821dc49b53 releng/14.4-n273782
- -------------------------------------------------------------------------
Run the following command to see which files were modified by a
particular commit:
# git show --stat
Or visit the following URL, replacing NNNNNN with the hash:
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmrPwdUbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvNkMP/1iZxLmeolrPLftdjdBr
NKTK4/EYKQupuCKhuGrJKRIbDcuz3aKoU+0lO821ra0ktly1mdzuO7xrNXIhzH6J
nTg+8MTPpM943sR2HP5vIyGPE+sXFd+YpSWjA0UHBhWIE25BFADhV0BC1UK1pGlD
nLYO/3eaPtmNAoP0UUo/YD/92JaoG2piqkPFYmPOVdbMwY3uphNzwhilJCuBdCMs
yxqhO/dpU+TYgv0vXs02p7iBvxwVHqgbZGHZHHBg+xnXBeFpMOXQ2jrtUJVc1FKZ
gVaHEoC0zO6VRg0pXCKU+SCYCvH0jlVGu/rBcpHgxTREN0Uf95lmO0NBWS5WgfBa
bl9mP3kwXc/rW59y36tY8vMTjg28J0h4DdTgPy2iJVcrYPWFx+ufUyVIdGCiuZat
Y3AjHwS/tPBAH15ovUBtkF1l7vB/LLRAi0qODnQmhgVkeZX2/PjGtzftyOES9P1T
zhehQnl1Twe+JiJgdtei/6UrnYHv2NKdmoW74tdi5WYizbnatN0P6uMLSCKdfbsZ
7q2i/8GUY4Js1yDqDAWGbg5fpq8fAKSY1GJtebK83E9MVjLaIl87llgS1KQASpXi
gmW4h9L8ZKZJPcysUk2YgXEDgMRKvuyj2soNVyL1V4oZtCJ4Tga4pdnjcyJlwpUT
JlT5dlSJCp7ed7hNh4wgOTTo
=kksa
-----END PGP SIGNATURE-----