Currently this check is run on every push to stable branches which all
fail since they fail to fetch the non-existent .github/path-rules.txt
from the just-updated branches.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60709
It has been almost a week with an open pull-requests and a follow-up
identified merge from master drm-kmod, as well as a patch supplied
in a PR for the ports to fix the the current build breakage in drm-kmod
and as a result also in nvidia-drm-* ports.
The problem there is that instead of using the kmod.mk supplied
definitions for LINUXKPI and despite using kmod.mk for the build,
the external components have hand-rolled solutions which can get
out of synch with src.git.
This was not discovered early on given that building drm-kmod with
LOCAL_MODULES_DIR= from git sources will not fail as the kernel
build will have provided the new opt_linuxkpi.h file. In addition
drm-kmod master already had the -include for kconfig.h which the
src tree has had since 2024.
Give the pkgbase/kmod builds and users over the weekend a chance
to produce drm-kmod packages as the number of affected poeple is
rising.
These changes will hopefully be brought back next week once
drm-kmod and nvidia-drm-* ports are fixed.
PR: 299334
Bring back after: 3+ days
This reverts commit bbfd52dcbe.
This reverts commit 9820afb99e.
caddr_t is a typedef for a character pointer (char *) that originated in
Version 7 Unix, released by AT&T in 1979. It became obsolete in 1989,
when ANSI C introduced void *.
What's left:
* ioctl(9) KPI still uses caddr_t, thus network related ioctl method
still use it.
* if_clone KPI, to be done separately.
* bpf(4), to be done separately.
* SCTP, let maintainers decide.
* iflib(4), let maintainers decide.
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D60738
caddr_t is a typedef for a character pointer (char *) that originated in
Version 7 Unix, released by AT&T in 1979. It became obsolete in 1989,
when ANSI C introduced void *.
There is a lot of code that uses m->m_data for arithmetics, thus we can't
switch it to void * easily. Let's at least stop proliferation of caddr_t.
We have developers that are twice younger than obsoletion of this type.
Reviewed by: zlei, tuexen, adrian
Differential Revision: https://reviews.freebsd.org/D60736
Make them all belong to SI_SUB_PROTO_FIREWALL and explicitly specify
order. Prefer SYSINIT() over modevent, for those subsystems that don't
have dependencies. All subsystems just depend on the main module and they
don't depend on each other, except dummynet which also has submodules.
Thus, keep DECLARE_MODULE() only for the main module and dummynet.
Differential Revision: https://reviews.freebsd.org/D60685
It was temporarily reduced in af78195e00 in 1994 to hide some bugs with
signed short overflow. We believe all these bugs were sorted out by
today. :)
Note that earlier ba582a82b0 reduced the MTU be rounded to a longword
with a reference "NFS likes it to be rounded". We have had several
refactors of the NFS code since that.
Reviewed by: pouria, zlei, tuexen
Differential Revision: https://reviews.freebsd.org/D59450
This adds a function which is used from various places in drm-kmod
to detect if the code can sleep or not. Currently, these locations
(such as intel_guc_send_busy_loop) are ifdeffed to freebsd specific
solutions (usually drm_can_sleep).
This change implements irqs_disabled. We check td_pinned as spinlocks
will call sched_pin, and td_critnest to check if we are in a critical
section.
Approved by: wulf, khng (mentor)
Differential Revision: https://reviews.freebsd.org/D57782
Linuxulator implements epoll instances using kqueues. Currently,
epoll_create_common() creates the backing kqueue with copy-on-fork
disabled. When fork() copies the descriptor table, the kqueue is
omitted from the child's table.
This differs from Linux, where an epoll descriptor survives fork(),
including when it was created with EPOLL_CLOEXEC. That flag controls
descriptor lifetime across exec(), not fork().
The missing descriptor breaks dbus-daemon daemonization. The daemon
creates its epoll instance before forking and continues using the
saved descriptor number in the child. F_GETFD initially fails with
EBADF. Once another open reuses that number, subsequent epoll_ctl()
calls fail with EINVAL because the descriptor no longer refers to
an epoll instance. The daemon then exits, preventing applications
that depend on the session bus from starting correctly.
Enable KQUEUE_CPONFORK for epoll's backing kqueue. This preserves the
descriptor number and copies supported event registrations into the
child, allowing the daemonized process to continue using epoll.
This is a partial compatibility improvement, not a complete
implementation of Linux epoll inheritance. Linux parent and child
reference the same epoll instance, whereas KQUEUE_CPONFORK creates
independent queues. Consequently, registration changes and one-shot
event consumption in one process are not reflected in the other.
Applications relying on shared epoll state across fork still require
further work.
Validation:
- A static Linux x86-64 C reproducer fails under the original
Linuxulator and passes on a real Linux kernel under QEMU.
- Before this change, the child loses its epoll descriptor with
both EPOLL_CLOEXEC enabled and disabled, while ordinary pipe
descriptors survive.
- After this change, descriptor flags, inherited readiness and
event data remain available in the child. epoll_ctl() also
succeeds after allocating additional descriptors.
- Both dbus-daemon --session --fork and dbus-launch start
successfully and answer a ListNames request from a separate
client.
- Shared-state regression tests still fail for parent visibility
of child ADD/MOD/DEL operations and EPOLLONESHOT consumption,
documenting the remaining semantic differences.
Reviewed by: kib
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D60783
ptmx_fdopen() masks the supplied file flags to FREAD | FWRITE before
passing them to pts_alloc(). This discards FNONBLOCK even when the
caller explicitly requests O_NONBLOCK.
As a result, open("/dev/ptmx", O_RDWR | O_NOCTTY | O_NONBLOCK) succeeds,
but the returned file is blocking. F_GETFL reports O_NONBLOCK cleared,
and a subsequent read can block instead of returning EAGAIN when no
data is available.
This causes Linux xfce4-terminal/VTE running under Linuxulator to
freeze. VTE opens the PTY master with O_NONBLOCK and relies on
nonblocking reads while draining terminal output. Once the available
data has been consumed, the main UI thread blocks in ptsdev_read(),
leaving the window unresponsive even though the child shell has
started successfully.
Include FNONBLOCK in the flags passed to pts_alloc(). Blocking opens
retain their existing behavior. No change to posix_openpt(2) flag
validation is required.
The flag loss also reproduces with a native FreeBSD program, so the
problem is in the shared /dev/ptmx implementation rather than Linux
syscall flag translation.
Validation:
- Before the fix, a native FreeBSD reproducer observes O_NONBLOCK
cleared after opening /dev/ptmx with that flag.
- Explicitly setting O_NONBLOCK with F_SETFL works, confirming that
nonblocking PTY operation itself is supported.
- After the fix, F_GETFL preserves O_NONBLOCK when requested and
leaves it cleared for a blocking open.
- xfce4-terminal in the Linux jail displays the shell prompt and
accepts input.
Reviewed by: kib
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D60700
IFCAP2_RXTLS4 and IFCAP2_RXTLS6 are bit numbers, not masks, so
ktls_reset_receive_tag() tested if_capenable2 against 0 for IPv4 and against the
RXTLS4 bit for IPv6. An IPv4 connection with NIC receive TLS offload thus never
got a new receive tag after its packets moved to another interface, and fell
back to software decryption for good.
c721694 fixed the same checks in ktls_alloc_rcv_tag(); use IFCAP2_BIT() here
as well.
Fixes: fe8c78f ("ktls: Add full support for TLS RX offloading via network interface.")
Approved by: gallatin, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60757
sbappend_ktls_rx() read the receiving interface of each packet header it
demotes from the chain's first mbuf, whose header it had zeroed on the first
pass. A chain of two packets or more thus had no interface, and a change of
input interface went unnoticed: the TLS receive tag stayed on the old interface
until a later append of one packet.
Read it from the packet being demoted, as the decrypted mark is.
Fixes: fe8c78f0d2 ("ktls: Add full support for TLS RX offloading via network interface.")
Approved by: gallatin
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60758
Port iwm_enable_ac_txq() from OpenBSD. It's effictively the
command FIFO path in the existing iwm_enable_txq().
The OpenBSD driver does a bunch of TX aggregation queue setup in
iwm_enable_txq() which isn't relevant here just quite yet and
it doesn't currently hurt to leave the existing one here
whilst I figure out the next steps.
Locally tested:
* 3160, 7260, 8260, 9260 - STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60696
* Add phy/mac tasks, the phy task is currently a placeholder
* Add in the MAC methods from net80211 that are called whenever
the VAP mode needs updating
* Mark the hardware as STOPPED during shutdown so scheduled tasks
don't run
The fun side of this work:
* detaching net80211 causes the parent method to be called which leads
to iwm_stop() being called, and at least one of the entry paths
into iwm_stop() has IWM_LOCK held, and we can't do a taskqueue_drain()
or taskqueue_drain_all() call with any lock held as it will sleep.
* the net80211 detach path is calling at least one of the MAC methods
during detach, and since the taskqueue is being deleted /before/
the net80211 detach path, we have to make sure nothing is actually
going to do taskqueue work after that!
* STOPPED in FreeBSD is MOSTLY doing the same as SHUTDOWN in OpenBSD.
It should be fine enough for this.
Locally tested:
* 3160/7260/8260/9260 STA mode - create, ctrl-C wpa_supplicant; create,
destroy; create, unload; create, destroy, unload. The create+unload paths
generate interesting net80211 tear down states which were causing
issues here.
Differential Revision: https://reviews.freebsd.org/D60607
This isn't yet used by anything; it's a precursor to TX queue
tracking needed for dynamically assigned TX aggregate queues.
Tested:
* 3160, 7260, 8260, 9260, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60286
pfr_remove_kentry() returns without removing an entry whose mark is
set. The mark is scratch space for the operations that handle a list
of addresses: each resets it before use and leaves it set on the
entries it kept, so after "pfctl -T replace" or "pfctl -T zero" of an
address the entry stays marked. An address a source limiter put in
its table is then never taken out again when the source falls below
the low-water mark.
Remove the entry whether it is marked or not; nothing else is in the
work queue.
Add a regression test.
Reviewed by: kp
Fixes: 4616481212 ("pf: introduce source and state limiters")
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D60530
mgb(4) is not x86-only now, so install its manpage everywhere and make
if_mgb.4 link creation work, which is already on all architectures.
Sponsored by: The FreeBSD Foundation
We add -dirty to the uname version string if the tree does not match the
reported hash. Previously, staged but uncommitted changes were ignored.
Noted by naddy@ in D60606.
Reviewed by: cperciva, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60722
Add tests for some recently fixed bugs in dhclient. All of these tests
set up two VNET jails connected by an epair. dhclient runs in one jail,
and the test code runs on the other end. It uses scapy to inject
"interesting" packets in response to DHCPDISCOVER messages from
dhclient, then checks the configured interface and lease file.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60485
The loop did not verify that the option buffer is large enough before
reading an address.
Reported by: Andrew Griffiths <[email protected]>
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60484
This is the program that found the races fixed in 1f1043d550. One
thread keeps a pattern in f14-f31 across a signal, while helpers pinned
to the same CPU keep different patterns in the real registers and get
woken up from another CPU to preempt it at random points. If the kernel
ever hands it somebody else's registers, the pattern doesn't match.
The register loads, the thr_kill() and the handshake with the helper are
in assembly so that nothing touches the FP registers between sigreturn
and the check. It runs for ten seconds and is skipped with fewer than
two CPUs.
Requested by: adrian
Approved by: jhibbits
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60411
Kernel mode program, trace, breakpoint and machine check exceptions go
through dbtrap, which saves the registers on trapstk and, if KDB doesn't
want the trap, restores them from there and continues with the normal
trap handler. There was just one trapstk for all CPUs, so when two of
them trapped at the same time they overwrote each other's frame and one
of them carried on with the other's registers. DTrace fbt probes are
these traps, so a probe on a function that runs on several CPUs at once
took the kernel down within seconds.
Keep the stack in the pcpu instead. The boot CPU gets a static one,
since it's set up before malloc works, the others allocate theirs in
cpu_pcpu_init() like the Book-E critical interrupt stack.
Approved by: jhibbits
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60362
Without it, LLVM libunwind doesn't know where to stop when unwinding the
main thread, so it uses a stale LR as the return address and crashes.
Our libunwind doesn't do that since 5866c369e4 reverted it, but
programs that bundle their own copy, like ClickHouse, are hit by it.
amd64, arm64, i386 and riscv already have the same annotation.
Approved by: jhibbits
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60740
handles wake-on-LAN arming and lid state on the PCH
PMC/GMUX platform instance, and panel backlight
control on the PNLF instance, registering with
backlight(9).
Reviewed by: ziaee, adrian
Differential Revision: https://reviews.freebsd.org/D58867
* ggatel: fix piped output. Flush stdout before daemonizing, so the
output can be read when it's in a command pipeline.
* ggated: bind the port _before_ daemonizing, so an invoking script can
be sure that the port is bound as soon as the command returns.
* tests: allow ggatec or ggatel to automatically allocate a device
number instead of choosing one in a racy way.
With all of these changes I can no run the tests 1000 times without
fail. And in parallel, too.
MFC after: 1 week
Sponsored by: ConnectWise
PR: 298942
Reported by: siva
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D60707
This brings these functions inline with OpenBSD
Locally tested:
* 3160, STA mode
* 7260, STA mode
* 8260, STA mode
* 9260, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D60211
Update the phy context routines to match what the openbsd snapshot
is doing. This involves some HT channel width stuff which although
I am not doing HT right now, it was juts easier to sync these
entirely versus just a partial sync.
* Update the phy context routines to match what openbsd is doing
* Although the openbsd driver has an iwm_phy_ctxt_update() routine
instead of add and modify, I'm leaving it as-is for now.
A bunch of refactoring is going to need to be done to properly
use an iwm_phy_ctxt_update() call and I didn't want to tackle
that in here.
* Add a UHB firmware capability phy context call; I can't test it
but it's mostly copy/paste.
* Add in a util to turn ieee80211_channel into the 'sco' variable
(the HT low/hi parameter) since it's done in openbsd in a
slightly different way.
Locally tested:
* 3160, STA mode
* 7260, STA mode
* 8260, STA mode
* 9260, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60082
bring the iwm_nic_config() / IWM_CSR_HW_IF_CONFIG_REG programming
in line with openbsd.
Locally tested:
* 3160 STA mode
* 7260 STA mode
* 8260 STA mode
* 9260 STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60081
This is the minimum set of DQA bits from iwm at the given openbsd
commit place.
* add a method to map ac to queue / ring
* use the DQA command queue if needed
* glue to wire it up
Locally tested:
* Intel 7260, STA mode
* Intel 9260, STA mode
* Intel 8260, STA mode
* Intel 3160, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60080
This is similar to `cmp -s`, but can be combined with:
-B --ignore-blank-lines
-b --ignore-space-change
-w --ignore-all-space
To only report a difference if it doesn't involve whitespace
Reviewed by: des, bapt, markj (previous version), ziaee (man page)
MFC after: 1 week
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D46717
The <machine/ieeefp.h> headers wrap their deprecated FPU control
prototypes in __BEGIN_DECLS/__END_DECLS but rely on the includer to
have pulled in <sys/cdefs.h>. Including <floatingpoint.h> first on
arm, arm64, powerpc and riscv (or amd64 <machine/ieeefp.h> with
__IEEEFP_NOINLINES__) fails with "unknown type name '__BEGIN_DECLS'".
This breaks e.g. devel/py-pyinstaller.
Suggested by: jhb
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D59659
The rfb code maintains an array of CRCs for 32x32 tiles in the
framebuffer. This array is sized statically based on the rfb code's
notion of the maximum framebuffer size, which changed in commit
fb51ddb20d without updating the rfb code.
Morever, writes to the framebuffer BAR can modify the recorded height
and width of the framebuffer. These values were not validated against
the maximum at all, unlike the parameters set via bhyve config.
Fix these problems:
- Define the maximum width and height in a shared header file so that
they do not get out of sync again.
- In pci_fbuf_render(), don't resize the console if the new dimensions
are too large.
- Add a mutex to synchronize framebuffer BAR I/O with the rfb thread.
Approved by: so
Security: FreeBSD-SA-26:72.bhyve
Security: CVE-2026-101311
Fixes: fb51ddb20d ("bhyve: increase fbuf display resolution limit")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60680
The length of each block in the stream must be non-zero. This is
assumed in hda_transfer(), otherwise an out-of-bounds read or write is
possible.
Use atomic loads to access stream descriptor fields, since they are
guest-controlled. Make sure that the descriptor array is suitably
aligned so that we can drop the __packed annotation from the structure
definition; per section 3.3.42 of the HDA spec the BDL pointer is
supposed to be 128-byte aligned, in fact.
Approved by: so
Security: FreeBSD-SA-26:72.bhyve
Security: CVE-2026-101310
Reported by: Brian Delgado from Intel using Anthropic Opus 4.8
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60678
rts->erst_p and rts->erstba_p are pointers to guest-controlled memory
which describe the event rings and pending event array, respectively.
The device model was not validating the size nor saving the value.
As a result, the bounds checks in pci_xhci_insert_event() were
susceptible to TOCTOU races.
Fix pci_xhci_rtsregs_write() to save the ring size in a softc field.
Validate that the size isn't larger than the maximum allowed by the XHCI
specification (64KB, or 4096 TRBs).
When processing TRBs, make sure we don't load fields more than once.
Make sure that pci_xhci_trb_next() doesn't return a pointer to host
memory. When handling ERDP writes, make sure that the guest-supplied
address is actually a pointer into the TRB array, and ignore the write
if not.
Approved by: so
Security: FreeBSD-SA-26:72.bhyve
Security: CVE-2026-101309
Reported by: Brian Delgado from Intel using Anthropic Opus 4.8
Differential Revision: https://reviews.freebsd.org/D60677
sndbuf_resize() and sndbuf_remalloc() drop the channel lock in order to
allocate the new buffer(s) with M_WAITOK. Before doing that they verify
that the buffer is not mapped, but this could change while the lock is
dropped, as there is no higher-level synchronization which prevents
buffer resize (e.g., via the SNDCTL_DSP_SETBLKSIZE ioctl) from happening
concurrently with mmap. Thus, these checks are insufficient.
Modify sndbuf_resize() and sndbuf_remalloc() to revalidate after
reacquiring the lock. Extend them to check for a couple of channel
flags, mirroring the check in chn_resizebuf(). Modify chn_resizebuf()
to revalidate state after reacquiring the channel lock.
We could also allocate new buffers with M_NOWAIT and so avoid dropping
the lock. Then, I think we could go even further and invoke
CHANNEL_SETBLOCKSIZE and CHANNEL_SETFRAGMENTS with the channel lock
held. But really it would be better to ensure that dsp operations are
serialized; there is no reason for mmap and chn_resizebuf() to be able
to run in parallel, we should not be relying on the channel lock for
this. So, let's keep a more minimal approach here.
Add a simple regression test.
Approved by: so
Security: FreeBSD-SA-26:71.sound
Security: CVE-2026-101308
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60554
Most implementations of CHANNEL_SETBLOCKSIZE and CHANNEL_SETFRAGMENTS
were not checking this. This is probably not a big problem: it's
unlikely for sndbuf_resize() to fail due to the refcount check in this
case since it's operating on the hardware buffer, which doesn't get
mmaped. But, I will add more reasons for it to fail in the next patch,
so let's be more careful.
This change modifies various CHANNEL_SETBLOCKSIZE implementations to
check for errors. In some cases I reordered things to avoid updating
driver state until after sndbuf_resize() succeeds.
Return 0 from CHANNEL_SETBLOCKSIZE to indicate an error, as it otherwise
returns the new block size. We could change the interface to return
both an error number and a block size, but that would break at least one
out-of-tree driver and I wish to avoid that here. Make sure that errors
from CHANNEL_SETFRAGMENTS and CHANNEL_SETBLOCKSIZE are returned to
userspace.
Approved by: so
Security: FreeBSD-SA-26:71.sound
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60553
The RACK stack's path capacity measurement module maintains an array of
samples, updated when the stack receives an ACK. The array grows as
needed, but code which handles the expansion is susceptible to remotely
triggerable overflow. This could lead to underallocation and a ~512KB
out-of-bounds write.
Fix this by bounding the sample array size.
Approved by: so
Security: FreeBSD-SA-26:70.tcp
Security: CVE-2026-101307
Reviewed by: glebius, markj
Reported by: Nozomi Networks Security Research
vmm doesn't implement them, and after commit 2272fac218
("hwpmc: Add support for AMD-only IRPERF in hwpmc PERF class"), FreeBSD
guests fail to boot since they access the unimplemented IRPERF MSR.
MFC after: 1 week
hdaa_audio_setup() reads the converter widget's ELD when choosing
between HDMI and DisplayPort audio infoframes. ELD is stored on the
output pin, so the converter has no ELD and the driver selects HDMI
framing even when the connected display uses DisplayPort.
Read the ELD from the output pin to select the correct audio framing.
The equivalent change was tested on DragonFly BSD with an Intel Kaby
Lake display-audio codec and an LG HDR 4K monitor connected over
DisplayPort. Before the change, converter node 2 had no ELD, while
output pin 5 had an 83-byte ELD identifying DisplayPort. Captured driver
commands programmed HDMI audio infoframe bytes (84 01 0a 70 01 00 00
00). After applying the change and rebooting, the commands used the
existing DisplayPort form (84 1b 44 01 00 00 00), and console tones and
desktop audio were audible.
PR: 299094
Signed-off-by: David Bidner <[email protected]>
Reviewed by: christos
MFC after: 2 weeks
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2463
John Baldwin