This reverts commit 781221f084.
Revert "pf tests: ensure that neighbour discovery works as expected"
This reverts commit 631d6e5300.
Revert "pf: fully annotated patch of disabling state tracking and issues for ND"
This reverts commit f858272896.
Revert "pf: invert direction for inner icmp state lookups"
This reverts commit c61a3c23fb.
Revert "pf tests: ensure that traceroutes using ICMP work"
This reverts commit 9c53965169.
Revert "pf: fix icmp-in-icmp state lookup"
This reverts commit e854cb4789.
Revert "pf: allow MLD LR to be sent without state"
This reverts commit 9b2e3cf60b.
Revert "pf: split ICMP/ICMPv6 number space in pf_icmp_mapping()"
This reverts commit ee1b7126a9.
Revert "pf: some ICMP types that also have icmp_id, pointed out by markus@"
This reverts commit c21004ce41.
Revert "pf: stricter state checking for ICMP and ICMPv6 packets"
This reverts commit 7f1f57ed78.
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
This isn't inherently an error. It is if you're attempting to download
dist tarballs or later install packages, but a FreeBSD system with no
NIC is a reasonable setup to have, especially in a throwaway VM setting,
so we shouldn't say it is one.
Leaving the exit code as 1 is still fine, since auto will ignore it, and
avoids breaking other uses.
MFC after: 1 week
(cherry picked from commit 7414d14bd51d8378057bbe952c2715b9f32d1d3e)
The script uses [ -z "$INTERFACES" ] to check if the list of interfaces
is empty and will exit early if so, but INTERFACES always contains at
least a space due to the way it appends the list of wireless devices.
Fix this by only adding the space when there are devices to append,
mirroring the behaviour for non-wireless devices above (both will result
in a redundant leading space when the list is non-empty, but that one is
harmless).
Fixes: 159ca5c844 ("Adapt to new wireless scheme where base wlan interfaces do not show up in ifconfig anymore.")
MFC after: 1 week
(cherry picked from commit b809c7d6a26924ac351e49a15011da718cc3feec)
Sloppy state tracking renders ICMP direction check useless
and harmful as we might see only half of the connection in
the asymmetric setups but ignore the state match. The bug
was reported and fix was verified by Insan Praja <insan ()
ims-solusi ! com>. Thanks! OK mcbride, henning
MFC after: 1 week
Obtained from: OpenBSD, mikeb <mikeb@openbsd.org>, 538596657140
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 3da3eb6081a2e2f6ea2fed1728d5dd7f9e8786e5)
Ensure that we rebuild the test binary when we add tests (i.e. modify
pfctl_test_list.inc).
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 250e074e5f609194e0e4cd0775d99b0a616bfcf3)
As of e67975d331 ("Fix 'calendar -a' in several ways."), `calendar -a`
will now fork off a new process for each user and do all of its own
processing in the user's own context.
As a side-effect, calendar(1) started calling setlogin(2) in each of the
forked processes and inadvertently hijacked the login name for the
session it was running under, which was typically not a fresh session
but rather that of whatever cron/periodic run spawned it. Thus, daily
and security e-mails started coming from completely arbitrary user.
We could create a new session, but it appears that nothing calendar(1)
does really needs the login name to be clobbered; opt to just avoid the
setlogin(2) call entirely rather than incur the overhead of a new
session for each process.
PR: 280418
Reviewed by: des, olce
Fixes: e67975d331 ("Fix 'calendar -a' in several ways.")
(cherry picked from commit 6cb8b61efe8899ee9194563108d0ae90c1eb89e3)
(cherry picked from commit 33708452aa)
Approved by: so
'ushm_refcnt' is unsigned. Don't leave the impression it isn't.
No functional change (intended).
Reviewed by: kib
Approved by: emaste (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
(cherry picked from commit c75a18905e308f69b01f19c3d7d613883a008e79)
(cherry picked from commit 4938f55446)
Approved by: so
This hardens against provoked use-after-free occurences should there be
reference counting leaks in the future (which is currently not the
case).
At the deepest level, umtx_shm_find_reg_unlocked() now returns EOVERFLOW
when it cannot grant an additional reference to the registry object, and
so will umtx_shm_find_reg(). umtx_shm_create_reg() will fail if calling
umtx_shm_find_reg() returns EOVERFLOW (meaning a SHM object for the
passed key already exists, but we can't acquire another reference on
it), avoiding the creation of a duplicate registry entry for a given key
(this wouldn't pose problem for the rest of the code in its current
form, but is expressly avoided for intelligibility and hardening
purposes).
Since umtx_shm_find_reg*(), and consequently the whole _umtx_op() system
call, can only return EOVERFLOW on such a bug manifesting, we don't
document that return value.
Reviewed by: kib, emaste
Approved by: emaste (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
(cherry picked from commit c3e6dfe55c0e81d0717b0458bc95128384c3ebe8)
(cherry picked from commit b20ae16087)
Approved by: so
umtx_shm_unref_reg_locked() would unconditionally drop the "registry"
reference, tied to USHMF_LINKED.
This is not a problem for caller umtx_shm_object_terminated(), which
operates under the 'umtx_shm_lock' lock end-to-end, but it is for
indirect caller umtx_shm(), which drops the lock between
umtx_shm_find_reg() and the call to umtx_shm_unref_reg(true) that
deregisters the umtx shared region (from 'umtx_shm_registry';
umtx_shm_find_reg() only finds registered shared mutexes).
Thus, two concurrent user-space callers of _umtx_op() with UMTX_OP_SHM
and flags UMTX_SHM_DESTROY, both progressing past umtx_shm_find_reg()
but before umtx_shm_unref_reg(true), would then decrease twice the
reference count for the single reference standing for the shared mutex's
registration.
Reported by: Synacktiv
Reviewed by: kib
Approved by: emaste (mentor)
Security: FreeBSD-SA-24:14.umtx
Security: CVE-2024-43102
Security: CAP-01
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
(cherry picked from commit 62f40433ab47ad4a9694a22a0313d57661502ca1)
(cherry picked from commit be7dc46139)
Approved by: so
...into the only USHMF_LINKED, as they are always set or unset together.
This is both to stop giving the impression that they can be set/unset
independently, which they can't with the current code, and to make it
clearer that an upcoming reference counting fix is correct.
Reviewed by: kib
Approved by: emaste (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
(cherry picked from commit dd83da532c36830a0c0aac624903849262ec6f68)
(cherry picked from commit 2d4511bb81)
Approved by: so
The incorrectly typed data is read only, used in a compare operation, so
neither remote code execution, nor memory content disclosure were possible.
However, applications performing certificate name checks were vulnerable to
denial of service.
The GENERAL_TYPE data type is a union, and we must take care to access the
correct member, based on `gen->type`, not all the member fields have the same
structure, and a segfault is possible if the wrong member field is read.
The code in question was lightly refactored with the intent to make it more
obviously correct.
Security: CVE-2024-6119
Obtained from: OpenSSL Project
(cherry picked from commit 1486960d6cdb052e4fc0109a56a0597b4e902ba1)
(cherry picked from commit 5946b0c6cb)
Approved by: so
The function pci_xhci_find_stream validates that the streamid is valid
but the bound check accepts up to ep_MaxPStreams included.
The bug results in an out-of-bounds write on the heap with controlled
data.
Reported by: Synacktiv
Reviewed by: jhb
Security: FreeBSD-SA-24:12.bhyve
Security: CVE-2024-32668
Security: HYP-04
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45994
(cherry picked from commit 5c9308a4130858598c76f3ae6e3e3dfb41ccfe68)
(cherry picked from commit 90af1336ed)
Approved by: so
Previously 3 bytes of data from the heap could be leaked to ctl
consumers.
Reported by: Synacktiv
Reviewed by: asomers, mav
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46091
(cherry picked from commit db87c98168b1605f067d283fa36a710369c3849d)
(cherry picked from commit 131b7dcb2f)
Approved by: so
This vulnerability is directly accessible to a guest VM through the
pci_virtio_scsi bhyve device.
In the function ctl_report_supported_opcodes() accessible from the VM,
the option RSO_OPTIONS_OC_ASA does not check the requested
service_action value before accessing &ctl_cmd_table[].
Reported by: Synacktiv
Reviewed by: asomers
Security: FreeBSD-SA-24:11.ctl
Security: CVE-2024-42416
Security: HYP-06
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46027
(cherry picked from commit af438acbfde3d25dbdc82b2b3d72380f0191e9d9)
(cherry picked from commit 803e0c2ab2)
Approved by: so
The functions ctl_write_buffer() and ctl_read_buffer() are vulnerable to
a kernel memory disclosure caused by an uninitialized kernel allocation.
If one of these functions is called for the first time for a given LUN, a
kernel allocation is performed without the M_ZERO flag. Then a call to
ctl_read_buffer() returns the content of this allocation, which may
contain kernel data.
Reported by: Synacktiv
Reviewed by: asomers
Reviewed by: jhb
Security: FreeBSD-SA-24:11.ctl
Security: CVE-2024-8178
Security: HYP-05
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45952
(cherry picked from commit ea44766b78d639d3a89afd5302ec6feffaade813)
(cherry picked from commit cdfdb3b008)
Approved by: so
The virtio_scsi device allows a guest VM to directly send SCSI commands
to the kernel driver exposed on /dev/cam/ctl. This setup makes the
vulnerability directly accessible from VMs through the pci_virtio_scsi
bhyve device.
The function ctl_write_buffer sets the CTL_FLAG_ALLOCATED flag, causing
the kern_data_ptr to be freed when the command finishes processing.
However, the buffer is still stored in lun->write_buffer, leading to a
Use-After-Free vulnerability.
Since the buffer needs to persist indefinitely, so it can be accessed by
READ BUFFER, do not set CTL_FLAG_ALLOCATED.
Reported by: Synacktiv
Reviewed by: Pierre Pronchery <pierre@freebsdfoundation.org>
Reviewed by: jhb
Security: FreeBSD-SA-24:11.ctl
Security: CVE-2024-45063
Security: HYP-03
Sponsored by: Axcient
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46424
(cherry picked from commit 670b582db6cb827a8760df942ed8af0020a0b4d0)
(cherry picked from commit 29937d7a1a)
Approved by: so
The function tpm_ppi_mem_handler is vulnerable to buffer over-read and
over-write, the MMIO handler serves the heap allocated structure
tpm_ppi_qemu.
The issue is that the structure size is smaller than 0x1000 and the
handler does not validate the offset and size (sizeof is 0x15A while the
handler allows up to 0x1000 bytes)
Reported by: Synacktiv
Reviewed by: corvink
Security: FreeBSD-SA-24:10.bhyve
Security: CVE-2024-41928
Security: HYP-01
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45980
(cherry picked from commit a06fc21e770a482c8915411ebc98c870e42dd29b)
(cherry picked from commit 6ce4821f08)
Approved by: so
During unpacking, we ensure that we do not read beyond the
declared size. However, unpack uses a function that copies
null-terminated strings. Prior to this commit, if the last string
was not null-terminated, it could result in copying data into a
buffer smaller than the allocated size.
Security: FreeBSD-24:09.libnv
Security: CVE-2024-45288
Security: CAP-03
Reported by: Synacktiv
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46138
(cherry picked from commit 3aaaca1b51ad844ef9e9b3d945217ab3dd189bae)
(cherry picked from commit 9c2ef10216)
Approved by: so
Ensure that the calculation of size of array doesn't
overflow.
Security: FreeBSD-24:09.libnv
Security: CVE-2024-45287
Security: CAP-02
Reported by: Synacktiv
Reported by: Taylor R Campbell (NetBSD)
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46131
(cherry picked from commit 36fa90dbde0060aacb5677d0b113ee168e839071)
(cherry picked from commit 371af89975)
Approved by: so
Some SCTP implementations will abort connections and then later re-use the same
port numbers (i.e. both src and dst) for a new connection, before pf has fully
purged the old connection.
Apply the same hack we already have for similarly misbehaving TCP
implementations and forcibly remove the old state so we can create a new one.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 82e021443a76b1f210cfb929a495185179606868)
We're going to start running many of the vnet tests in nested jails (so they
can run in parallel). That means the tests won't be able to load kernel modules,
which we commonly do for if_epair and if_bridge.
Just assume that all vnet tests need this, because so many of them do that we
don't want to manually annotate all of them.
This is essentially a no-op on non-nested tests.
Do the same for the python test framework.
While here also have pflog_init actually call pft_init. While having pflog
loaded implies we have pf too pft_init also checks for vimage support, and now
for if_epair.
Reviewed by: markj
MFC after: 1 month
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D46039
(cherry picked from commit ae8d58814089308028046ac80aeeb9cbb784bd0a)
Many of the tests create temporary files. pid files, log files, tcpdump
captures, ... We should take care to ensure they're stored in the temporary
working directory Kyua creates rather than in the root directory.
This ensures there are no conflicts between simultaneously running tests, and
also keeps the root directory clean.
MFC after: 1 month
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit b0fcf4d5222bfdbbc0e2af2b14f0d73704706aa0)
Unfortunately this will likely resurface CVE-2024-6640 which was what all the
effort was about here in the first place. In this situation, however, the
general stability of ND behaviour is more important than fixing this.
(e.g. traceroute with icmp)
ok henning, jsing
Also extend the test case to cover this scenario.
PR: 280701
Obtained from: OpenBSD
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
In 534ee17e6 pf state checking for ICMP(v6) was made stricter. This change
failed to correctly set the pf_pdesc for ICMP-in-ICMP lookups, resulting in ICMP
error packets potentially being dropped incorrectly.
Specially, it copied the ICMP header into a separate variable, not into the
pf_pdesc.
Populate the required pf_pdesc fields for the embedded ICMP packet's state lookup.
PR: 280701
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Change PF behavior to allow MLD Listener Report packets to be sent
without needing a previously created state by MLD Listener Query. It
wasn't working because: (1) you might not have a previous MLD Listener
Query and (2) the addresses of the Query and Report don't match.
ok mikeb@, sashan@
Approved by: so
Security: FreeBSD-SA-24:05.pf
Security: CVE-2024-6640
MFC after: 1 day
Obtained From: OpenBSD, rzalamena <rzalamena@openbsd.org>, 5c526dbdb0f2
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 1afe4da75d1d2acd33b25eea942af28aa41c82c2)
(cherry picked from commit 3382c691dc)
In pf_icmp_mapping() the ICMP and ICMPv6 types shared the same
number space. In fact they are independent and must be handled
separately. Fix traceroute via pf by splitting pf_icmp_mapping()
into IPv4 and IPv6 sections.
ok henning@ mcbride@; tested mcbride@; sure deraadt@
Approved by: so
Security: FreeBSD-SA-24:05.pf
Security: CVE-2024-6640
MFC after: 1 day
Obtained From: OpenBSD, bluhm <bluhm@openbsd.org> ef4bccd7509e
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 46755f52247bd34a7f013d6844ed0c673ac0defc)
(cherry picked from commit 7f77305a5b)
Include
the ICMP type in one port of the state key, using the type to determine which
side should be the id, and which should be the type.
Also:
- Handle ICMP6 messages which are typically sent to multicast addresses but
recieve unicast replies, by doing fallthrough lookups against the correct
multicast address.
- Clear up some mistaken assumptions in the PF code:
- Not all ICMP packets have an icmp_id, so simulate one based on other
data if we can, otherwise set it to 0.
- Don't modify the icmp id field in NAT unless it's echo
- Use the full range of possible id's when NATing icmp6 echoy
ok henning marco
testing matthieu todd
Approved by: so
Security: FreeBSD-SA-24:05.pf
Security: CVE-2024-6640
MFC after: 1 day
Obtained From: OpenBSD, mcbride <mcbride@openbsd.org> 70bf7555ef4c
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 534ee17e61ee094ec175703bc50e88ff6587703e)
(cherry picked from commit 2f6b4611b5)
The cloner has the ability to limit the maximum unit. Employ it to do
that rather than roll our own.
No functional change intended.
Reviewed by: kp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45767
(cherry picked from commit 07d138afc7e5efee73368459dd047493713056cf)
Some drivers, e.g. if_enc(4), only allow one instance to be created, but
the KPI ifc_attach_cloner() treat zero value of maxunit as not limited,
aka IF_MAXUNIT.
Introduce a new flag IFC_F_LIMITUNIT to indicate that the requested
maxunit is limited and should be respected.
Consumers should use the new flag if there is an intended limit.
Reviewed by: glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45757
(cherry picked from commit a2cac544a668d2834ed41986aca32b44b9819c89)
In main [1] this warning message is suppressed but no plans to MFC the
change as the message may be still useful for users that upgrade from
older releases to 14.x or 13.x. Well emitting this warning message every
time increasing the fib number is confusing for users not for the feature
`net.add_addr_allfibs`, let's limit it to be printed only once.
1. a48f7a2eb90b fibs: Suppress the WARNING message for setups with multiple fibs
This is a direct commit to stable/14 and stable/13.
PR: 280097
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46204
These variables are tunables, so in principle they never change at runtime.
That would mean they don't need to be tracked per-vnet.
However, they both can be decreased (back to their default values) if the
memory allocations for their respective tables fail, and these allocations are
per-vnet. That is, it's possible for a few vnets to be started and have the
tuned size for the hash and srchash tables only to have later vnets fail the
initial allocation and fall back to smaller allocations. That would confuse
the previously created vnets (because their actual table size and size/mask
variables would no longer match).
Avoid this by turning these into per-vnet variables.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 271f146955641857c93705b5b1916b8004e5623c)
To make parsing of, for example, Spamhaus' drop.txt and similar
files that contains semicolons as comments, allow them also
in file-based tables.
Reviewed by: kp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D46088
(cherry picked from commit a8a95277363be2c92b3c06bd9cd1a32d1c6c6ecd)
When creating a state for ICMP (v4 or v6) packets we only used the ID, which
means that we could confuse different ICMP types. For example, if we allowed
neighbour discovery but not ICMPv6 echo requests an ND packet could create a
state that the echo request would match.
Test that this is now fixed.
Reported by: Enrico Bassetti <e.bassetti@tudelft.nl>
MFC after: 1 day
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit b9f0dbc3d006e0b904ee4275d54459f4edd65bb8)
