aboutsummaryrefslogtreecommitdiff
path: root/gnu/libexec/uucp/libuuconf/(developers-only)
diff options
context:
space:
mode:
authorDag-Erling Smørgrav <des@FreeBSD.org>2026-09-08 20:55:15 +0000
committerDag-Erling Smørgrav <des@FreeBSD.org>2026-09-16 13:56:44 +0000
commitb7e5c2e008f5b441611830ad3a0329de0882419e (patch)
tree0a74bd244be365789e0b5b0f1084a1133818fbb7 /gnu/libexec/uucp/libuuconf/(developers-only)
parentd2ad1c3ffe67d7994a409956b6344dd458170d04 (diff)
hastd: Use fixed-length protocol namesHEADmain
All communication between hastd nodes and internally between hastd and its worker children passes through the same pair of send / receive functions. The receive function uses recv(2) with the MSG_WAITALL flag, which in theory means we should never get a short read. However, when handing off a socket to a worker child, we also pass a variable-length string identifying the type of socket we're passing, and reading this string relies on a short read. This used to work because the arrival of the descriptor would interrupt the recv(2) call, but this bug was fixed when the AF_UNIX code was rewritten a while ago and hastd has been broken ever since. Fixing the length of the protocol name to four characters including the terminating null solves the short-read bug by never requiring a short read (nothing else in hastd requires one). Note that this issue appears to have been reported independently first by Alessandro Sagratini in PR 234576 and then by Martin Vidovic in D57511. I ended up going in a different direction than Martin's patch, but his analysis was invaluable, hence the double credit below. PR: 234576 Reported by: Martin Vidovic <xtronom@gmail.com> MFC after: 1 week Event: EuroBSDcon DevSummit 2026 Reviewed by: xtronom_gmail.com, kevans, glebius, gjb Differential Revision: https://reviews.freebsd.org/D59521
Diffstat (limited to 'gnu/libexec/uucp/libuuconf/(developers-only)')
0 files changed, 0 insertions, 0 deletions