pf was too strict when validating SCTP tags. When a server receives a
retransmitted INIT it will reply with a random initiate tag every time.
However, pf saves the first initiate tag and expects every subsequent INIT_ACK
retransmission to have the same tag. This is not the case, leading to endless
INIT/INIT_ACK cycles.
Allow the tag to be updated as long as we've not gone past COOKIE_WAIT.
Add a test case to verify this.
MFC after: 2 weeks
See also: https://redmine.pfsense.org/issues/16516
Sponsored by: Rubicon Communications, LLC ("Netgate")
If we fail to open /dev/pf don't try to close it again. That would result in
errno getting overwritten by close(), hiding potentially useful information.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
In 95c20faf11 and ecd8245e0d kib introduced support to have the
kernel linker stop resolving local symbols from other files, but did
not enable it by default to avoid surprises. Flip the default now,
before FreeBSD 16.0.
The debug.link_elf_leak_locals and debug.link_elf_obj_leak_locals
sysctls are available to revert to the previous behaviour if necessary.
PR: 207898
Reviewed by: bz
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47742
Ensure the offp capability bounds cover entire struct with checksum fields.
This is needed for CHERI systems to avoid bounds violation trap, as
otherwise offp allowed to dereference 4 bytes of csum_flags field only
so bzero failed.
Tested on ARM Morello.
Reviewed by: kbowling
Discussed with: jrtc27
Sponsored by: CHERI Research Centre
Differential Revision: https://reviews.freebsd.org/D53903
The NVME controller in Crucial P310 disk does not accept 16-byte aligned
host memory buffer on Codasip Prime platform, but works fine on PAGE_SIZE
aligned memory.
Instead of adding a quirk, just increase alignment for everyone.
Reviewed by: jhb
Discussed with: imp
Sponsored by: CHERI Research Centre
Differential Revision: https://reviews.freebsd.org/D53296
In practice this just ends up as an orphan section and so is placed next
to .rodata-like sections, so it's pretty harmless, but not intended.
Fixes: a095390344 ("Use a template assembly file for firmware object files.")
ZFSSRC is abiguous on its surface and too clos to ZFSTOP, so rename it
to SAZFSSRC.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D53901
Use ZFSTOP instead of OZFS. They are the saame thing.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D53900
Because setcred() has (always) treated the effective GID separately from
the supplementary groups, when cr_groups[0] was storing the effective
GID, it internally needed to build an array containing both the
effective GID and the specified supplementary groups to eventually call
crsetgroups_internal().
As kern_setcred() was only used to actually implement
user_setcred()/sys_setcred(), which need to allocate a buffer to copy in
the userland groups array into, some optimization was put in place where
these would allocate an array with one more element than
'wc_supp_groups', copyin() the latter into the subarray starting at
index 1 and pass the pointer to the whole array to kern_setcred() in
'preallocated_groups'. This would allow kern_setcred() not to have to
allocate memory again to make room for the additional effective GID.
Since commit be1f7435ef ("kern: start tracking cr_gid outside of
cr_groups[]"), crsetgroups_internal() only takes supplementary groups,
so this machinery has become obsolete. It was not removed as part of
that commit, but just minimally amended to simplify the changes and
lower the risks. Finally remove it.
Reviewed by: kevans
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53772
If the basis for supplementary groups are the current ones, we do not
need to fetch them when they are to be replaced entirely (which we
already have been doing), as in the '!start_from_current_groups' case,
but specifically also when they are not going to be touched at all.
This change in passing makes the modified code block's comment saying
that SETCREDF_SUPP_GROUPS need not be set here correct.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53771
It was found that in some circumstances when launching
non-waiting create qhash cqp operation the refcount on
the cqp_request may be not properly decremented leading to a memory
leak.
Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com>
Reviewed by: anzhu_netapp.com
Tested by: mateusz.moga_intel.com
Approved by: kbowling (mentor)
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D53732
Prior to commit 0c511bafdd, each time
snl_realloc_msg_buffer was called, it called snl_allocz to request a
new buffer. If an existing linear buffer was used, then after the
call, the linear buffer effectively contained the old buffer contents
followed by the new buffer (so there was definitely wasted memory),
but the linear buffer state was consistent (lb->offset correctly
accounted for both copies). For example, if the initial linear buffer
was 256 bytes in size, lb->size would be 256. Using 16 bytes followed
by 32 bytes would first set lb->offset to 16, then the second realloc
would allocate 48 bytes (16 + 32) setting lb->offset to 64 (16 + 48).
Commit 0c511bafdd aimed to avoid this
memory waste by resetting the base pointer to the start of the
existing linear buffer if the new allocation was later in the same
linear buffer. This avoided some of the waste, but broke the
accounting. Using the same example above, the second realloc would
reuse the pointer at an offset of 0, but the linear buffer would still
claim that 64 bytes was allocated via lb->offset rather than the true
allocation of 48 bytes.
One approach to fix this would be to "extend" the allocation of an
existing linear buffer where a realloc would try to increase
lb->offset without setting a new base pointer so long as there was
still room remaining in the linear buffer for the new request.
However, this change takes a simpler approach. If snl_allocz()
returned an allocation from a new linear buffer, just claim the entire
linear buffer for use by the snl_writer ensuring the accounting is
correct in both the linear buffer and the snl writer. With this
approach, the initial snl_writer size would be 256 bytes for a 256
byte linear buffer and would only grow if it needs to allocate an
entirely new linear buffer.
Reviewed by: igoro
Fixes: 0c511bafdd ("netlink: fix snl_writer and linear_buffer re-allocation logic")
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D53697
This is the more typical style used in compat syscalls. Modern
compilers are smart enough to coalesce multiple member assignments
into a bulk copy.
Reviewed by: olce, brooks
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D53757
This is the more typical approach used in the tree for system calls
with per-ABI structure layouts.
Reviewed by: olce, brooks
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D53756
This removes mac_label_copyin32() as mac_label_copyin() can now handle
both native and 32-bit struct mac objects.
Reviewed by: olce, brooks
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D53755
Define this helper variable in one place and make it available while
building the entire base system.
Reviewed by: sjg
Obtained from: CheriBSD (mostly)
Differential Revision: https://reviews.freebsd.org/D53790
Clear the RSS hash on transmit, now that RSS hashing is enabled
unconditionally, and the network stack may want to trust that
it is getting the correct hash on input.
Differential Revision: https://reviews.freebsd.org/D53090
Reviewed by: zlei
Sponsored by: Netflix
When in restricted mode, the slirp-helper process enters a capsicum
sandbox, after which we cannot look up the uid for the "nobody" user.
Reverse the order.
Reported by: kp
Fixes: 0e62ebd201 ("bhyve: Move the slirp backend out into a separate process")
Otherwise etcupdate apparently can fail if its private object directory
under /var/db is in a filesystem mounted noexec. We shouldn't be
building this target at all, but for now, just apply this workaround.
PR: 291043
Reviewed by: ivy, cy, des
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53861
In arch_fix_auxv(), remove local variable shadowing the argument,
remove write-only variable, and declare the loop variable.
The wrong patch was committed after series of local reverts and
re-apply.
Fixes: b2b3d2a962
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
* Always install the manual page as pam_krb5(8) regardless of which
version we're using.
* Regenerate it using pod2mdoc instead of pod2man so it doesn't claim
to be part of “User Contributed Perl Documentation”.
* Put the correct section number in the header and footer.
* Don't cross-reference non-existent pam(7) manual page.
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D53885
Not only does the new pam_krb5 module not have the same allow_kdc_spoof
option that the old one had, its behavior in this matter defaults to
insecure. Reimplement allow_kdc_spoof and switch the default back.
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D53884
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.1, 14
and anything newer.
This reverts commit bd27bd1f51.
Only some people (including the release manager, unfortunately) ran into
build issues with the previous iteration of this commit, because they
were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER
src.conf(5) setting, or because the build system determined that their
base system compiler was out of date.
The bootstrapped compiler would then enable outline atomics and compile
libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs,
it could not find the helper routines in libcompiler_rt.a.
In contrast, people who did not bootstrap the compiler never saw any
issues, because libgcc_s was built using their 'old' base system
compiler, and so libgcc_s would not contain any calls to those helper
routines.
Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a
explicitly, similar to some other binaries and libraries that are built
with -nodefaultlibs.
Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated
compiler with outline atomics enabled. (This should have been done in
the first iteration of this commit, because the error would have shown
up right away then.)
MFC after: 3 days
The register set information is stored as a singleton in
GetRegisterInfo_i386. However, other functions later access this
information assuming it is stored in GetSharedRegisterInfoVector. To
resolve this inconsistency, we remove the original construction logic
and instead initialize the singleton using llvm::call_once within the
appropriate function (GetSharedRegisterInfoVector_i386).
PR: 289945
Obtained from: llvm-project 41859c27842eeda1ef6ff18f3b2fb269388c0857
Currently, LLDB in FreeBSD host sets the Process Architecture used by
lldbserver as Default one. Which cause problem when trying to debug a
32bit binary on amd64 platform since the lldb itself will found mismatch
architecture with lldbserver's return.
Notice that this patch is only a partial fix for the debugging problem.
We are still unable to debug x86 on x86_64 so that we don't provide
testcase in this patch.
PR: 289945
Obtained from: llvm-project 394e7ded8b6bcff1382468b407ca620a2837f41b
It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB
transfer callbacks. I will try to address this at some point, because
this is layering violation, but for now we need to revert the commit, as
it causes a lock recursion panic with USB audio devices.
This reverts commit e254ef87a3.
Contrary to the claim made in a previous commit, removing KDE and
adding all of vim and emacs results in an image which does not fit
into 4.7 GB; to be specific, it lands at 4.722 GB rather than the
claimed 4.689 GB. (This descrepancy resulted from doing test DVD
image builds using an out-of-date tree, and became visible when the
15.0-RC3 images were built.)
Limit the emacs packages shipped on the DVD to the "nox" flavor;
this brings the disk image down to 4.407 GB, aka under the 4.7 GB
limit for standard DVDs.
Fixes: 6cc6beb4c8 ("release: Remove KDE from dvd1.iso")
MFC after: 1 day (for 15.0-RC4)
This key was generated by gordon@ (aka security-officer@) on an offline
system as a backup key should anything happen to the AWS Key
Management Service that is currently in use for signing pkgbase
repositories for FreeBSD 15.x.
Reviewed by: cperciva
With hat: so
It's not clear what the race described in the commit actually is, nor
how it could arise, but this commit is definitely wrong; curthread is no
longer set for intr_pic_init_secondary, and gic_v3's pic_init_secondary
uses mutex(9) in some places, which requires curthread, so it has led to
panics. Revert this change until the original issue this was intended to
be fixed can be more thorougly investigated and a better fix made.
Reported by: Herbert J. Skuhra <herbert@gojira.at>, jhb
This reverts commit a695ac2ce8.
Rockchip have two erratas (#3568001 and #3568002) for the GIC on RK356x.
Until we have a way to handle them revert the changes that uses ITS instead of
GIC for PCIe.
Sort usage and man page options, mention possible minimum and maximum
values, fix punctuation marks, and cleanup the man page.
PR: 291092
Reviewed by: pauamma_gundo.com, christos
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53827
Add guards against attempting to process a user data file with an empty
first line or contents.
PR: 290395
Reviewed by: bapt (earlier), dtxdf, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53239
Now that we can trust NICs to supply an identical hash result
to software, we can setup the inpcb hash on outgoing connections.
This gives us symmetric hashing, meaning packets should enter
and leave on the same NIC queue.
Differential Revision: https://reviews.freebsd.org/D53104
Reviewed by: adrian, cc, kbowling, tuexen, zlei
Sponsored by: Netflix
Kristof Provost