Revert "Remove {ATF,PLAIN}_REQUIRE_KERNEL_MODULE macros"
The change breaks the build of tests/sys/net/routing/test_rtsock_l3.c.
This reverts commit e34b159d4c64575aa45763968b6ad01dfd7c2337.
Remove {ATF,PLAIN}_REQUIRE_KERNEL_MODULE macros
These macros predated the `require.kmod` (ATF) and `required_kmods`
(kyua) test metadata and are no longer needed.
Add a hint to freebsd_test_suite/macros.h about the `*FEATURE*` macros
going away soon. See [this kyua issue][kyua-issue] for more details.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D61082
[kyua-issue]: https://github.com/freebsd/kyua/issues/346
nvmecontrol: Range-check the format command's field values
The format command accepted any 32-bit value for -m, -p, -l and
--ses and passed it into the Format NVM command. Before
eae727676169 an out-of-range value spilled into the adjacent cdw10
fields, which usually drew an error from the controller; after it,
the value is masked to the field width, so a mistyped value is
silently accepted with a different meaning. Most seriously,
--ses 8 masked to SES=0 and performed a plain format with no erase
at all, exiting 0. A value like --ses 10 masked to a cryptographic
erase while bypassing the FNA cryptographic erase capability check,
which compares the unmasked value.
Reject values outside the ranges nvmecontrol.8 documents, which are
the values the spec defines: 0-1 for -m and -l, 0-3 for -p, and
0-2 for --ses. The checks run at option validation time, before
the device is opened, and the capability check now only ever sees
valid values.
[10 lines not shown]
virtio_random: defer first enqueue until after DRIVER_OK
According to the virtio spec:
> The driver MUST NOT send any buffer available notifications to the
> device before setting DRIVER_OK.
DRIVER_OK isn't set until after attach completes, so defer the first
enqueue. We haven't found any problems as a result of this to the best
of my knowledge: q35 and other devices that we *have* been used with
will apparently check when we go DRIVER_OK.
Tested with q35 virtio-random, which still works.
Approved by: re (cperciva)
Reported by: llm-postcr
Reviewed by: kfv, markj
Fixes: f1c5a2e3a62505 ("virtio_random: Pipeline fetching the data")
Sponsored by: Stormshield
[4 lines not shown]
virtio_pci_modern: enable virtqueues before completing attach
Most of our drivers setup interrupt(s) and virtqueues are enabled at
that time, but nothing will currently enable them for devices that we're
only going to poll. This most notably affects virtio-random, and the
problem can be observed with qemu's q35 emulation and a random device
attached. The q35 implementation ignores the ring unless it's enabled,
so vtrnd_harvest() will consistently EAGAIN rather than contribute
anything of value, but with this patch it becomes functional.
This can be reproduced with a qemu invocation like so:
qemu-system-x86_64 -machine q35,accel=tcg -cpu max -smp 2 -m 2G \
-drive file=FreeBSD-16.0-CURRENT-amd64-ufs.qcow2,if=virtio \
-device pcie-root-port,id=rp1,bus=pcie.0,chassis=1 \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0,bus=rp1 \
-display curses
[7 lines not shown]
krb5: Import MIT 1.22.3
Major changes in 1.22.3 (2026-11-09)
====================================
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
[49 lines not shown]
nvmecontrol: Mask the fields in the Format NVM command
The format command composed cdw10 by hand without masking any of
the fields and with no support for the LBAFU field. Since commit
2c41f7d8a034 the LBA format index defaulted from FLBAS can exceed
15 on an NVMe 2.0 namespace using FIDXU, and such an index would
bleed into the MSET and PI fields. An out of range index supplied
with -f for a whole-controller format was not caught either.
Build the command with nvme_admin_format_cmd(), which masks all of
the fields and encodes LBA format indexes above 15 in LBAFU, and
reject LBA format indexes greater than 63 for whole-controller
formats. Per-namespace formats already validate the index against
NLBAF.
This is the same problem that llm-postcr reported in camcontrol's
copy of this code, fixed in 3892a6453fc6; the unmasked composition
originated here (635c517ae9ca).
[7 lines not shown]
namei(9): fix two ni_startdir leaks
namei() leaks the caller's ni_startdir reference on the empty-path
ENOENT return and on namei_getpath() failure.
On ZFS with the default zfs_xattr_compat=1, an empty user-namespace
extattr name on a file that has an xattr directory leaks one reference
on that directory per call.
Reported by: llm-postcr
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61366
vn_open_cred(9): fix ni_startdir leak
vn_open_cred() returns EINVAL before calling namei() for
O_CREAT|O_EXCL|O_DIRECTORY and for O_CREAT|O_EMPTY_PATH.
That leaks an NDINIT_ATVP() start directory.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61366
libthr mutex_self_lock(): handle signals and clock steps
Relocking an owned NORMAL mutex with an absolute timeout has two issues:
- nanosleep(2) is never restarted, so any caught signal causes
an early ETIMEDOUT.
- If CLOCK_REALTIME or CLOCK_TAI are stepped backward during the sleep,
the call also returns ETIMEDOUT before the clock reaches the deadline.
The kernel already polls CPU-time clocks and handles realtime steps.
Use _thr_umtx_timedwait_uint() in a loop to handle both issues.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D61381
bsdinstall: Set TMPDIR in pkgbase install
The FreeBSD-base repository (aka "pkgbase") is now created using 'pkg
repo -l' in order to make 'pkg rwhich' work. Unfortunately this makes
the data.pkg file considerably larger, and FreeBSD 15.2-BETA1 fails to
install using a remote repository since the installer has a small /tmp
(20 MB).
Run pkg commands with 'env TMPDIR=<chrootdir>/tmp' since the /tmp in
the system being installed is considerably larger than the tmpfs which
the installer runs with. Create <chrootdir>/tmp first so we can ensure
it has 1777 permissions.
Reviewed by: bapt
MFC after: 1 day
Differential Revision: https://reviews.freebsd.org/D61380
acpi_video: dim the internal panel while the lid is closed
Register an acpi_lid_event consumer that saves the current _BQC level and
drives _BCM to the lowest level _BCL offers when the lid closes, putting
the saved level back when it opens. Only an output already classified as
an internal panel is touched, and only a level this handler dimmed is
restored, so a brightness change made while the lid was shut survives.
Disabled by default; set hw.acpi.video.lid_blank=1 to enable.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D60827
acpi_video: fall back to _BCL when _DOD matches no output
vid_enum_outputs() only registers a child whose _ADR appears in the
graphics controller's _DOD. _DOD is filled in from the graphics driver's
ACPI opregion on some platforms, so with no such driver attached it can
describe no device at all while the panel still implements _BCL, _BCM and
_BQC. The match then fails for every child and the machine is left with
no brightness control.
Fall back to registering the first child that implements _BCL when _DOD
matched nothing, so such a machine gets a working
hw.acpi.video.lcd0.brightness and the brightness keys that ride on it.
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D60826
axgbe: bound the sysctl parser writes in get_val()
Reject tokens and option counts that exceed the fixed parser buffers,
and fix the terminating NUL offset. Have the sysctl handlers propagate
parser errors before applying settings.
Handle SYSL_U32 options and reject failed numeric conversions instead of
using an uninitialized value. Fix the duplex case falling through to an
error, and initialize the link-setting strings for unexpected speeds.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D61339
axgbe: return positive errno values from the sysctl handlers
Return positive errno values from the FreeBSD sysctl handlers so that
userland reports the proper error instead of "Unknown error: -22".
Convert the negative phy_config_aneg() result at the sysctl boundary,
matching axgbe_if_media_change(), and retain the PHY code's internal
error convention.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D61400
pwd_mkdb: validate login names
vipw(8) never looked at names, it just hands the file to pwd_mkdb,
and pwd_mkdb only cared abuot the field layout. So something like
`user1$(id$IFS-A)` in master.passwd went straight into the db.
Do the same check pw(8) does, in scan(), so vipw, chpass and hand
edits all hit it. NIS +/- entries get checked after the prefix.
Bail out rather then warn; a file with junk names wont rebuild
anymore, whcih is kinda the point.
Add tests while here.
Reported by: Harry Sintonen (Reversec)
Sponsored by: Entersekt
Approved by: bapt
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D61405
tpm_crb: Use locality registers only with plain CRB
The locality release wait times out on every command on a Framework 13
(Pluton start method), logging every 10 seconds.
Reported by: emaste, tuexen
Reviewed by: kbowling
Approved by: kbowling
Fixes: bfe4be85a935 ("tpm_crb: wait for idle and locality release after each command")
tests/sys/pmc: add pidtrack, callchain, pmc(8), RAPL and AMD tests
Add to the suite of ATF tests for hwpmc(4). Vendor-neutral tests go in
tests/sys/pmc; tests that depend on AMD hardware interfaces go in
tests/sys/pmc/amd, which is only built on amd64.
tests/sys/pmc:
pmc_pidtrack_test process-mode PMCs follow their PID: a live
self-read counts the process' own work, an idle
process sharing the CPU with a busy one does not
pick up its work, and the count survives a
context switch
pmc_callchain_ur_test pmcstat -U collects user callchains through the
PMC_UR ring; regression test for the KASSERTs
fixed in rGaf3929c5152b and rG66118c3f1011
pmc_cli_test pmc(8): missing log, list-events, record/info
round trip with the "instructions" alias
pmcstat_tsc_test (amd64) tsc_freq in the initlog record, TSC
column of pmcstat -R, tsc in pmc filter -j,
[29 lines not shown]
asmc: do not enable the sudden motion sensor on the MMIO backend
The interrupt filter reads the PIO interrupt port, but sc_ioport is NULL
under MMIO; the capability test only probed for keys, which says nothing
about the backend.
No MMIO-capable machine has a sudden motion sensor anyway. It existed to
park the heads of spinning disks.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D61383
libpmc: Strip leading zeros from the cpuid model
Upstream's mapfile.csv lists models without leading zeros, so entries
for models below 10h had to be fixed up by hand on every import. Strip
them before matching and use the entries as imported.
Add tests to validate the functionality.
Reviewed by: mhorne, Ali Mashtizadeh <ali at mashtizadeh.com>
Sponsored by: Advanced Micro Devices, Inc.
MFC after: 1 week
Signed-off-by: Osvaldo Janeri Filho <ojanerif at amd.com>
Differential Revision: https://reviews.freebsd.org/D60790
iflib: rate limit deferred tx ring drain
When simple_tx gives up & return ENOBUFS because the tx ring is full,
we were doing a GROUPTASK_ENQUEUE(&txq->ift_task) each time.
On a tx ring that has overflowed and is being hammered on
by a fast UDP sender, this can result in a massive increase in
context switches (I've seen over 30M ctxw/sec due to this, and
the ctxsw codepath taking roughly 50% CPU).
This change removes the GROUPTASK_ENQUEUE() and replaces it
with a call to a callout which drains the tx ring. The callout time is
determined based on the link speed, estimating how long it would take
for a large fraction of of a ring containing full-MTU packets to drain.
This removes the 30M ctxsw / sec in my test case and reduces it
to roughly a doubling of ctxsws.
Reviewed by: kbowling
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D61313
