rtnetlink: Use default weight for unset weights in NHA_GROUP
newnhg() copied the weights of a nhgrp as is and a group
whose members all have a zero weight, which is what
userland sends when it leaves the weight unset, made
calc_min_mpath_slots_fast() divide by zero.
Therefore replace weight of zero with RT_DEFAULT_WEIGHT.
While here, return early from calc_min_mpath_slots_fast()
if all weights are zero.
MFC after: 3 days
Fixes: 7e5bf68495cc ("netlink: add netlink support")
kernel: Add -mindirect-branch-cs-prefix for WITH_KERNEL_RETPOLINE
-mindirect-branch-cs-prefix adds a CS segment-override prefix (0x2e)
to each call or jmp to a retpoline thunk. The CPU ignores the prefix,
but it extends the instruction to six bytes instead of five. This
leaves enough room for a future kernel change to patch all of the call
sites at boot time to disable retpoline if not required.
Support for this option arrived in GCC 12 and Clang/LLVM 16.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D61514
if_media: Add 100BASE-T1 and 1000BASE-T1 media types
100BASE-T1 (IEEE 802.3bw) and 1000BASE-T1 (IEEE 802.3bp) are Single-Pair
Ethernet (SPE) standards intended for use in automotive and industrial
applications.
Reviewed by: kbowling
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60864
(cherry picked from commit f69099fc0fc55262741621451a52de50f164271a)
tcp: count only the SACK blocks that fit in tcp_maxseg()
tcp_addoptions() sends only the SACK blocks that fit in TCP_MAXOLEN.
tcp_maxseg() counted every pending block and clamped the total, so
without timestamps and with five or more blocks pending it came out 4
bytes below the segment tcp_output() sends. Limited transmit after an
RTO then sent one full segment and failed the "sent too much" KASSERT.
PR: 282605
Approved by: adrian (mentor)
Signed-off-by: Nick Price <nprice at FreeBSD.org>
Reviewed by: tuexen, glebius, adrian
Differential Revision: https://reviews.freebsd.org/D60460
powerpc: don't drop FPU and VMX ownership in grab_mcontext()
grab_mcontext() saved the FP and vector registers with save_fpu() and
save_vec(), which drop ownership: PCPU(fputhread) becomes NULL while
PCB_FPU stays set and the thread keeps using the unit. A later
cpu_update_pcb(), at fork(2) or thr_new(2), then skipped the save,
since save_fpu_nodrop() only saves for the thread that owns the unit,
and the child got the registers as they were at the getcontext() or
signal rather than at the fork. Use the nodrop variants.
A child forked after getcontext() saw the parent's f14 as it was at
the getcontext(); it sees the current value now.
Reviewed by: adrian, jhibbits
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60837
procctl: Zero the output structure for the compat32 syscall
Otherwise the freebsd32 implementation of PROC_REAP_STATUS leaks
uninitialized kernel stack memory.
Reviewed by: kib
Reported by: Dennys Kaluzny Pereira <dennyskaluzny at gmail.com>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D61510
ipfilter: Remove erroneous ntohs()
The original commit was wrong. ipf_nat_builddivertmp() builds the UDP
template with the length in host byte order
M_DUP() copies that value unchanged. The old code was therefore correct.
It added fin_plen in host order and then did a single htons().
The original patch was discussed with Co-Pilot, which pointed out the
original bug. claude-opus-5-5 discovered the ntohs() error that
co-pilot suggested.
Interestingly this code had been running here for a couple of months.
Reported by: llm-postcr
Fixes: 72cc9e3766f4
(cherry picked from commit 86861520613f99c85b5fbdf92b5c955a13ed6624)
ipfilter: Only recalculate the UDP header when we have one
When ipf_nat_out processes NAT_DIVERTOUT (ipnat rdr statements)
it also fixes the checksum in the UDP header. Test for a UDP header
before adjusting its length.
While we are here, the length in the UDP header must be converted
from network byte order to host byte order. Add the missing ntohs().
PR: 296944
(cherry picked from commit 72cc9e3766f4222fa7fc462bc669dcf668e8b334)
ipfilter: Remove erroneous ntohs()
The original commit was wrong. ipf_nat_builddivertmp() builds the UDP
template with the length in host byte order
M_DUP() copies that value unchanged. The old code was therefore correct.
It added fin_plen in host order and then did a single htons().
The original patch was discussed with Co-Pilot, which pointed out the
original bug. claude-opus-5-5 discovered the ntohs() error that
co-pilot suggested.
Interestingly this code had been running here for a couple of months.
Reported by: llm-postcr
Fixes: 72cc9e3766f4
(cherry picked from commit 86861520613f99c85b5fbdf92b5c955a13ed6624)
ipfilter: Only recalculate the UDP header when we have one
When ipf_nat_out processes NAT_DIVERTOUT (ipnat rdr statements)
it also fixes the checksum in the UDP header. Test for a UDP header
before adjusting its length.
While we are here, the length in the UDP header must be converted
from network byte order to host byte order. Add the missing ntohs().
PR: 296944
(cherry picked from commit 72cc9e3766f4222fa7fc462bc669dcf668e8b334)
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
[50 lines not shown]
vtnet: honor the advertised MTU limit on attach
When VIRTIO_NET_F_MTU is negotiated, virtio_net_config.mtu specifies
the maximum MTU the driver may use. vtnet_ioctl_mtu() enforces this
limit for subsequent MTU changes, but ether_ifattach() unconditionally
initializes the interface MTU to ETHERMTU (1500).
So a device advertising a maximum below 1500 starts with an MTU above
its limit. So make sure to set the initial MTU no larger than
vtnet_max_mtu. That is, for vtnet_max_mtu less than 1500
interface MTU will be set to this value, otherwise the current behaviour
is preserved, MTU will be set to 1500.
Reviewed by: kfv, tuexen
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D60980
(cherry picked from commit 0974ef03b43f279f16289ad4d5be3a03923983ea)
nvme: enforce the Abort Command Limit
Each watchdog pass submitted an Abort for every timed-out command
with nothing counting them against the controller's ACL. A
controller may complete excess Aborts with Abort Command Limit
Exceeded status.
Reviewed by: imp, adrian
Differential Revision: https://reviews.freebsd.org/D59636
acpi: Tasks: Precisely report the maximum number of slots used
To this end, store the actual number of busy slots instead of the index
of the final slot selected (off by one), and fix races when updating
'acpi_tasks_hiwater'.
The race is that it could happen that a first thread enqueued a task at
a higher index than the current maximum, followed by a second one
enqueuing at some even higher index, with the first thread updating
'acpi_tasks_hiwater' while the second was exactly after the 'if (i >
acpi_tasks_hiwater)' but just before attempting the atomic_cmpset_int()
that updates 'acpi_task_hiwater', which then would fail silently (the
return value was ignored) leading to the real maximum not being
recorded.
Fix the race by simply testing the return value of atomic_cmpset_int()
and retrying. Use an explicit atomic_load_int() for the guard (that
compiles to a regular load, so this change is cosmetic).
[6 lines not shown]
dwc: fix DEBUG macro name
It conflicts with the general "DEBUG" macro defined as an option in LINT
builds. Since this is actually unused, just rename it to GMAC_DEBUG.
Reviewed by: manu
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44102
(cherry picked from commit fae39d8da9d5ddf4239fc2143522340c941f6612)
hwpmc: tidy pcd_finalize methods
Make them a little bit more consistent with one another in terms of what
is done:
- Add/reduce assertions to what is most useful: a loop to ensure
pcpu_fini freed everything
- Add PMCDBG trace entries
The exception is the dmc620/cmn600 classes, which behave a little
differently, so leave them untouched.
Reviewed by: jkoshy
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41270
(cherry picked from commit 90a6ea5ca0b1b578e265d2479511bd04347f9510)
mmc_fdt: handle broken-cd property
The documented properties [1] for card-detection are one of:
- cd-gpios
- non-removable
- broken-cd
In cd_setup() we handle the first two, but not the latter, resulting in
a silently undetected card on an affected system.
To work around this, force cd_disabled when broken-cd is specified, so
that the card detect helper function gets to run. A more complete
solution would implement some kind of polling mechanism to detect the
card's presence or removal.
Some variants of the Allwinner D1, such as the Lichee Rv, specify this
property in the mmc0 device node.
[1] sys/contrib/device-tree/Bindings/mmc/mmc-controller.yaml
[9 lines not shown]
amd64: use pc_is_full() helper function
This seems to have been missed in a few places. No functional change
intended.
Reviewed by: kib
MFC after: 1 week
Fixes: 4d90a5afc51b ("sys: Consolidate common implementation details...")
Differential Revision: https://reviews.freebsd.org/D45920
(cherry picked from commit e7f849e25bbca9a74c9d3a5b633f9cd01ba95a55)
acpi: Tasks: Ensure sane values for number of tasks and threads
Make sure that these are set to sane values even on silly tunables:
- There must be at least one thread to process the 'acpi_taskq'.
- Use the ACPI_MAX_TASKS default when a negative number of tasks was
specified. This avoids common pilot errors causing a bogus huge memory
allocation for acpi_tasks[].
Reviewed by: obiwac (older version)
Differential Revision: https://reviews.freebsd.org/D60373
acpi: Tasks: Use M_WAITOK to allocate the taskqueue
Memory failure at this point normally does not happen except if the
kernel is running on a machine with a too tiny amount of memory, in
which case it is likely to panic or to be unusable anyway. However,
letting it panic here with a NULL pointer dereference is not very
helpful. Instead, use M_WAITOK, hoping the memory allocator itself will
indicate the low memory condition if it cannot succeed (if it does not,
it should be changed to).
Reviewed by: obiwac
Differential revision: https://reviews.freebsd.org/D60379
callout: optionally spread callouts to all CPUs
By default, if the caller has not used one of the _on() or _cpucpu()
variants of the callout API, the system assigns the callout to CPU0.
Having most callouts running on CPU0 can be problematic in terms of
the amount of CPU time spent executing callouts can have an unfair
impact to CPU0, and a critical callout (like lacp_tick) is certain
to land on the same CPU as everything else, so it is more likely
to be delayed.
This change introduces a change to callout_init* where if
kern.callout_spread is non-zero, callouts initialized after SMP startup
are distributed among CPUs.
This is left as disabled by default, as it may reveal any latent
synchronization bugs that were previously hidden, e.g., two callout handlers
which were always accidentally serialized against each other before may now
run concurrently. It also may cause a slight increase in power consumption
[6 lines not shown]
vtnet: honor the advertised MTU limit on attach
When VIRTIO_NET_F_MTU is negotiated, virtio_net_config.mtu specifies
the maximum MTU the driver may use. vtnet_ioctl_mtu() enforces this
limit for subsequent MTU changes, but ether_ifattach() unconditionally
initializes the interface MTU to ETHERMTU (1500).
So a device advertising a maximum below 1500 starts with an MTU above
its limit. So make sure to set the initial MTU no larger than
vtnet_max_mtu. That is, for vtnet_max_mtu less than 1500
interface MTU will be set to this value, otherwise the current behaviour
is preserved, MTU will be set to 1500.
Reviewed by: kfv, tuexen
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D60980
(cherry picked from commit 0974ef03b43f279f16289ad4d5be3a03923983ea)
