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
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
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 are returned to userspace.
Approved by: so
Security: FreeBSD-SA-26:71.sound
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60553
When performing an unconnected sendto() on a v6 UDP socket in a classic
jail, we were not applying the usual policy of replacing the loopback
addr with the jail's primary IP. Compare with, e.g., udp6_connect() or
the IPv4 udp_send(). Fix that.
Approved by: so
Security: FreeBSD-SA-26:69.udp
Security: CVE-2026-101303
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li,
and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Reviewed by: bz, glebius
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59772
(cherry picked from commit fecb9537a8)
(cherry picked from commit 809221661a)
If the entire plaintext is zero-filled, the backwards walk in
tls13_find_record_type() would return the offset of the last byte of the
TLS header. This causes an underflow when decrypting, resulting in a
null pointer dereference.
Fix the bug and add a regression test.
Approved by: so
Security: FreeBSD-SA-26:67.ktls
Security: CVE-2026-101302
Reviewed by: gallatin, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59767
(cherry picked from commit 7c5e457d3a)
(cherry picked from commit fc1a02c93b)
The FD_RESOLVE_BENEATH flag was intended to try to resolve bugzilla PR
262179 without entirely disallowing fd passing between jails. However,
one can use renameat() to bypass the restriction: upon receiving a
directory fd with FD_RESOLVE_BENEATH set, a jailed process can still
move its CWD or one of its ancestors to the directory, and just cd
out of its jail root.
So disallow renameat() when either the source or destination directory
fds has FD_RESOLVE_BENEATH set, like we do with fchdir() and fchroot()
to prevent similar escapes.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Security: CVE-2026-101305
PR: 262179
Reported by: [email protected]
Reviewed by: olce, kib
Differential Revision: https://reviews.freebsd.org/D59875
When an fdescfs mount has the nodup option set, fdesc_lookup(/dev/fd/n)
returns the vnode referenced by file descriptor n, rather than returning
an fdescfs vnode. This meant that fd metadata attached to fd n was not
preserved when reopening the file, which is contrary to the expected
semantics for capsicum rights and the UF_RESOLVE_BENEATH fd flag. For
regular fdescfs mounts, this metadata is copied via dupfdopen().
Fix the problem by passing up this metadata through the nameidata
structure. Thus, if one opens /dev/fd/n, the returned fd will inherit
UF_RESOLVE_BENEATH and the capability rights of fd n. Add some
regression tests as well.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Security: CVE-2026-101304
Reported by: Jan Bramkamp
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59886
These routines let one compute the intersection of two sets of filecaps
or capability rights, just as filecaps_merge() and cap_rights_merge()
compute the union. This will be useful in an upcoming patch.
filecaps_intersect() is complex due to the need to merge sets of ioctls.
For now this is implemented with a dumb nested loop on the basis that
ioctl lists are typically short enough that this is fine. It may be
better to instead sort the two lists first and step through them
together.
No functional change intended.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59885
In a couple of places we want to know whether someone has limited rights
on an fd. There, we want a predicate which determines whether the set
of rights is smaller than CAP_ALL, and whether there are explicit ioctl
or fcntl lists. Factor this out into a helper function, in preparation
for use elsewhere.
No functional change intended.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59884
semop() may sleep waiting for a semaphore. Upon waking up, it checks to
see if the set's sequence number has changed, indicating that the set
was removed. The sequence number is not wide enough to prevent a false
negative due to wraparound, in which case the subsequent access of
`semakptr->u.__sem_base[sopptr->sem_num]` may be out of bounds. This
race can be leveraged to elevate privileges.
Fix this by introducing a 64-bit sequence number for each semaphore
pool. This is wide enough to make the race impossible to hit. Allocate
a separate array for them, as we cannot really change the layout of
struct semid_kernel since some userspace tools (e.g., ipcrm(1)) embed
the layout.
While here, use semvalid() instead of open-coding its implementation,
convert a couple of flags to be bool, and use a better variable name to
store required permissions.
Approved by: so
Security: FreeBSD-SA-26:64.sysvsem
Security: CVE-2026-58098
Reported by: Reo Shiseki
Reported by: Andrew Griffiths
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59347
The 16-byte "device_name" field was not zero-filled, so could contain
uninitialized stack data. Zero the whole struct, as that's the
prevailing pattern for this kind of conversion code, and it's more
robust in the face of future revisions to struct devstat.
Approved by: re (cperciva)
Reviewed by: olce, kib
Reported by: Reo Shiseki
Fixes: a11d132f6c ("devstat: Provide 32-bit compatibility")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59309
(cherry picked from commit 7cb1a76f88)
(cherry picked from commit 6e94e0734b)
The check for whether shm_lp_psind was assigned was unlocked. This race
can be exploited to create an object with psind==2 but with only
pagesizes[1] worth of pages populated. This in turn can be used to
escalate privileges.
Fix this by acquiring the rangelock earlier. In shm_mmap_large(),
assert that we hold the rangelock. In shm_write(), annotate an unlocked
load of shm_lp_psind.
Approved by: re (cperciva)
Approved by: so
Security: FreeBSD-SA-26:63.posixshm
Security: CVE-2026-58094
Reported by: tsune of GMO Cybersecurity by Ierae, Inc. working with TrendAI Zero Day Initiative
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59104
The TIOCSCTTY ioctl handler drops the tty lock in order to acquire the
proctree relock. After relocking the tty, it did not revalidate the
tty state, and it could end up linking a doomed tty to the calling
process' session. This race can be exploited to escalate privileges.
TIOCSPGRP has a similar race, fix that too.
Approved by: re (cperciva)
Approved by: so
Security: FreeBSD-SA-26:62.tty
Security: CVE-2026-58093
Reported by: tsune of GMO Cybersecurity by Ierae, Inc. working with TrendAI Zero Day Initiative
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59126
Approved by: re (cperciva)
Reported by: Reo Shiseki
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59054
(cherry picked from commit 6cb7e368da)
(cherry picked from commit 55ee29bf35)
This function has a loop where it attempts to lock all channels in a
group. If doing so would block, it releases all locks, sleeps for a
bit, and tries again. However, once the syncgroup lock is dropped,
nothing prevents the syncgroup structure from being freed.
Fix the inner loop: after waking up, break out of it unconditionally and
start everything again. I think the old code was also buggy and not
well-exercised: after waking up we'd continue to try and continue
locking channels. Then we'd try again from the beginning and fail to
lock the channels we had already locked.
Approved by: re (cperciva)
Approved by: so
Security: FreeBSD-SA-26:58.sound
Security: CVE-2026-58091
Reported by: Hazley Samsudin of GovTech CSG
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58912
When a process execve()s, pmc_process_exec() is supposed to evaluate
whether the new image is setuid/setgid and if so, whether to detach
PMCs. This was handled by pmc_can_attach(), which is effectively an
open-coded copy of cr_xids_subset().
Unfortunately, the test of the result of this function was inverted,
with the result that we'd detach PMCs only if the predicate said it was
okay to do so. It appears the bug has always been there; it seems the
intent was to return 0 on "success", i.e., it is okay to attach the
PMCs, much like p_candebug(). Commits 1c3c698ba4 and 1c40b15971
obscured this a bit.
I think this check is trying to be too clever. Let's make it simpler:
simply do not attach PMCs unless the owner is privileged. This is how,
e.g., ktrace works. I do not think it's worth trying to be more
sophisticated than this unless we can generalize the policy in a way
that's applicable to other subsystems.
Also fix a bug at the end of pmc_process_exec():
pmc_detach_one_process() will call pmc_remove_process_descriptor() for
us.
Approved by: re (cperciva)
Approved by: so
Security: FreeBSD-SA-26:56.hwpmc
Security: CVE-2026-58089
Reported by: netchild
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59102
This function is supposed to wait until all pending callbacks have been
executed. This is useful in some contexts where we tear down some
context (like a VNET jail and its associated UMA zones) synchronously,
and we want to make sure that all pending asynchronous callbacks (which
may free objects to said UMA zones) have run first.
The implementation schedules a callback on each CPU and waits for them
all to run. This assumes that, on a given CPU, callbacks are executed
in the order that they are pushed. This assumption depends on the
implementation of epoch_call_task() and ck_epoch_poll_deferred(), and it
is not true in general.
Callbacks are pushed onto a per-CPU stack in LIFO order.
ck_epoch_poll_deferred() first pulls out the callbacks from epoch - 2,
which are always safe to execute, and in so doing reorders them such
that the oldest callback as at the top of the stack, so in this case,
epoch_call_task() will execute them in order. However,
ck_epoch_poll_deferred() may determine that it is safe to execute
callbacks from epoch - 1 (or even from the current epoch if there are
no active readers), and in this case it will push those callbacks onto
the returned stack. This means that epoch_call_task() will invoke those
newer destructors before the older ones, which means that
epoch_drain_callbacks() may return early.
Fix the correctness problem by simply doing all of this twice: once the
first callback is invoked, we know that all of the callbacks that were
pending at the time that epoch_drain_callbacks() was called are
scheduled to be executed, so when the second callback is executed we
know that they must be finished. This is slow, but it is already slow,
and the slowness is less noticeable after commit dce5659499.
I note that in an ideal world, this function would not exist, and all of
the teardown would happen asynchronously, rather than the current
mismash of synchronous and asynchronous cleanup.
Approved by: re (cperciva)
PR: 290201
Reviewed by: glebius
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D58030
(cherry picked from commit 7bf11a2f0c)
(cherry picked from commit 8eef466432)
The CTL High Availablity clustering feature allows a pair of hosts to
implement transparent failover. The implementation uses a TCP
connection to exchange messages. There is no authentication mechanism
and the protocol itself embeds kernel pointers in the messages exchanged
between HA hosts. This property (of CTL_MSG_DATAMOVE messages
specifically), as well as insufficient validation of inbound messages,
mean that anyone able to access a CTL HA port is able to remotely
execute code on that host.
Provide a warning to this effect in the CTL man page.
Approved by: re (cperciva)
Reported by: Ryan of Calif.io
Reviewed by: ziaee, ken, mav
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58622
(cherry picked from commit 3c8f8432b6)
(cherry picked from commit 43a34002f6)
Per RFC1717 section 5.1.3, the option length must be at least three.
Processing an undersized option would trigger a large out-of-bounds
write.
Approved by: re (cperciva)
PR: 271910
Reported by: Robert Morris
Reported by: Décio Brandão (0xDBJ)
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58554
(cherry picked from commit b9d07a4308)
(cherry picked from commit 30b4bdd451)
Each byte of the address is represented by a pair of characters, so we
should be multiplying len by 2 when figuring out how much buffer space
we have. Previously, a sufficiently large option could cause an
overflow of the global "result" buffer.
Approved by: re (cperciva)
Reported by: Joshua Rogers <[email protected]>
Tested by: Décio Brandão (0xDBJ)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58555
(cherry picked from commit e004ff15f8)
(cherry picked from commit 607c41d8f8)
p_reapsubtree lives in the p_startcopy/p_endcopy block of struct proc,
which is copied during fork without any synchronization. However, the
field is not stable except when the proctree lock is held, and indeed
may change if p1's reaper exits or explicitly releases its reaper
status. This state change can race with fork() and leave the child with
an incorrect p_reapsubtree field.
Close the race: explicitly copy the field under the proctree lock during
fork.
Approved by: re (cperciva)
Reported by: syzkaller
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58482
(cherry picked from commit 8616b7dc38)
(cherry picked from commit fb0af871db)
A v6 raw socket may ask the kernel to validate the checksum of an
inbound packet. If it does, and the validation fails, we discard the
packet, but this isn't really right: other raw sockets may wish to
receive a copy of the packet anyway.
Rework checksum handling to address this problem, and use a flag to
avoid computing the checksum more than once for a given packet.
Approved by: re (cperciva)
Fixes: de2d47842e ("SMR protection for inpcbs")
Reviewed by: pouria, glebius
Reported by: Yunzhi Ke
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58559
(cherry picked from commit 196874ce2e)
(cherry picked from commit 1fe3a2897b)
When the first loop in inm_merge() hits an error, generally because it
hit some limit on the number of source filters for a multicast group,
inm_merge() tries to atomically roll back changes to the group source
filter list.
To roll back, it iterates over the global source filter list for the
multicast group, starting at the last entry that we updated ("nims").
But, if we have not yet updated any entries, this variable is
uninitialized. Initialize it to NULL, so that RB_FOREACH_REVERSE_FROM
doesn't visit any source filters in this case.
All of the above applies to the v6 case.
Approved by: re (cperciva)
Reported by: Daniel Birtwhistle
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
(cherry picked from commit b9db5a5b16)
(cherry picked from commit 843ef89615)
The implementation previously only generated an IN_IGNORED event for a
deleted watched file if the watch explicitly requested IN_DELETE_SELF.
This is not correct, IN_IGNORED should always be raised when the watched
subject is deleted. Adjust the implementation of inotify_log_one()
accordingly.
This also fixes a problem where a deleted watched file's watch
would not be removed if IN_DELETE_SELF was not in the watch's event
mask, in which case the unlinked vnode would linger until the inotify
descriptor itself is closed.
Add a regression test.
Reported by: jrtc27
Reviewed by: jrtc27
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D58050
(cherry picked from commit b70997c8c7)
The IN_MOVED_FROM and _TO events only apply to names in a watched
directory, never to a watched directory itself. So, the cookie value
there is always zero, and in particular we should not reset the
caller-provided cookie value, as it may be used later.
Add a regression test.
Reported by: arrowd
MFC after: 1 week
(cherry picked from commit da8ab13249)
For 15.0, apply a minimal fix which at least ensures that inotify can't
trigger the latent race described in commit 99cb3dca47 ("vnode: Rework
vput() to avoid holding the vnode lock after decrementing").
Reviewed by: olce, kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53774
(cherry picked from commit ebc17879f0)
The inotify flags are copied from the lower vnode into the nullfs vnode
so that the INOTIFY() macro will invoke VOP_INOTIFY on the nullfs vnode;
this is then bypassed to the lower vnode. However, when a nullfs vnode
is reclaimed we should clear these flags, as the vnode is now doomed and
no longer forwards VOPs to the lower vnode.
Add regression tests. Remove a test in vn_inotify_revoke() which is no
longer needed after this change.
PR: 292495
Reviewed by: kib
Reported by: Jed Laundry <[email protected]>
Fixes: f1f230439f ("vfs: Initial revision of inotify")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56639
(cherry picked from commit a02d794f5a)
In cache_vop_inotify(), we call inotify_log() with a namecache hash lock
held. inotify_log() looks at all watches registered with the vnode to
see if any of them are interested in the event. In some cases, we have
to detach and free the watch after logging the event. This means we
must vrele() the watched vnode, and this must not be done while a
non-sleepable lock held.
Previously, I deferred the vrele() to until the inotify softc and vnode
pollinfo locks were dropped. However, this is not enough since we may
still be holding the aforementioned namecache lock. Go further and use
a taskqueue thread to release vnode references. Introduce a set of
detached watches, and queue a threaded task which releases the vnode
reference.
Reported by: [email protected]
Reviewed by: kib
Fixes: f1f230439f ("vfs: Initial revision of inotify")
Differential Revision: https://reviews.freebsd.org/D51685
(cherry picked from commit c2230ad3b1)
When hooking vop_rename_post(), the preexisting dst vnode will be
unlocked. But, we need to invoke VOP_GETATTR on it in vn_inotify() to
check its link count.
In inotify_unlink_watch_locked(), the vnode interlock is not held, so
don't use vn_irflag_unset_locked().
Reviewed by: kib
Fixes: f1f230439f ("vfs: Initial revision of inotify")
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51401
(cherry picked from commit af0ec3fa29)
Otherwise gcc warns that strcmp() will read a byte from a zero-length
array, though in practice we exclude that case with an explicit length
check.
Fixes: f1f230439f ("vfs: Initial revision of inotify")
(cherry picked from commit bc6b526e2b)
Implement the Linux inotify system calls using the native implementation
in vfs_inotify.c.
PR: 240874
Reviewed by: brooks
MFC after: 3 months
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D50761
(cherry picked from commit 3965de642c)
The INOTIFY macro and its variants check if the vnode is being watched,
and if so, calls into a slow path which adds an event to one or more
inotify descriptors. Most of these events correspond to EVFILT_VNODE
events as well, and are added to VOP *_post hooks.
Reviewed by: kib
MFC after: 3 months
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D50315
(cherry picked from commit bc4430dc20)
inotify_init() and inotify_init1() are implemented using __specialfd(2).
inotify_add_watch() is implemented in terms of inotify_add_watch_at(2).
Reviewed by: kib
MFC after: 3 months
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D50315
(cherry picked from commit 245ff4c4b2)
Add an implementation of inotify_init(), inotify_add_watch(),
inotify_rm_watch(), source-compatible with Linux. This provides
functionality similar to kevent(2)'s EVFILT_VNODE, i.e., it lets
applications monitor filesystem files for accesses. Compared to
inotify, however, EVFILT_VNODE has the limitation of requiring the
application to open the file to be monitored. This means that activity
on a newly created file cannot be monitored reliably, and that a file
descriptor per file in the hierarchy is required.
inotify on the other hand allows a directory and its entries to be
monitored at once. It introduces a new file descriptor type to which
"watches" can be attached; a watch is a pseudo-file descriptor
associated with a file or directory and a set of events to watch for.
When a watched vnode is accessed, a description of the event is queued
to the inotify descriptor, readable with read(2). Events for files in a
watched directory include the file name.
A watched vnode has its usecount bumped, so name cache entries
originating from a watched directory are not evicted. Name cache
entries are used to populate inotify events for files with a link in a
watched directory. In particular, if a file is accessed with, say,
read(2), an IN_ACCESS event will be generated for any watched hard link
of the file.
The inotify_add_watch_at() variant is included so that this
functionality is available in capability mode; plain inotify_add_watch()
is disallowed in capability mode.
When a file in a nullfs mount is watched, the watch is attached to the
lower vnode, such that accesses via either layer generate inotify
events.
Many thanks to Gleb Popov for testing this patch and finding lots of
bugs.
PR: 258010, 215011
Reviewed by: kib
Tested by: arrowd
MFC after: 3 months
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D50315
(cherry picked from commit f1f230439f)
Reported by: Chris Jarrett-Davies of the OpenAI Codex Security Team
Reviewed by: pouria, kp
Fixes: 0361f165f2 ("ipsec: replace SECASVAR mtx by rmlock")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58521
(cherry picked from commit b6823a9737)
Otherwise ktls_mbuf_crypto_state() will reject mbufs created by
_mb_unmapped_to_ext(), which arises when transmitting packets through an
interface that doesn't support unmapped mbufs, and the loopback
interface in particular.
PR: 296498
Fixes: 3444414cb4 ("ktls: Don't attempt to modify non-anonymous mbufs on the receive path")
Reviewed by: gallatin, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57557
(cherry picked from commit 815976ee14)
Several functions were using sprintf() to write RPC server-controlled
data to a stack buffer. Adopt some minimal changes from NetBSD to avoid
the potential overflows.
Security: CVE-2026-16277
Security: CVE-2026-16461
Reviewed by: khorben
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58441
(cherry picked from commit 152ba2d3c5)
When we drop the prefix lock to call nd6_prefix_offlink() or
nd6_prefix_onlink(), make sure to keep the correpsonding prefix
structure alive. It is possible for a concurrent nd6_timer() to expire
the prefix while the lock is dropped.
Reported by: Maik Muench of Secfault Security
Reviewed by: pouria, zlei
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58423
(cherry picked from commit 76ca489e0f)
The FD_RESOLVE_BENEATH flag is supposed to be sticky. It's set when you
receive an fd from a different jail and preserved by openat(<dfd>) etc..
However, if you send the fd to yourself, the flag is stripped since
SCM_RIGHTS message don't preserve file descriptor flags.
Fix this by preserving those flags and checking for UF_RESOLVE_BENEATH
in restrict_rights().
Fixes: 350ba9672a ("unix: Set O_RESOLVE_BENEATH on fds transferred between jails")
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58317
(cherry picked from commit 586e2b3d89)
Fixes: 9636299233 ("kthread_add(): do not allow to attach the thread to a dead or dying process")
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58433
(cherry picked from commit c7917e72fe)
After commit 848f360c8f, if one tries to connect to a closed port,
fetch reports "Operation now in progress", which is rather confusing.
Return a more useful error message, restoring the old behaviour.
Fixes: 848f360c8f ("libfetch: Apply timeout to connection attempts")
Reviewed by: des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58481
(cherry picked from commit b02e02958d)
In an ELF coredump, each dumped vm_map_entry is represented by a
segment. __elfN(coredump) first computes the number of segments by
looping over the vm_map entries (in each_dumpable_segment()), then
allocates a buffer to hold the ELF header and program headers, then
loops over the entries again to populate the program headers.
each_dumpable_segment() holds the vm_map read lock, but that lock is
dropped between the two calls. If the map is shared with another
process, via rfork(), then the map can change. cb_put_phdr() did not
account for this, and so could write out of bounds.
Add a check to prevent this; simply do not write out excess segments.
Approved by: so
Security: FreeBSD-SA-26:55.elf
Security: CVE-2026-58088
Reported by: Maik Muench of Secfault Security
Reviewed by: kib, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58416
These commands take a snapshot of the size of a semaphore set, then drop
the lock and malloc an appropriately sized array before reacquiring the
lock. A comment explains why this is (probably) safe. Unfortunately,
it's wrong; it is indeed possible for a malicious userspace to create
and destroy 2^{15} sets in the window where the lock is dropped. This
race can lead to out-of-bounds reads and writes, and that can be
exploited to elevate privileges.
Replace the assertions with runtime checks.
Approved by: so
Security: FreeBSD-SA-26:54.sysvsem
Security: CVE-2026-58087
Reported by: Maik Muench of Secfault Security
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58421
A vm_page's a.queue field records the page queue index for the page
queue to which the page belongs. The PGA_ENQUEUED flag indicates
whether the page is actually enqueued in that queue's TAILQ. When
modifying the a.queue field, you need to hold the page queue lock for
the queue corresponding to the old value, unless the old value is
PQ_NONE.
Suppose a managed page is freed. vm_page_free_prep() calls
vm_page_dequeue_deferred(), which checks whether the page belongs to a
queue; if so it schedules an asynchronous dequeue operation so that page
queue lock acquisitions can be batched if possible.
The dequeue operation must be completed before the page's plinks.q
fields are reused. So, during page allocation, we call
vm_page_dequeue() to finish the dequeue operation. Similarly, since the
buddy allocator uses the plinks.q fields for its own internal linkage,
vm_freelist_add() calls vm_page_dequeue().
_vm_page_pqstate_commit_dequeue() is the function which actually removes
the page from its queue. It sets a.queue = PG_NONE and removes the page
from its queue. However, the update to the page's atomic state is
relaxed, so on systems with store reordering, it may race with a
concurrent enqueue of the page into the buddy queues (probably more
likely) or a page queue.
Fix this: use a release store to update the page's queue state in
_vm_page_pqstate_commit_dequeue(), and make sure that vm_page_dequeue()
uses an acquire load when comparing m->a.queue == PQ_NONE.
PR: 296767
Reported and tested by: pkubaj
Reviewed by: alc, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D58261
(cherry picked from commit d809a10218)
The taskqueue thread loop tries to avoid entering and exiting net epoch
read sections for every task. This reduces the overhead of net epoch
integration, but the implementation wasn't bounding the length of the
read section, so a busy taskqueue thread could hold an epoch open for an
unbounded period. This is easy to achieve with the epair task, for
instance.
Bound the number of tasks that we'll execute without observing the
global epoch, and provide a sysctl to control it. Let the default bound
be eight.
Reviewed by: glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D58031
(cherry picked from commit a58590631c)
The entry size of the probe section is assumed to be at least
sizeof(dof_probe_t) by the loop further below.
enoff_sec->dofs_entsize was not being validated at all.
When multiplying an index by a table entry size, make sure the
multiplication can't overflow.
Fix an off-by-one when validating the translated probe argument array.
Make sure that the probe argument argvs are valid string offsets
even if the argument count is zero.
Reviewed by: christos
MFC after: 2 weeks
Sponsored by: CHERI Research Centre
Differential Revision: https://reviews.freebsd.org/D57979
(cherry picked from commit 7f5fa76367)
The check for a nul terminator implicitly assumes that the section size
is positive. Make the assumption explicit.
Reviewed by: christos
MFC after: 2 weeks
Sponsored by: CHERI Research Centre
Differential Revision: https://reviews.freebsd.org/D57977
(cherry picked from commit b56b601c5b)
We must ensure that each DOF section does not overlap with the DOF
header or section table. Otherwise the relocations processed in the
second pass over sections can manipulate DOF metadata, leading to OOB
writes.
Reviewed by: christos
MFC after: 2 weeks
Sponsored by: CHERI Research Centre
Differential Revision: https://reviews.freebsd.org/D57976
(cherry picked from commit 8dc98f4d25)
The loop which validates each DOF section assumes that the section
header is present, so the section size must be at least as large as the
header, otherwise a small OOB access is possible.
Reviewed by: christos
MFC after: 2 weeks
Sponsored by: CHERI Research Centre
Differential Revision: https://reviews.freebsd.org/D57975
(cherry picked from commit c1b6ebc2b7)
The test relies on being able to assign the same interface address to
two different tap interfaces; it then removes one of the addresses,
which at one point would trigger a kernel panic.
Since 361a8395f0 it is not possible to assign an address multiple
times this way, so the test fails. Just mark it as expected to fail for
now: if the kernel's behaviour here changes again, this test might be a
useful seatbelt.
MFC after: 2 weeks
(cherry picked from commit 6bdc9743d8)
linux_sys_futex() does not copyin a timespec for the timeout if the
operation is LINUX_FUTEX_TRYLOCK_PI, presumably because it doesn't make
sense to specify a timeout for a try-lock operation. However, this
means that we pass a userspace timespec pointer to
linux_umtx_abs_timeout_init().
Modify linux_futex_lock_pi() to not initialize the timeout if we're
try-locking.
Reviewed by: kib, dchagin
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li,
and Ke Xu from Tsinghua University using GLM-5.2 from Z.ai
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58061
(cherry picked from commit 407c7c339a)
Use ATF to wrap the new reimplementation of pjdfstest that came out of
GSOC 2022, now available in the ports tree as filesystems/pjdfstest.
So far I added tests for UFS (with several different option
combinations), tmpfs and ZFS, plus ZFS+nullfs. All of these create a
memory disk, initialize the filesystem, and point the pjdfstest
executable at it.
In the future it would be good to add tests for at least NFS and p9fs.
Reviewed by: asomers
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56605
(cherry picked from commit 8fd4d1c0ff)
After commit 853cd87234 it became invalid for kinst_invop() to return
0: dtrace_invop_start() would convert this to a sentinel value
indicating that it did not consume the breakpoint, and so we'd just
call kdb_trap() to handle it.
Change kinst_invop() to return NOP_INSTR after handling a matching
breakpoint. NOP_INSTR is handled by advancing the ELR, so we have to
compensate by subtracting INSTR_SIZE before returning.
Reviewed by: christos
MFC after: 1 week
Fixes: 853cd87234 ("arm64: Clean up usage of the dtrace invop handler")
Differential Revision: https://reviews.freebsd.org/D56987
(cherry picked from commit d6f0e671d0)
libalias maintains a global list of all libalias handles. The list was
updated without any locking, but nothing prevents updates from running
concurrently.
MFC after: 1 week
(cherry picked from commit 2ff705f32a)
This extends stack canary use to all functions which define arrays on
the stack, not just those which operate on byte buffers. This option
would have made it harder to exploit SA-26:18.setcred and
SA-26:08.rpcsec_gss.
The change bloats the amd64 kernel text by about 350KB and increases the
number of covered functions from ~1500 to ~9000 (within the kernel
itself, i.e., not counting kernel modules).
Reviewed by: olce, olivier, emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56870
(cherry picked from commit 8deebce931)
The check for the extended signature table was backwards, so we always
ignored it.
We should verify that the extended signature table fits within the total
image size.
Reviewed by: jrm, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57209
(cherry picked from commit 0beb172898)
/sbin/ping and /sbin/ping6 are hard-linked, and the vmmap sysctl handler
doesn't know which name was used to launch the process.
PR: 296116
MFC after: 3 days
Fixes: 080a408701 ("tests: Fix race condition in aslr_setuid")
(cherry picked from commit 81cf9a0ca7)
In the ISO2022-CN encoding, characters may require at least seven bytes,
and MB_LEN_MAX==6 is insufficient. From code inspection,
_ISO2022_sputwchar() can emit 10 bytes in the worst case, so use that to
size buffers.
Add a regression test.
Approved by: so
Security: FreeBSD-SA-26:49.iconv
Security: CVE-2026-58082
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D57950
wcrtomb may store up to 2 2-byte escape sequences to the state buffer in
addition to the character itself. In the worst case, a 3-byte heap
overflow is possible.
Approved by: so
Security: FreeBSD-SA-26:49.iconv
Security: CVE-2026-58081
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D57949
sendfile(2) can transmit POSIX shared memory objects. Typically it will
look up and wire each page before sending it to a socket; once
transmission is complete, the page is unwired and typically released
back into the page queues. sendfile() has an advisory flag, SF_NOCACHE,
which means, "try to free the page once transmission is complete." This
is implemented in vm_page_release(), which expects to operate on managed
pages.
Pages belonging a largepage object are de-facto wired not explicitly so.
Thus, vm_page_release() will unwire and, having found no additional
references, free the page. Because mappings of largepage objects are
unmanaged, userspace can still access the now freed page.
Fix the problem by explicitly wiring largepage pages. Make the VM
object destructor responsible for unwiring and freeing them.
Add a regression test.
Approved by: so
Security: FreeBSD-SA-26:44.posixshm
Security: CVE-2026-49427
Reported by: Chris Jarrett-Davies <[email protected]>
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57832
We correctly handled ftruncate(), but not open(O_TRUNC).
Add a regression test.
Approved by: so
Security: FreeBSD-SA-26:44.posixshm
Security: CVE-2026-49428
Reported by: Chris Jarrett-Davies <[email protected]>
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57831
As with truncation, the operation isn't supported, but nothing prevented
it.
Add a regression test.
Approved by: so
Security: FreeBSD-SA-26:44.posixshm
Security: CVE-2026-49428
Reported by: Chris Jarrett-Davies <[email protected]>
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57830
Malicious userspace might switch TCP stacks twice while the inpcb lock
is dropped. If it does so, the validation of tp->t_fb might succeed,
but the saved pointer to the stack PCB might be invalid. Reload it to
avoid this problem, as BBR already does.
Approved by: so
Security: FreeBSD-SA-26:43.tcp
Security: CVE-2026-49422
Reported by: Maik Münch
Reviewed by: tuexen
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57791
The unlinkat(2) and funlinkat(2) system calls were ignoring
AT_RESOLVE_BENEATH.
Also pass pathseg through instead of assuming it's UIO_USERSPACE.
Add some tests which make sure that AT_RESOLVE_BENEATH is handled
properly by various system calls.
Approved by: so
Security: FreeBSD-SA-26:42.unlinkat
Security: CVE-2026-49421
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57790
Mark Johnston