iconv VIQR: Fix use-after-free during destruction.
PR lib/59019: various iconv issues
Prompted by investigating:
PR lib/60413: iconv_samples test crashes on sparc*
Fixed in FreeBSD back in 2022, and I confirmed -Wuse-after-free catches
this for us too, but we're not using it -- maybe we should:
commit 8f27c9d14a559f33aa7fc3245f841f7ce52fadd5
Author: John Baldwin <jhb at FreeBSD.org>
Date: Mon Oct 3 16:10:43 2022 -0700
libiconv VIQR: Fix a use after free.
Use TAILQ_FOREACH_SAFE to walk to list of children mnemonics to
free
[5 lines not shown]
Pull up following revision(s) (requested by mrg in ticket #372):
external/mit/xorg/lib/libEGL/Makefile: revision 1.10
external/mit/xorg/lib/driver.mk: revision 1.9
external/mit/xorg/lib/libgbm/Makefile: revision 1.11
external/mit/xorg/lib/libGL/Makefile: revision 1.36
ensure HAVE_NOATEXIT is properly set for all that need it.
Increase size of bpfjit interal stack, follow bpf_validate() closely.
Increase a size of M[] array allocated on the stack by bpfjit.
When bpf_validate() fails, bpfjit now fails too:
- Fail to validate/compile BVF_DIV+BPF_K and BPF_MOD+BPF_K with K=0.
- Fail unless the last instruction is BPF_RET+BPF_A or BPF_RET+BPF_K.
If a program contains additional BPF_RET instructions, it is accepted
by bpf_validate() and it compiles fine by bpfjit but both bpf_filter()
and bpfjit reject it (return 0) at runtime.
Adjust existing bpfjit test to follow the changes, add new tests.
defflag M68K_MMU_CUSTOM. Checks for this were added a while ago, but
the defflag was missed. It's not expected to be used directly by
configus, but is there as something other MMU options can add as a
dependency.
Pull up following revision(s) (requested by gson in ticket #371):
usr.sbin/sysinst/run.c: revision 1.17
usr.sbin/sysinst/defs.h: revision 1.98
usr.sbin/sysinst/util.c: revision 1.85
usr.sbin/sysinst/main.c: revision 1.39
Make sysinst intercept kernel console messages using TIOCCONS at all
times, not just when running an external command, and discard those
that occur when not running an external command so that they don't
mess up the display when running sysinst on the console. Fixes
PR install/54932.
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
