ahcisata_pci: Add sanity check for BAR5 to prevent panic
Inte volume management can't be attach to ahcisata_pci.
It doesn't conform the AHCI specification. The AHCI specification says it's
32bit BAR. According to the PCI specification, if a BAR is the lower 32-bit
register of a 64-bit register, the next register represents the upper 32
bits. However, BARs only go up to 5, and there is no BAR 6.
Pull up following revision(s) (requested by msaitoh in ticket #2032):
sys/dev/usb/xhci.c: revision 1.193
xhci: Add missing UHF_PORT_POWER support to xhci_roothub_ctrl_locked()
Pull up following revision(s) (requested by msaitoh in ticket #1305):
sys/dev/usb/xhci.c: revision 1.193
xhci: Add missing UHF_PORT_POWER support to xhci_roothub_ctrl_locked()
Pull up following revision(s) (requested by msaitoh in ticket #367):
sys/dev/usb/xhci.c: revision 1.193
xhci: Add missing UHF_PORT_POWER support to xhci_roothub_ctrl_locked()
Pull up following revision(s) (requested by kre in ticket #366):
sbin/efi/devpath.c: revision 1.2
PR bin/60403 : sbin/efi - fix core dump from assert in devpath
assert(3) should never be used to validate data from external sources,
only to validate assumptions about how the code itself works.
Worse here, the assert() wasn't even validating that the externally sourced
data was correctly formed, which it was; it was just in a format that wasn't
common, and wasn't expected.
What the output should be (the textual representation of the variable
value) is unknown to me, I haven't been able to locate anything in the
EFI standard which says (or even gives an example of the case in question).
It might be there though somewhere I haven't found yet.
The unusual case is when a variable which contains a path, like:
Boot0000* NetBSD
[9 lines not shown]
Additionally pull up following revision(s) (requested by riastradh in ticket #308):
distrib/sets/lists/tests/mi: revision 1.1408
distrib/sets/lists/comp/mi: revision 1.2526
new openssl test file
new OpenSSL man page
acpi(4): Reset mcfg_nsegs to zero if we couldn't find any valid ones.
acpimcfg_probe initializes mcfg_nsegs to the number of segments in
thef MCFG table, and allocates space at mcfg_segs for an array of
segments, but leaves the array zero-initialized.
Later, acpimcfg_init initializes the array with the valid segments,
and _if there are any_, sets mcfg_nsegs to the number of valid ones.
But _if there aren't any_, acpimcfg_init would leave mcfg_nsegs set
to the amount of space allocated in the array, all zero-initialized.
Later still, if PCI_RESOURCE is enabled, acpimcfg_configure_bus
would, via acpimcfg_get_segment, search mcfg_segs[0..mcfg_nsegs) for
an entry matching a PCI segment and bus number, and if they both
happened to be zero, the first one would match...and
acpimcfg_configure_bus would fish the (null!) seg->ms_bst out of the
all-zero entry and feed it to bus_space_map which would proceed to
barf on the null pointer.
[12 lines not shown]
wg-userspace(8): Tighten rump interface.
1. Don't abuse struct iov as a tuple of two buffers, one of which is
conveying a sockaddr; just pass two separate arguments, one for the
sockaddr and the other for the payload.
2. Avoid sketchy struct sockaddr * scabs; we're a union shop here.
It might seem like a regression to rip out all the scatter/gather
iovecs and require contiguous buffers. But on the input path we
already have a contiguous buffer filled by read(2) or recvfrom(2)
(and there would be no advantage to using readv(v)). And on the
output path, we always generate handshake messages and ciphertext in
contiguous buffers anyway. So no scatter/gather support is actually
lost here.
Cleanup prompted by:
PR bin/60392: assertion "mbuflen >= sizeof(struct wg_msg)" failed
PR bin/60403 : sbin/efi - fix core dump from assert in devpath
assert(3) should never be used to validate data from external sources,
only to validate assumptions about how the code itself works.
Worse here, the assert() wasn't even validating that the externally sourced
data was correctly formed, which it was; it was just in a format that wasn't
common, and wasn't expected.
What the output should be (the textual representation of the variable
value) is unknown to me, I haven't been able to locate anything in the
EFI standard which says (or even gives an example of the case in question).
It might be there though somewhere I haven't found yet.
The unusual case is when a variable which contains a path, like:
Boot0000* NetBSD
HD(3,GPT,d439564b-f7e4-4f92-b6ae-2fa0c33632f2,0x400,0x7f800)/
File(\EFI\BOOT\BOOTX64.EFI)
[9 lines not shown]
Additionally pull up following revision(s) (requested by riastradh in ticket #339):
tests/lib/libc/locale/t_c8rtomb.c: revision 1.8
lib/libc/locale/c8rtomb.c: revision 1.10
lib/libc/citrus/modules/citrus_utf8.c: revision 1.20
lib/libc/citrus/modules/citrus_utf8.c: revision 1.21
lib/libc/citrus/modules/citrus_utf8.c: revision 1.22
Be truly pedantic about UTF-8 encodings
If we're not going to be accepting "legacy" UTF-8
(5 and 6 byte encodings for code points >= 0x00200000 which the
standards don't allow, as they won't fit in UTF-16) then we
certainly should never be able to generate them, and even more
should certainly be pedantic about not allowing the various
forms of mis-coded strings for which there is no justification
but have been known to be used to attempt to violate security.
This, I believe, now enforces all the current restrictions, eg,
[46 lines not shown]
Pullup the following, requested by riastradh in ticket #308:
crypto/external/apache2/openssl//lib/libcrypto/man/X509V3_EXT_print.3 up to
crypto/external/apache2/openssl/include/openssl/opensslv.h up to 1.4
crypto/external/apache2/openssl/lib/libcrypto/man.inc up to 1.7
crypto/external/apache2/openssl/lib/libcrypto/arch/powerpc/chachap10-ppc.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/powerpc64/chachap10-ppc.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv32/Makefile up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv32/aes-riscv32-zkn.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv32/riscv32cpuid.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv64/Makefile up to 1.4
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv64/aes-riscv64-zkn.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv64/aes-riscv64-zvkned.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv64/aes-riscv64.S up to 1.3
crypto/external/apache2/openssl/lib/libcrypto/arch/riscv64/riscv64cpuid.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/sparc/aesfx-sparcv9.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/arch/sparc64/aesfx-sparcv9.S up to 1.2
crypto/external/apache2/openssl/lib/libcrypto/man/ADMISSIONS.3 up to 1.6
crypto/external/apache2/openssl/lib/libcrypto/man/ASN1_EXTERN_FUNCS.3 up to 1.6
[848 lines not shown]
