tests/sys/capsicum: Fix -Wshadow issue with `fd_set`
`fd_set` is defined in `sys/select.h`, and prior to this change, was in fcntl.cc as well.
This change renames `fd_set` to `fd_set_` to avoid the name collision.
MFC after: 1 week
Reported by: gcc 14
Fixes: 04c4b2084eb9 ("capsicum-test: make the code WARNS=6 clean")
krb5: Import MIT 1.22.3
This is a bug fix release, with a focus on security issues discovered
with the aid of large language models. See
https://web.mit.edu/kerberos/advisories/MITKRB5-SA-2026-001.txt for
information on the risks of continuing to use unpatched releases.
* Fix a logic error when checking PAC server checksums
[CVE-2026-111423].
* Check for unkeyed checksums when validating CAMMAC verifiers
[CVE-2026-71199].
* Fix a loophole in the KDC's client authdata filtering which could
allow clients to include fake PAC and CAMMAC authdata values when
requesting service tickets. These fake values would be rejected by
application servers, were it not for the two bugs noted above.
* Check for the lockdown_keys attribute when processing password
[44 lines not shown]
mqueuefs: set *a_eofflag in VOP_READDIR
mqfs_readdir() never reported end of directory. Since 77b273d8f5f4
VOP_READDIR_APV() asserts that a readdir which returns no entries also
sets *a_eofflag, so with INVARIANTS the final zero-length
getdirentries(2) that ls(1) issues on a mounted mqueuefs panics:
panic: VOP_READDIR: eofflag not set
Report end of directory when the child list was walked to its end;
leave the flag clear when the walk stopped because the buffer was full.
(cherry picked from commit fbac0abdc5ab1fe867ac85635662ef06b2ee9d10)
i2ctinyusb: do not list i2ctinyusb.c twice in SRCS
The module Makefile named its only source file in both the SRCS= line
and the SRCS+= line that follows. bsd.kmod.mk tolerates the duplicate
in a normal build, but when the kernel is built with -flto=thin the
linker sees the same bitcode object twice and refuses to link the
module ("Expected at most one ThinLTO module per bitcode file").
Fixes: 54e231b373ef
(cherry picked from commit b5cd411af6418986fa0da9c12d02b9f26c344a4a)
tools/git/arcgit: retire
This too has been superseded by `git-arc`, located in the same directory as
`arcgit`.
Differential Revision: https://reviews.freebsd.org/D61379
tools/git/ghpr: retire
The project under the .../ghpr subdirectory is an earlier version of the
tool. A newer/supported iteration of the tool can be found on
[GitHub][ghpr-repo].
`ghpr` can be installed via `pkg`, e.g., `pkg install py312-ghpr-5`.
Please see the [README.md][readme] for further details.
MFC after: 1 month
[ghpr-repo]: https://github.com/bsdimp/ghpr/
[readme]: https://github.com/bsdimp/ghpr/blob/main/README.md
Reviewed by: dteske
Differential Revision: https://reviews.freebsd.org/D61086
capsicum-test: Disable `HAVE_SEND_RECV_MMSG` again
04c4b2084eb9 accidentally added some changes from another WIP commit into that
diff. Instead of wholesale reverting the change, just revert the part that's
currently broken (`HAVE_SEND_RECV_MMSG`). While some of the related tests pass,
one of the testcases (`capmode.cc:AllowedMmsgSendRecv`) doesn't currently pass.
Revert the change to make the CI run more green again.
MFC after: 1 week
Fixes: 04c4b2084eb9 ("capsicum-test: make the code WARNS=6 clean")
tests/sys/capsicum: restore test coverage with root user
This change builds capsicum_test and installs/runs it as an unprivileged
user ("tests" in vanilla FreeBSD) and root.
This required adjusting logic in the Makefile in order to build two
binaries with the same sources and running them as separate binaries.
Moreover, in order to restore coverage and ensure that some tests which
require `other_uid` (typically specified via `-u` on the CLI with the
test program) don't fail, become the "tests" user when run as root. This
technically doesn't honor unprivileged_user property in kyua.conf: the
property needs to be passed via a command-line parameter to the test
program.
MFC after: 1 week
Reported by: markj
Fixes: 3fb03fb35b20 ("[tests] switch GoogleTest tests ...")
[2 lines not shown]
capsicum-test: make the code WARNS=6 clean
Make the code WARNS=6 clean by doing the following:
- Renaming variables (-Wshadow).
- Use memcpy instead of assigning the result of CMSG_DATA to a variable
(-Wcast-align).
- Wrap some macros with do-while(0) to avoid variable collisions
(-Wshadow).
- Push one of the TRACE statements up by 1 layer to avoid a collision
between 2 calls of TRACE via the same overarching macro.
This was needed in order for the code to build properly with D61066,
since the code was not compiling with WARNS set to 3 at the testcase
level.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D61080
Revert "capsicum-test: make the code WARNS=6 clean"
The wrong patch got committed somehow from one of my git clones. Revert the
change so I can reapply the correct patch >:(.
This reverts commit 5bae837f316ca96b69c61bae15bd61da76e7f3ea.
Revert "tests/sys/capsicum: restore test coverage with root user"
The wrong patch was applied for D61080. Both changes must go.
This reverts commit dda15b669d021346682009f38acc6db2639fb99f.
tests/sys/capsicum: restore test coverage with root user
This change builds capsicum_test and installs/runs it as an unprivileged
user ("tests" in vanilla FreeBSD) and root.
This required adjusting logic in the Makefile in order to build two
binaries with the same sources and running them as separate binaries.
Moreover, in order to restore coverage and ensure that some tests which
require `other_uid` (typically specified via `-u` on the CLI with the
test program) don't fail, become the "tests" user when run as root. This
technically doesn't honor unprivileged_user property in kyua.conf: the
property needs to be passed via a command-line parameter to the test
program.
MFC after: 1 week
Reported by: markj
Fixes: 3fb03fb35b20 ("[tests] switch GoogleTest tests ...")
[2 lines not shown]
capsicum-test: make the code WARNS=6 clean
Make the code WARNS=6 clean by doing the following:
- Renaming variables (-Wshadow).
- Use memcpy instead of assigning the result of CMSG_DATA to a variable
(-Wcast-align).
- Wrap some macros with do-while(0) to avoid variable collisions
(-Wshadow).
- Push one of the TRACE statements up by 1 layer to avoid a collision
between 2 calls of TRACE via the same overarching macro.
This was needed in order for the code to build properly with D61066,
since the code was not compiling with WARNS set to 3 at the testcase
level.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D61080
pthread_cond_timedwait.3: list pthread_cond_clockwait as .Nm
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
pthread_cond_timedwait.3: split STANDARDS and HISTORY
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
libthr: libpthread/t_mutex.c tests should expect EDEADLK
to follow the POSIX specification.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
_umtx_op.2: correct the description of the valid _clockid for _umtx_time
And remove the duplicated list from the description of the condition
variable.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
lib/libthr: add helper to check valid clockid to use with _umtx_op(2)
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
umtxq_sleep(): do not wait forever for zero absolute timeouts
For msleep(), zero sbt means no timeout. If the timeout was specified as
absolute {0, 0} on MONOTONIC/UPTIME clocks, consider the call timed out
immediately, instead of sleeping until a signal is delivered.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
libthr cond_wait_user(): do not loop forever on clock error
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
pthread_cond_clockwait(3): explicitly reject unacceptable clockids
Otherwise they are rejected by kernel in do_wait(), reached through
_thr_sleep()/UMTX_OP_WAIT_UINT_PRIVATE on the user-mode path. Then,
since cond_wait_user() only leaves its loop on a wakeup, a cancellation
or ETIMEDOUT, the EINVAL from do_wait() results in a loop.
If hit, this indicates a bug in user code, but the system library
must be resilient to such misuse.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61253
