jail: prevent a race between jail_attach in different threads
Attaching to a jail changes its root directory and its process
credentials. These operations both require unlocking the jail, and also
need allprison_lock unlocked. That means that if two threads are trying
to attach to different jails at the same time, it's possible for the
process to end up with one jail's root directory but the other jail's
credentials.
Solve this by forcing the process into single-threaded mode during
system calls that attach to a jail (jail_attach, jail_attach_jd, and
sometimes jail_set).
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D57858
(cherry picked from commit d4e0f4dab2d7f4de46bb79db1ca7e6e8a2e34746)
jail: clean up locking around do_jail_attach
jail_attach_jd passed PD_DEREF to do_jail_attach, assuming it would take
care of freeing the held prison. This is not true, as do_jail_attach
immediately cleared that flag, leaving the jail stock in dying state
when it is later removed.
Reported by: markj
Reviewed by: markj
Differential Revision: <https://reviews.freebsd.org/D57674>
(cherry picked from commit 3584cde63e416d150214192721cead4b735ca0b5)
jail: call PR_METHOD_ATTACH again (with old jail) if the first call fails
jail_attach lets modules do attachment-specific work by calling
osd_jail_call(PR_METHOD_ATTACH). If one of the modules returns an
error, the call needs to be repeated with the thread's current prison,
so possible earlier modules and undo any changes they may have made.
(cherry picked from commit e91e8ebefadcce9d57c8ff945ff70050cbbe1ce1)
jail: prevent a race between jail_attach in different threads
Attaching to a jail changes its root directory and its process
credentials. These operations both require unlocking the jail, and also
need allprison_lock unlocked. That means that if two threads are trying
to attach to different jails at the same time, it's possible for the
process to end up with one jail's root directory but the other jail's
credentials.
Solve this by forcing the process into single-threaded mode during
system calls that attach to a jail (jail_attach, jail_attach_jd, and
sometimes jail_set).
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D57858
(cherry picked from commit d4e0f4dab2d7f4de46bb79db1ca7e6e8a2e34746)
jail: prevent a null derefence on array parameter assignment
The same variable was used as a counter for an inner and out loop.
Add a new one for the inner loop.
PR: 283934
Reported by: crest at rlwinm.de
(cherry picked from commit 6d9bc46cd7fc48ece597162d3ca413fc9d67b5f0)
jail: prevent a null derefence on array parameter assignment
The same variable was used as a counter for an inner and out loop.
Add a new one for the inner loop.
PR: 283934
Reported by: crest at rlwinm.de
(cherry picked from commit 6d9bc46cd7fc48ece597162d3ca413fc9d67b5f0)
nfs_clstate.c: Fix handling of delegation upgrades
Commit 016570c4463d modified the client to handle
the upgrade of a read delegation to a write delegation,
where the server provides the same delegation stateid
to the client. However, it failed to check if the
delegation structure was currently in use. Without this
patch, if the structure was in use, a use after free
could occur.
This patch handles the "in use" case by copying the
necessary fields into the current/old structure and
free's the new one instead of the old one that is
"in use".
PR: 296224
MFC after: 2 weeks
sound: Use sx_assert instead of KASSERT(sx_xlocked())
It's redundant.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
(cherry picked from commit 72acd1720af365e6fd186cc1706994d72c43650a)
snd_dummy: advance pointers for both channels
Previously only the play pointer advanced each tick; the record channel
refilled the whole buffer with silence and left the DMA pointer at 0.
Advance the record pointer by one block per tick and fill that block
with silence, so the DMA pointer changes and mmap kqueue consumers can
track progress.
MFC after: 1 week
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D57834
(cherry picked from commit 968e748c439a50ad0a1a4463f4753f58a2bdaf9f)
Revert "zfs: Wire sha512 offload to the build"
This reverts commit cd61eb4f6681b13d98b6a7be252500ad30f05f74.
Some people report module load failure due to undefined symbol.
I don't have those problems myself, so it might be a question of
full rebuild. But I don't have time right now, so just revert.
sys/systm.h: include sys/limits.h for SSIZE_MAX
This makes the header more self-contained.
The symbol is needed only on 32bit arches, but the include file is
provided unconditionally to make the namespace population predictable.
PR: 296489
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
iwn: assign sequence number to raw transmit frames
This fixes associating to various APs.
It worked fine to a FreeBSD AP (which is a wholly separate problem
I'm going to need to dive into) but not to my tplink AX1800 Wifi-6
router.
PR: kern/296503
Locally tested:
* STA: Intel Centrino Advanced-N 6205 (iwn), Lenovo T420
* AP: TP-Link AX1800 wifi-6 router
tests/aslr: Fix spurious test failures
/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: 080a4087014e ("tests: Fix race condition in aslr_setuid")
autofs: enable witness for autofs node lock
Previously, an_vnode_lock was initialized with SX_NOWITNESS to silence
lock order reversals. The reversals would occur when autofs_node_vn()
was called with the directory vnode lock held, then lock an_vnode_lock,
then lock the vnode attached to the autofs node. It looked like:
directory vnode -> an_vnode_lock -> vnode attached to autofs node
The established lock order is now vnode -> an_vnode_lock
Currently, we don't have to worry about losing an autofs node during the
unlock/lock as autofs nodes are only removed during an unmount() after
vflush(). When autofs_node_vn() is called, the mountpoint has either
been busied (preventing unmount) or a directory vnode is locked which
prevents vflush() from finishing until the directory vnode is unlocked.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D57857
fusefs: fix vnode locking violations during execve
Fix two locking violations that could happen during execve, while
executing a file stored on fusefs. Both would cause panics on an
INVARIANTS kernel after 15.0, or a DEBUG_VFS_LOCKS kernel prior to that.
Neither is likely to be noticeable on a release kernel.
* Don't assume that the vnode is exclusively locked during VOP_CLOSE.
It usually is thanks to !MNTK_LOOKUP_SHARED, but isn't during execve,
which locks the vnode outside of the lookup path.
* Totally rewrite fuse_io_invalbuf. It's had a number of problems ever
since its original introduction[^1]:
- Don't assume that the vnode is exclusively locked. That assumption
failed during execve just like the assumption in fuse_vnop_close.
- Don't livelock forever if vinvalbuf returns ENOSPC or EDQUOT.
[20 lines not shown]
hwpstate_amd(4): Use new cpu_get_pcpuid(), constify related variables
Also, add a check in the attach method that a per-CPU structure is
provided by the bus. This allows to remove such checks in multiple
functions. The check cannot currently fail as all x86 CPU drivers
(ACPI, legacy) provide the CPU_IVAR_PCPU instance variable, but it is
safer to have it, especially as an example to other driver writers.
Event: Halifax Hackathon 202606
Location: Seat 25A in AF0349, before leaving Montréal-Trudeau
Sponsored by: The FreeBSD Foundation
hwpstate_intel(4): Use new cpu_get_pcpuid(), constify related variables
Also, add a check in the attach method that a per-CPU structure is
provided by the bus. This allows to remove such checks in multiple
functions. The check cannot currently fail as all x86 CPU drivers
(ACPI, legacy) provide the CPU_IVAR_PCPU instance variable, but it is
safer to have it, especially as an example to other driver writers.
Event: Halifax Hackathon 202606
Location: Seat 36K in AC667, still waiting for a gate at Montréal-Trudeau
Sponsored by: The FreeBSD Foundation
cpu: New cpu_get_pcpuid(), retrieves internal CPU ID
It is a handy shortcut that will be used extensively in
hwpstate_intel(4) and hwpstate_amd(4).
Warn users that it panics if the parent bus does not provide the
CPU_IVAR_PCPU instance variable. That condition should be tested by
callers (doing so once is enough). Suggest to do that in driver's
attach method.
Reviewed by: jhb (code)
Event: Halifax Hackathon 202606
Location: Seat 36K in AC667, waiting for a gate at Montréal-Trudeau
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57897
newvers.sh: Avoid spurious -dirty in git revision
If git is installed and .git exists but git rev-parse failed to report a
hash we previously produced just "-dirty" as the git revision. Gate the
git commit count and -dirty check on the rev-parse passing.
Reviewed by: jlduran
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57995
netlink: add const variants of NLA iteration macros
Add const-qualified versions of the NLA iteration helpers to allow
walking immutable netlink attribute buffers without discarding const
qualifiers.
This introduces NLA_NEXT_CONST(), _NLA_END_CONST(), and
NLA_FOREACH_CONST() in netlink_snl.h.
Signed-off-by: Ishan Agrawal <iagrawal9990 at gmail.com>
Sponsored-by : Google LLC (GSoC 2026)
ffs: do not return ESTALE on attempt to ffs_unotovp() on unlinked inode
The consequences are:
- for nfs exports and fhopen(2), unlinked but still referenced inodes
are accessible
- for ffs_vput_pair() with unlock_vp = false, spurious ESTALE is not
returned when the inode is still alive but unlinked
Note that tmpfs does not return ESTALE for the unlinked nodes.
The same behavior is claimed for Linux in
https://github.com/openzfs/zfs/issues/18699
Reviewed by: rmacklem
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57982
acpi: ignore wake button press replayed by firmware on resume
Some firmware delivers the power or sleep button press that woke the
system as an ordinary button press (Notify 0x80) shortly after resume,
rather than as the wakeup notification (Notify 0x02) the ACPI
specification requires for a button that is also a wake source.
On affected machines (e.g. the Framework Laptop 12, Intel Raptor Lake-P)
the power button is a control-method device behind the embedded
controller. The EC latches the key press that woke the system across the
sleep transition and flushes it through its normal _Qxx query path as
soon as it is reinitialized on resume. The replayed press is
indistinguishable from a genuine one, so the kernel honors it as a fresh
suspend request and the machine suspends again immediately after waking;
it cannot be kept awake with the button.
The event cannot be filtered at its source: it arrives over the same EC
query path that also carries legitimate events (lid, AC, thermal,
battery), so suppressing the drain would lose real notifications.
[24 lines not shown]
jail: prevent a race between jail_attach in different threads
Attaching to a jail changes its root directory and its process
credentials. These operations both require unlocking the jail, and also
need allprison_lock unlocked. That means that if two threads are trying
to attach to different jails at the same time, it's possible for the
process to end up with one jail's root directory but the other jail's
credentials.
Solve this by forcing the process into single-threaded mode during
system calls that attach to a jail (jail_attach, jail_attach_jd, and
sometimes jail_set).
Reviewed by: kib, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D57858
src.conf(5): Suggest using ccache4
We have separate ports for Ccache 3 and 4. Suggest both, rather than
only the Ccache 3 port. Rearrange the text somewhat to avoid an
excessively ragged edge on a standard 80-column terminal.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58005
irdma(4): update irdma to version 1.3.56-k
Update Intel irdma driver to version 1.3.56-k
Notable changes:
- adding E830 support
- adding E835 support
Signed-off-by: Sobczak, Bartosz <bartosz.sobczak at intel.com>
Reviewed by: Andrew Zhu <anzhu at netapp.com>
Tested by: Mateusz Moga <mateusz.moga at intel.com>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D55479
(cherry picked from commit 5b7aa6c7bc9db19e8bd34a5b7892fb5df2a3068b)
