acpi_cpu: Bring back setting BM_RLD on resume
enable_idle(), which was called on resume before 427747fc16c9
("acpi_cpu: No longer disable idle during suspend"), also set BM_RLD.
This commit brings back just setting BM_RLD on resume because some
firmware might not be doing this itself on some machines.
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D61431
acpi_cpu: No longer disable idle during suspend
This had been introduced in 3331373ce733 ("Disable CPU idle states
during suspend and reenable them during resume.") to work around C-state
selection logic which would skip C-states which returned immediately,
considering them "broken".
This workaround is incompatible with suspend-to-idle however, which
requires CPUs to be in their idle states, and is no longer relevant
either way since b0baaaaecf1a ("Avoid comparing negative signed to
positive unsignad values.") removed the C-state skipping logic the
previous change was working around.
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/71
Differential Revision: https://reviews.freebsd.org/D60649
libfetch: Prepare for OpenSSL 4
* Always use libmd's MD5 since it's deprecated in OpenSSL.
* Use ASN1_STRING_get_length() instead of ASN1_STRING_length().
modstat: avoid copying from freed memory
If a module is unloaded after the module is looked up in kern_modstat,
but before one of the copyout's occurs, then the memory being copied
might be freed and reused leading to an information disclosure.
The LLM was particularly concerned about a TOCTOU issue in the length
of the name, but it seems likely that there are issues with all the
copyout's. As such, hold the shared lock throughout.
Reviewed by: markj
Reported by: llm-postcr
MFC after: 3 days
Sponsored by: Innovate UK
Fixes: 9b3851e9e3b1 ("- Lock down the ``module'' structure...")
Differential Revision: https://reviews.freebsd.org/D61398
netipsec: Release the sahtree lock on the AH and IPComp EAGAIN paths
183513d15f22 made the AH, ESP and IPComp input callbacks hold the
sahtree read lock, but only esp_input_cb() drops it before resubmitting
a request that the crypto framework completed with EAGAIN.
ah_input_cb() and ipcomp_input_cb() return with the lock still held.
crypto_invoke() completes requests with EAGAIN while their driver
detaches. Detaching ossl(4) under inbound AH traffic then hangs the
next rmlock writer, and the system panics with "spin lock held too
long" in smp_rendezvous_cpus() called from _rm_wlock().
Release the lock as esp_input_cb() does.
Reported by: llm-postcr
Reviewed by: kib
Fixes: 183513d15f22 ("sys/netipsec: ensure sah stability during input callback processing")
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D61399
ppp: bound IPCP IP-Address replies to the reply buffers
`ipcp_ValidateReq()` appended `IP-Address ack/nak/reject` records to the fixed `fsm_decode` buffers without a bound check. A `Config-Request` with ~17 or more `IP-Address` options overran a buffer into its own end pointer, so later writes could go wherever the peer chose.
Emit the option through `fsm_ack()/fsm_nak()/fsm_rej()` like the other options.
Reviewed by: markj
Approved by: adrian (mentor)
Signed-off-by: Nick Price <nprice at FreeBSD.org>
Differential Revision: https://reviews.freebsd.org/D61326
mlx5: add per-flow-group hash table for FTE lookup
lookup_fte_locked() scanned every FTE in a flow group with xa_next()
and memcmp() on each one. A new RX TLS session always misses, so the
whole group was walked under the group lock for every insertion. With
tens of thousands of RX-offloaded sessions in the same IPv6 TCP group
this costs milliseconds per call and grows linearly with the number of
FTEs.
Keep a hash table of the FTEs in each flow group, keyed by a jhash of
the match value. The table is sized from the group size, capped at
16K buckets. It is updated in insert_fte() and del_sw_fte(), both of
which hold the group write lock, and read in lookup_fte_locked() under
the group read or write lock. The xarray is kept for index
allocation. No lockless reads are introduced.
Reported by: NetApp
Reviewed by: kib
Sponsored by: NVidia networking
MFC after: 1 week
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]
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]
