When an ipfw rule references a NAT64 instance by name using
'nat64lsn', the kernel looks up the instance in the shared
srvstate[] array without verifying the instance type.
If the named instance is actually a nat64clat or nat64stl
instance (created with 'nat64clat' or 'nat64stl'), the code
incorrectly casts the instance to nat64lsn_instance and
dereferences the ->cfg pointer, which causes a kernel panic.
The root cause is that all NAT64 instance types share the same
srvstate[] array but have different struct layouts.
For nat64lsn_instance, the field after 'no' is a pointer to nat64lsn_cfg.
For nat64clat_cfg, the same offset contains an embedded nat64_config struct.
Fix by adding a type check after NAT64_LOOKUP() to verify that the
instance's etlv matches IPFW_TLV_NAT64LSN_NAME before proceeding.
If the type doesn't match, return IP_FW_DENY to reject the packet
safely rather than crashing.
Signed-off-by: Teddy Engel <engel.teddy@gmail.com>
PR: 292023
Reported by: pouria
Reviewed by: ae
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2249
These were dropped in 2021 but were never listed in ObsoleteFiles.inc,
so systems that have been upgraded from source since before that date
(or from 13.x) may still have them.
PR: 295668
MFC after: 1 week
Fixes: 0a36787e4c ("locales: separate unicode from other locales")
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D57331
Implement NT_PRFPREG and NT_X86_XSTATE for PTRACE_GETREGSET on amd64.
Chrome's crashpad handler uses these to collect floating-point and
extended CPU register state for crash dumps.
Other architectures retain the previous EINVAL stub behavior.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
PR: 289285
Reviewed by: kib
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2165
Add struct linux_pt_fpregset, the amd64 Linux NT_PRFPREG payload,
corresponding to user_i387_struct in Linux. The struct describes
the 512-byte FXSAVE area as exposed by PTRACE_GETREGSET.
Add bsd_to_linux_fpregset() to translate from FreeBSD's struct fpreg
to struct linux_pt_fpregset. Fields are extracted from the fpr_env[]
array which stores the FXSAVE environment packed as four 64-bit words.
The FP and XMM register banks are bulk-copied as opaque byte arrays.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
Reviewed by: kib
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2165
In package control mode, the performance of all cores depends on the
most recent value written to the request field. If the last write comes
from an E-core, all cores are forced to align with the E-core
performance level, resulting in significant performance degradation.
Therefore, package control is disabled on hybrid-core systems.
Reviewed by: olce
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Sponsored by: Framework Computer Inc
Differential Revision: https://reviews.freebsd.org/D57377
Git 1111a44301 - main - Defer the January 19, 2038 date limit in
UFS1 file systems to February 7, 2106 - did so by changing the UFS1
32-bit signed timestamps to unsigned. With this change, time stamps
from before January 1, 1970 went from being negative numbers to
large positive numbers implying times in the future. When such a
time stamp is encountered when an inode is read into memory or when
it is encountered by fsck, its timestamp is replaced with the
kernel's current time.
Andre Albsmeier reported that he had a machine reboot after a power
failure and the battery that maintained its real-time clock had
died. The result was that the system booted with the time set to
five years earlier (absent a real-time clock value, the boot ROM
used the time that the boot ROM had last been updated). The net
result was that fsck reset the time stamps of all files newer than
five years old to the five year old time.
Andres's original request was for a flag in the file system superblock
to say that there are no timestamps from before 1970 in the file
system, so there shouldn't be anything to fix because of the signed
to unsigned switch. But this assumes that no one every does an rsync
or extracts a tar file or restores a dump that introduces an incorrect
time stamp on their system. So this approach was not taken.
This change compares the system's version of the current time to
the last modification time in the file system superblock. If the
current time is earlier than that time then use the last modification
time in the superblock as the value for the current time. There
should be no files in the file system with times newer than the
last modification time in the superblock.
The superblock time stamp is updated in the in-memory superblock
every time any change is made to anything in the file system. The
superblock is written to the disk every 30 seconds, so it may be
off by up to 30 seconds plus the time it sits in the disk cache
waiting to be written if the system has an unclean shutdown (such
as a power failure). Thus, the worst case scenario with this change
is that files written in the last 30 seconds plus disk cache delay
time before the crash may have their times adjusted back by up to
30 seconds plus the disk cache delay time.
Requested by: Andre Albsmeier
Approved by: kib
Reviewed by: kib, imp, Andre Albsmeier
MFC-after: 1 week
Differential Revision: https://reviews.freebsd.org/D57371
We implement all of the currently-defined Linux inotify mask bits and
flags, with the same values as Linux. Return EINVAL for unknown bits,
as Linux does.
This also moves the translation inline into linux_inotify_add_watch.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57387
We cannot call copyout() while in a net epoch section, unless the user
memory is wired. Use the global ifnet lock to synchronize the accesses
instead.
Reported by: emaste
Reviewed by: zlei
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57154
The sc_count check in lagg_transmit_ethernet() and
lagg_transmit_infiniband() is racy, as the lagg protocol handlers are
only synchronized by net_epoch. Handle a count of 0 in each protocol
handler where it's needed, namely in the RR and LB handlers.
Reported by: Yuxiang Yang, Yizhou Zhao, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM5.1 from Z.ai
Reviewed by: pouria, zlei
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56942
[Serialization] Fix assertion on re-deserialized friend template spec… (#200566)
…ialization in PCH (#198133)
A friend function-template specialization declared inside a class
template is serialized into a PCH. When the class template is later
instantiated while loading the PCH, the friend specialization can be
deserialized re-entrantly (VisitFriendDecl -> VisitFunctionDecl -> ...
-> VisitFunctionDecl for the same specialization) at the same time as
the canonical copy, producing two redeclarations of the same
specialization in the template's specialization set.
ASTDeclReader::VisitFunctionDecl asserted that this collision could only
happen when merging declarations from different modules. Since
38b3d87bd384, friend functions defined inside dependent class templates
are loaded eagerly, so the collision can now also occur within a single
PCH/AST file (non-modules build), tripping the assertion:
Assertion failed: (Reader.getContext().getLangOpts().Modules &&
"already deserialized this template specialization"), function
VisitFunctionDecl
The merge that follows (mergeRedeclarable) already links the two
redeclarations correctly regardless of whether modules are enabled, so
the fix is to drop the modules-only assumption and let the merge run.
Fixes https://github.com/llvm/llvm-project/issues/198133
This fixes (well, simply removes :) an assertion when building the
cad/OrcaSlicer port with precompiled headers turned on.
PR: 295296
MFC after: 3 days
The memory where the pre-OS IDT was located might be already consumed by
kernel.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57321
parse_rules() has been calling toast_rules() in case of a parse error in
order to deallocate the 'struct rule' objects it has constructed up to
that point.
toast_rules() would take a pointer to a full 'struct rules' object, and
besides freeing all 'struct rule' referenced by it, would also free the
holding 'struct rules' itself.
With the introduction of the "executable paths" feature, and the
embedding of 'struct rules' into 'struct conf', meaning that the
lifecycle for 'struct rules' was no longer independent, toast_rules()
was changed not to free the passed 'struct rules' (as it was a field of
a 'struct conf' object). Unfortunately, this change was not completed
with a reinitialization of the rules list head, so the 'struct conf'
object would continue to reference just-freed rules, which then would be
freed a second time on destruction of that container.
So, make toast_rules() re-initialize the rules list in 'struct rules',
which it logically has been having to do since not freeing the enclosing
'struct rules'. This alone is enough to fix the bug, but let's use the
occasion to change the contract of parse_rules() and bring its herald
comment up-to-date: On error, parse_rules() now simply leaves already
constructed 'struct rule' objects in 'conf'. The latter is eventually
destroyed and the rule objects reclaimed at that point.
Add a test trying to set an invalid rules configuration with the first
rule being valid and the second being invalid, which triggers the bug
(and an immediate panic() on an INVARIANTS kernel).
Reported by: impost0r(ret2plt) <impostor@ret2p.lt>
Reviewed by: markj
Fixes: 9818224174 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
Sponsored by: The FreeBSD Foundation
Since the factor is not 1, we need to provide a unit.
MFC after: 1 week
Fixes: 5d92f20c7d ("bin/sh: support RLIMIT_PIPEBUF")
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D57352
This id is for SPI flash instead of spi bus
Fixes: 39e297bf54 ("ig4iic: Add PantherLake IDs")
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Sponsored by: Framework Computer Inc
Long file names are using UTF-16 symbols to represent international or
special characters. The implementation in FreeBSD did not support the
"Supplementary Private Use Area-B" (PUA-B), which requires a surrogate
pair to be represented in UTF-16 (Unicode code points beyond U+FFFF).
The PUA-B is used to represent emoji characters, which are supported
in file names on other common operating systems. The motivation for
this change was that removable media written on another system were
only partially readable on FreeBSD, since they contained emojis in
file names.
A test script that verifies correct operations on files names with
emojis has been added to the tools/test/stress2/misc directory under
the name msdos24.sh.
Reported by: Fabian Keil <fk@fabiankeil.de>
Reviewed by: ib
Approved by: mkcusick
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D57313
The change to relaxed mode has had too many unintended breakages. Revert
back to strict mode until that works for all the cases that are
currently broken.
Fixes: 784150fd25, d69fc3a9dc
PR: 295289
Sponsored by: Netflix
This commit adds the sapphire rapids CPU model to hwpmc_intel.c,
allowing hwpmc to be used on this CPU family.
Reviewed by: mhorne
MFC after: 3 days
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D57263
The driver implements the ntsync interface as specified in the Linux
7.0-rc3 document Documentation/userspace-api/ntsync.rst. Only the
documentation and the userspace tests (Linux'
tools/testing/selftests/drivers/ntsync/ntsync.c) were used for
reference. When the documentation contradicted the tests, tests
behavior was implemented.
One quirk is that Linux API needs to return an error from ioctl() and to
copyout the modified ioctl() argument. Our generic ioctl() is not flexible
enough to implement this, so the ntsync_ioctl_copyout() hack allows to
copyout the ioctl parameter directly from the ioctl method, instead of
relying on the ioctl infra.
The FreeBSD port of the tests, that can be compiled both on FreeBSD and
Linux, is available at https://github.com/kostikbel/freebsd-ntsync-test.
The Linux binary compiled with the Linux test harness, cannot be run
under linuxolator due to unimplemented syscalls, but the shims in
freebsd-ntsync-test can be compiled on Linux and resulting Linux/glibc
binary run on linuxolator to test linux compat.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57038
This fails when using WITH_BEARSSL. It seems like we build the EFI bits
of libsecureboot (which is really just part of libsa in this case), even
when building the BIOS loader. Revert for now to unbreak the build.
This reverts commit 2fa4bdd7f9.
Reported by: freebsd@walstatt-de.de
Move liblua32efi and ficl32efi before .WAIT, otherwise there's a race
between the interpreter and the loader being built.
Reported by: kbowling
Discussed with: kevans
Fixes: d15cc7625d
ukbd_set_leds_callback() built the SET_REPORT control request with
USETW2(req.wValue, UHID_OUTPUT_REPORT, 0) before the loop that
determines the actual HID report ID from sc_id_numlock,
sc_id_scrolllock, or sc_id_capslock. The data payload was already
correctly prefixed with the real report ID when id != 0, but the
control request's wValue told the device to set report ID 0, which
does not exist on devices that use non-zero report IDs for LED output.
Apple Internal Keyboard / Trackpad (0x05ac:0x0274) uses report ID 1
for LED output. The mismatch caused the device to STALL every
SET_REPORT request, so the capslock LED could never be updated.
Move the USETW2 call to after the LED-detection loop so that wValue
carries the correct report ID.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
Reviewed by: wulf
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2210
Our idr implementation is using a mtx lock which in the past has
already caused problems (613723bac2).
In order to make it easier to tackle the problem start by factoring
out all the operations related to the idr->lock into macros as we
have often done in other parts of code as well.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: wulf, emaste
Differential Revision: https://reviews.freebsd.org/D55392
Shortly before I committed the works from a year ago, jhb added a
function ("is_pci_device") so that the check against the devclass
does not have to be coded in every driver. Use this instead in main
(and stable/15 in case the works get MFCed).
At the same time this fixes the check (the old one was wrong) as we
attach to the LinuxKPI 802.11 driver, e.g., iwlwifi and thus we need
to check the parent of the parent and not just the parent to be
of the devclass "pci" in the identify bus function. The was the
first error. The second was (and this is why it worked) that we
checked for == instead of != and so the wrong check became true again.
Discussed with: jhb
Fixes: 11d69a4558 ("LinuxKPI: 802.11: add support for s/r")
MFC after: 3 days
X-MFC after: ffcf5e3566 ("pci: Add is_pci_device helper function")
Sponsored by: The FreeBSD Foundation
Add the device ID to the usbdevs table in order to be able to use
it in the rtwn/usb driver for the RTL8188EU attachment.
(I adjusted the name to B1 compared to the original submission)
PR: 291839
MFC after: 3 days
Implement dummy support for PR_SET_VMA with PR_SET_VMA_ANON_NAME in
prctl(2). This prevents applications from receiving EINVAL when
attempting to name anonymous memory regions.
Include `<stdbool.h>` instead of defining a local bool enum.
This avoids duplicating a standard type name and keeps the
source compatible with headers that provide bool as a macro,
or in case of C23 that compilers provide it as keyword.
Signed-off-by: Faraz Vahedi <kfv@kfv.io>
Reviewed by: fuz
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/2203
`yp_prot.h` has carried a SunRPC-era typedef of `bool` guarded by
`BOOL_DEFINED`, but the header itself does not use it. The YP/RPC
interfaces use `bool_t` for protocol booleans.
Defining `bool` in a public header collides with modern C headers
that provide `bool` as a macro or keyword, such as `<stdbool.h>`
and C23-aware assert handling. Drop the compatibility typedef and
leave `bool` definition to the consumer's language mode.
Signed-off-by: Faraz Vahedi <kfv@kfv.io>
Reviewed by: fuz
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/2203
that are accepted in the activated image or interpreter.
Requested by: jhb
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57328
The UEFI spec says:
> Structures are aligned on boundaries equal to the largest internal
> datum of the structure and internal data are implicitly padded to
> achieve natural alignment.
Unlike the old Intel EFI toolkit, the EDK2 headers expect ia32 builds to
use -malign-double to achive this.
Make EFI versions of libsa32, liblua32, and ficl32. With the difference
being that they are compiled with -malign-double.
Differential Revision: https://reviews.freebsd.org/D55385
Commit f34aca55ad ("netlink/route: provide pre-2.6.19 Linux compat shim",
2024-06) fixed the partial fix for net/bird2 on the netlink path by mapping the
legacy 8-bit struct rtmsg::rtm_table field onto the modern 32-bit RTA_TABLE
attribute when the latter is absent.
That fix, however, was only applied to rtnl_handle_newroute. The two sibling
handlers: rtnl_handle_delroute and rtnl_handle_getroute were left looking at
attrs.rta_table directly. They are reachable from exactly the same client
(bird, in its netlink scan path), so any FIB number that fits in 8 bits
silently maps to RT_TABLE_UNSPEC in those handlers.
Reviewed by: melifaro (previous version)
Approved by: emaste
MFC after: 1 week
Sponsored by: Netflix
Pawel Biernacki