With this merge, we return to our previous long-standing practice of
distributing the IANA Time Zone Database unmodified.
Releases of tzdb since 2021b have merged some time zones where clocks
have agreed since 1970. The overwhelming majority of users will not be
affected by this change. A port of the newly created global-tz fork of
the IANA Time Zone database (misc/global-tz) is available for users who
need more granular pre-1970 time zone history.
Mathy Vanhoef [Sun, 6 Jun 2021 22:10:56 +0000 (22:10 +0000)]
net80211: prevent plaintext injection by A-MSDU RFC1042/EAPOL frames
No longer accept plaintext A-MSDU frames that start with an RFC1042
header with EtherType EAPOL. This is done by only accepting EAPOL
packets that are included in non-aggregated 802.11 frames.
Note that before this patch, FreeBSD also only accepted EAPOL frames
that are sent in a non-aggregated 802.11 frame due to bugs in
processing EAPOL packets inside A-MSDUs. In other words,
compatibility with legitimate devices remains the same.
This relates to section 6.5 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.
ieee80211_defrag() accepts fragmented 802.11 frames in a protected Wi-Fi
network even when some of the fragments are not encrypted.
Track whether the fragments are encrypted or not and only accept
successive ones if they match the state of the first fragment.
This relates to section 6.3 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.
Bjoern A. Zeeb [Wed, 6 Oct 2021 18:41:37 +0000 (18:41 +0000)]
net80211: proper ssid length check in setmlme_assoc_adhoc()
A user supplied SSID length is used without proper checks in
setmlme_assoc_adhoc() which can lead to copies beyond the end
of the user supplied buffer.
The ssid is a fixed size array for the ioctl and the argument
to setmlme_assoc_adhoc().
In addition to an ssid_len check of 0 also error in case the
ssid_len is larger than the size of the ssid array to prevent
problems.
Bjoern A. Zeeb [Wed, 6 Oct 2021 18:09:39 +0000 (18:09 +0000)]
net80211: correct length check in ieee80211_ies_expand()
In ieee80211_ies_expand() we are looping over Elements
(also known as Information Elements or IEs).
The comment suggests that we assume well-formedness of
the IEs themselves.
Checking the buffer length being least 2 (1 byte Element ID and
1 byte Length fields) rather than just 1 before accessing ie[1]
is still good practise and can prevent and out-of-bounds read in
case the input is not behaving according to the comment.
Mathy Vanhoef [Sun, 6 Jun 2021 22:10:52 +0000 (22:10 +0000)]
net80211: mitigation against A-MSDU design flaw
Mitigate A-MSDU injection attacks by detecting if the destination address
of a subframe equals an RFC1042 (i.e., LLC/SNAP) header, and if so
dropping the complete A-MSDU frame. This mitigates known attacks,
although new (unknown) aggregation-based attacks may remain possible.
This defense works because in A-MSDU aggregation injection attacks, a
normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
header. In other words, the destination MAC address of the first A-MSDU
subframe contains the start of an RFC1042 header during an aggregation
attack. We can detect this and thereby prevent this specific attack.
This relates to section 7.2 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.
Andriy Gapon [Tue, 25 Jan 2022 10:34:08 +0000 (12:34 +0200)]
smp_targeted_tlb_shootdown has to pin the CPU on i386
This should fix a regression in 1820ca215461 which happened
because pmap -> shootdown contracts on amd64 and i386 diverged.
On amd64 the pmap code always pins the CPU before calling the shootdown
code and expects it to unpin on return.
On i386 the pmap code either has pins and unpins around the shootdown
calls or does not pin at all.
This change should account for that difference.
In main and stable/13 the contracts are also different, but the
shootdown code is split into the i386 and amd64 variants and each
variant is tailored towards the platform's pmap.
PR: 261338
Reported by: Dmitry K. <thedix@yandex.ru>
Debugged by: Dmitry K. <thedix@yandex.ru>
Tested by: Dmitry K. <thedix@yandex.ru>
Fixes: 1820ca215461 MFC r368649 / 3fd989da by kib: amd64 pmap: fix PCID mode invalidations
Reviewed by: kib
X-Pointyhat to: avg
Differential Revision: https://reviews.freebsd.org/D33980
r368649 fixed a regression in r362031 that was MFC-ed to stable/12 as
a part of r362572. That commit reordered IPI send and local TLB flush in
TLB invalidations.
Without this fix we've been seeing problems with stale memory content
where changes done under a mutex were not immediately observed by
another thread after taking the same mutex. Those inconsistenices were
correlated to copy-on-write faults for pages contaning the data.
The change needed some adaptations as I elected to skip two significant
intermediate changes:
- r363195 / dc43978a, amd64: allow parallel shootdown IPIs
- r363311 / 3ec7e169, amd64 pmap: microoptimize local shootdowns for
PCID PTI configurations
Wei Hu [Sat, 27 Nov 2021 06:42:34 +0000 (06:42 +0000)]
Hyper-V: vPCI: Prepopulate device bars
In recent Hyper-V releases on Windows Server 2022, vPCI code does not
initialize the last 4 bit of device bar registers. This behavior change
could result weird problems cuasing PCI code failure when configuring
bars.
Just write all 1's to those bars whose probed values are not the same
as current read ones. This seems to make Hyper-V vPCI and
pci_write_bar() to cooperate correctly on these releases.
Casper services expect that the first 3 descriptors (stdin/stdout/stderr)
will point to /dev/null. Which Casper will ensure later. The Casper
services are forked from the original process. If the initial process
closes one of those descriptors, Casper may reuse one of them for it on
purpose. If this is the case, then renumarate the descriptors used by
Casper to higher numbers. This is done already after the fork, so it
doesn't break the parent process.
Mark Johnston [Fri, 28 May 2021 14:41:43 +0000 (10:41 -0400)]
libradius: Fix attribute length validation in rad_get_attr(3)
The length of the attribute header needs to be excluded when comparing
the attribute length against the length of the packet. Otherwise,
validation may incorrectly fail when fetching the final attribute in a
message.
Approved by: so
Security: FreeBSD-EN-21:17.libradius
Fixes: 8d5c78130 ("libradius: Fix input validation bugs")
Reported by: Peter Eriksson
Tested by: Peter Eriksson
Sponsored by: The FreeBSD Foundation
If copyin family of routines fault, kernel does clear PSL.AC on the
fault entry, but the AC flag of the faulted frame is kept intact. Since
onfault handler is effectively jump, AC survives until syscall exit.
Approved by: so
Security: FreeBSD-SA-21:11.smap
Security: CVE-2021-29628
Reported by: m00nbsd, via Sony
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
admbugs: 975
Mark Johnston [Tue, 27 Apr 2021 00:04:25 +0000 (20:04 -0400)]
aesni: Avoid modifying session keys in hmac_update()
Otherwise aesni_process() is not thread-safe for AES+SHA-HMAC
transforms, since hmac_update() updates the caller-supplied key directly
to create the derived key. Use a buffer on the stack to store a copy of
the key used for computing inner and outer digests.
This is a direct commit to stable/12 as the bug is not present in later
branches.
Approved by: so
Security: EN-21:11.aesni
Reviewed by: kib
Instantiate Error in Target::GetEntryPointAddress() only when
necessary
When Target::GetEntryPointAddress() calls
exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned
entry_addr is valid, it can immediately be returned.
However, just before that, an llvm::Error value has been setup, but
in this case it is not consumed before returning, like is done
further below in the function.
In https://bugs.freebsd.org/248745 we got a bug report for this,
where a very simple test case aborts and dumps core:
* thread #1, name = 'testcase', stop reason = breakpoint 1.1
frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
1 int main(int argc, char *argv[])
2 {
-> 3 return 0;
4 }
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Thread 1 received signal SIGABRT, Aborted.
thr_kill () at thr_kill.S:3
3 thr_kill.S: No such file or directory.
(gdb) bt
#0 thr_kill () at thr_kill.S:3
#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890
Fix the incorrect error catch by only instantiating an Error object
if it is necessary.
Kristof Provost [Tue, 15 Dec 2020 08:29:45 +0000 (08:29 +0000)]
MFC r368588:
pf: Allow net.pf.request_maxcount to be set from loader.conf
Mark request_maxcount as RWTUN so we can set it both at runtime and from
loader.conf. This avoids users getting caught out by the change from tunable to
run time configuration.
Suggested by: Franco Fichtner
Approved by: so
Security: FreeBSD-EN-21:06.pf
Mark Johnston [Thu, 25 Mar 2021 21:55:20 +0000 (17:55 -0400)]
accept_filter: Fix filter parameter handling
For filters which implement accf_create, the setsockopt(2) handler
caches the filter name in the socket, but it also incorrectly frees the
buffer containing the copy, leaving a dangling pointer. Note that no
accept filters provided in the base system are susceptible to this, as
they don't implement accf_create.
Reported by: Alexey Kulaev <alex.qart@gmail.com>
Discussed with: emaste
Sponsored by: The FreeBSD Foundation
Approved by: so
Security: CVE-2021-29627
Security: FreeBSD-SA-21:09.accept_filter
Roger Pau Monné [Wed, 20 Jan 2021 18:40:51 +0000 (19:40 +0100)]
xen-blkback: fix leak of grant maps on ring setup failure
Multi page rings are mapped using a single hypercall that gets passed
an array of grants to map. One of the grants in the array failing to
map would lead to the failure of the whole ring setup operation, but
there was no cleanup of the rest of the grant maps in the array that
could have likely been created as a result of the hypercall.
Add proper cleanup on the failure path during ring setup to unmap any
grants that could have been created.
This is part of XSA-361.
Approved by: so
Security: CVE-2021-26932
Security: FreeBSD-SA-21:06.xen
Security: XSA-361
Sponsored by: Citrix Systems R&D
The existing logic is nice in theory, but in practice freebsd-update will
not preserve the timestamps on these files. When doing a major upgrade, e.g.
from 12.1-RELEASE -> 12.2-RELEASE, pwd.mkdb et al. appear in the INDEX and
we clobber the timestamp several times in the process of packaging up the
existing system into /var/db/freebsd-update/files and extracting for
comparisons. This leads to these files not getting regenerated when they're
most likely to be needed.
Measures could be taken to preserve timestamps, but it's unclear whether
the complexity and overhead of doing so is really outweighed by the marginal
benefit.
I observed this issue when pkg subsequently failed to install a package that
wanted to add a user, claiming that the user was removed in the process.
bapt@ pointed to this pre-existing bug with freebsd-update as the cause.
PR: 234014, 232921
Approved by: so
Security: FreeBSD-EN-21:08.freebsd-update
Jamie Gritton [Fri, 19 Feb 2021 22:13:35 +0000 (14:13 -0800)]
MFC jail: Change both root and working directories in jail_attach(2)
jail_attach(2) performs an internal chroot operation, leaving it up to
the calling process to assure the working directory is inside the jail.
Add a matching internal chdir operation to the jail's root. Also
ignore kern.chroot_allow_open_directories, and always disallow the
operation if there are any directory descriptors open.
Jamie Gritton [Tue, 16 Feb 2021 19:19:13 +0000 (11:19 -0800)]
MFC jail: Handle a possible race between jail_remove(2) and fork(2)
jail_remove(2) includes a loop that sends SIGKILL to all processes
in a jail, but skips processes in PRS_NEW state. Thus it is possible
the a process in mid-fork(2) during jail removal can survive the jail
being removed.
Add a prison flag PR_REMOVE, which is checked before the new process
returns. If the jail is being removed, the process will then exit.
Also check this flag in jail_attach(2) which has a similar issue.
Roger Pau Monné [Wed, 25 Nov 2020 11:34:38 +0000 (12:34 +0100)]
xen: allow limiting the amount of duplicated pending xenstore watches
Xenstore watches received are queued in a list and processed in a
deferred thread. Such queuing was done without any checking, so a
guest could potentially trigger a resource starvation against the
FreeBSD kernel if such kernel is watching any user-controlled xenstore
path.
Allowing limiting the amount of pending events a watch can accumulate
to prevent a remote guest from triggering this resource starvation
issue.
For the PV device backends and frontends this limitation is only
applied to the other end /state node, which is limited to 1 pending
event, the rest of the watched paths can still have unlimited pending
watches because they are either local or controlled by a privileged
domain.
The xenstore user-space device gets special treatment as it's not
possible for the kernel to know whether the paths being watched by
user-space processes are controlled by a guest domain. For this reason
watches set by the xenstore user-space device are limited to 1000
pending events. Note this can be modified using the
max_pending_watch_events sysctl of the device.
This is XSA-349.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Mark Johnston [Sun, 3 Jan 2021 16:32:30 +0000 (11:32 -0500)]
Ensure that dirent's d_off field is initialized
We have the d_off field in struct dirent for providing the seek offset
of the next directory entry. Several filesystems were not initializing
the field, which ends up being copied out to userland.
Alan Somers [Tue, 1 Dec 2020 15:15:18 +0000 (15:15 +0000)]
Fix error merging r354116 from OpenZFS
When we merged 4c0883fb4af0d5565459099b98fcf90ecbfa1ca1 from OpenZFS (svn
r354116), there were some merge conflicts. One of those was resolved
incorrectly, causing "zfs receive" to fail to delete snapshots that a "zfs
send -R" stream has deleted.
This change corrects that merge conflict, and also reduces some harmless
diffs vis-a-vis OpenZFS that were also introduced by the same revision.
Direct commit to stable/12 because head has moved on to OpenZFS.
MFC r368237: if: Fix panic when destroying vnet and epair simultaneously
When destroying a vnet and an epair (with one end in the vnet) we often
panicked. This was the result of the destruction of the epair, which destroys
both ends simultaneously, happening while vnet_if_return() was moving the
struct ifnet to its home vnet. This can result in a freed ifnet being re-added
to the home vnet V_ifnet list. That in turn panics the next time the ifnet is
used.
Prevent this race by ensuring that vnet_if_return() cannot run at the same time
as if_detach() or epair_clone_destroy().
Glen Barber [Fri, 23 Oct 2020 00:00:52 +0000 (00:00 +0000)]
- Switch releng/12.2 from RC3 to RELEASE.
- Add the anticipated 12.2-RELEASE date to UPDATING. Fix
a missing colon in the previous UPDATING entry while here.
- Set a static __FreeBSD_version.
Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC (netgate.com)
Allan Jude [Thu, 15 Oct 2020 15:07:25 +0000 (15:07 +0000)]
ZFS: whitelist zstd and encryption in the loader
MFC r364787:
MFS r366593:
Please note that neither zstd nor encryption is
supported by the loader at this instant. This
change makes it safe to use those features in
one's root pool, but not in one's root dataset.
Warner Losh [Wed, 14 Oct 2020 01:47:00 +0000 (01:47 +0000)]
MFS12: r366422 r366588
r366588: fixes video display heuristic that prevented byhve and vmware
from detecting dual consoles.
r366422: Report the kernel console on the boot screen
Report what console the boot loader is telling the kernel to use and allow
toggling between them.
Michael Tuexen [Thu, 1 Oct 2020 18:17:56 +0000 (18:17 +0000)]
MFS r366324:
Improve the handling of receiving unordered and unreliable user
messages using DATA chunks. Don't use fsn_included when not being
sure that it is set to an appropriate value. If the default is
used, which is -1, this can result in SCTP associaitons not
making any user visible progress.
Thanks to Yutaka Takeda for reporting this issue for the the
userland stack in https://github.com/pion/sctp/issues/138.
MFS r366329:
Improve the input validation and processing of cookies.
This avoids setting the association in an inconsistent
state, which could result in a use-after-free situation.
This can be triggered by a malicious peer, if the peer
can modify the cookie without the local endpoint recognizing
it.
Thanks to Ned Williamson for reporting the issue.
John Baldwin [Thu, 1 Oct 2020 17:30:38 +0000 (17:30 +0000)]
MFS 366297: Revert most of r360179.
I had failed to notice that sgsendccb() was using cam_periph_mapmem()
and thus was not passing down user pointers directly to drivers. In
practice this broke requests submitted from userland.
Rick Macklem [Tue, 29 Sep 2020 15:09:38 +0000 (15:09 +0000)]
MFS: r366238
Bjorn reported a problem where the Linux NFSv4.1 client is
using an open_to_lock_owner4 when that lock_owner4 has already
been created by a previous open_to_lock_owner4. This caused the NFS server
to reply NFSERR_INVAL.
For NFSv4.0, this is an error, although the updated NFSv4.0 RFC7530 notes
that the correct error reply is NFSERR_BADSEQID (RFC3530 did not specify
what error to return).
For NFSv4.1, it is not obvious whether or not this is allowed by RFC5661,
but the NFSv4.1 server can handle this case without error.
This patch changes the NFSv4.1 (and NFSv4.2) server to handle multiple
uses of the same lock_owner in open_to_lock_owner so that it now correctly
interoperates with the Linux NFS client.
It also changes the error returned for NFSv4.0 to be NFSERR_BADSEQID.
Thanks go to Bjorn for diagnosing this and testing the patch.
He also provided a program that I could use to reproduce the problem.
Stefan Eßer [Mon, 28 Sep 2020 14:47:36 +0000 (14:47 +0000)]
MF12 r366218:
Add documentation of the build options WITH_GH_BC and WITHOUT_GH_BC to
optionally replace the traditional implementation of bc(1) and dc(1) with
the new implementation that has become the default version in -CURRENT.
The man-page differs from the one in -CURRENT due to different default
values of that build option.
Alan Somers [Mon, 28 Sep 2020 00:23:59 +0000 (00:23 +0000)]
MF stable/12 r366190:
fusefs: fix mmap'd writes in direct_io mode
If a FUSE server returns FOPEN_DIRECT_IO in response to FUSE_OPEN, that
instructs the kernel to bypass the page cache for that file. This feature
is also known by libfuse's name: "direct_io".
However, when accessing a file via mmap, there is no possible way to bypass
the cache completely. This change fixes a deadlock that would happen when
an mmap'd write tried to invalidate a portion of the cache, wrongly assuming
that a write couldn't possibly come from cache if direct_io were set.
Arguably, we could instead disable mmap for files with FOPEN_DIRECT_IO set.
But allowing it is less likely to cause user complaints, and is more in
keeping with the spirit of open(2), where O_DIRECT instructs the kernel to
"reduce", not "eliminate" cache effects.
PR: 247276
Approved by: re (gjb)
Reported by: trapexit@spawn.link
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D26485
projects / FreeBSD / FreeBSD.git / log