Adding back arguments, which were missed during the import of ncurses version
6.5, to the code gen awk script.
This is modified from lib_keyname.c and keys.list targets in
contrib/ncurses/ncurses/Makefile.in of
21817992b3314c908ab50f0bb88d2ee750b9c4ac
PR: 280697
Reported by: np
Reviewed by: bapt
Tested by: scf
Fixes: 21817992b331 ncurses: vendor import version 6.5
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47153
(cherry picked from commit 514f4e89acd2e7b1824b261055bef49a3da6a956)
This function is called by GCC 14 if a destructor invoked during
exception unwinding throws an exception.
Reviewed by: emaste
Obtained from: libcxxrt commit 391a3dcc1054e18c2f0dff4e14d6d79ac95399d7
Differential Revision: https://reviews.freebsd.org/D46004
(cherry picked from commit 297a9e552b9a5adf07d195eae9649b0758f395af)
Previously a stream opened as read-only could be written to. Add a test
case for the fix.
Also correct another incorrect access mode check that worked by
accident, and improve the tests for that.
PR: 281953
Reported by: Erkki Moorits, fuz
Reviewed by: fuz, khng (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47265
(cherry picked from commit 0953460ce149e6f384aafbcb1e6213dfbf8f6a16)
(cherry picked from commit 6b9f7133aba44189d9625c352bc2c2a59baf18ef)
Prevent a potentially sufficiently smart compiler from optimising
away our attempts to clear sensitive buffers.
A related change was discussed and rejected in D16059, but I don't
believe the reasoning there applies: the code clearly documents its
intent that the `memset` calls clear sensitive buffers so they don't
hang around. `explicit_bzero` is the appropriate function for this
purpose. A potential performance disadvantage seems less important:
the functions in crypt are specifically designed to be slow, so a
few extra calls to guarantee that sensitive buffers are cleared does
not significantly affect runtime.
See also: D16059
Reviewed by: delphij, kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47037
(cherry picked from commit a2c0d2026fb422ade2171da4bc6d5d2773b268a6)
Libarchive 3.7.7
Security fixes:
#2158 rpm: calculate huge header sizes correctly
#2160 util: fix out of boundary access in mktemp functions
#2168 uu: stop processing if lines are too long
#2174 lzop: prevent integer overflow
#2172 rar4: protect copy_from_lzss_window_to_unp() (CVE-2024-20696)
#2175 unzip: unify EOF handling
#2179 rar4: fix out of boundary access with large files
#2203 rar4: fix OOB access with unicode filenames
#2210 rar4: add boundary checks to rgb filter
#2248 rar4: fix OOB in delta filter
#2249 rar4: fix OOB in audio filter
#2256 fix multiple vulnerabilities identified by SAST
#2258 cpio: ignore out-of-range gid/uid/size/ino and harden AFIO parsing
#2265 rar5: clear 'data ready' cache on window buffer reallocs
#2269 rar4: fix CVE-2024-26256 (CVE-2024-26256)
#2330 iso: be more cautious about parsing ISO-9660 timestamps
#2343 tar: clean up linkpath between entries
#2364 tar: don't crash on truncated tar archives
#2366 gzip: prevent a hang when processing a malformed gzip inside a gzip
#2377 tar: fix two leaks in tar header parsing
Important bugfixes:
#2096 rar5: report encrypted entries
#2150 xar: fix another infinite loop and expat error handling
#2173 shar: check strdup return value
#2161 lha: fix integer truncation on 32-bit systems
#2338 tar: fix memory leaks when processing symlinks or parsing pax headers
#2245 7zip: fix issue when skipping first file in 7zip archive that
is a multiple of 65536 bytes
#2252 7-zip: read/write symlink paths as UTF-8
#2259 rar5: don't try to read rediculously long names
#2290 ar: fix archive entries having no type
#2360 tar: fix truncation of entry pathnames in specific archives
CVE: CVE-2024-20696, CVE-2024-26256
(cherry picked from commit bd66c1b43e33540205dbc1187c2f2a15c58b57ba)
Add a minimal membarrier man page that documents the available cmd
values and errors that can be returned. We can add more information and
iterate on it in the tree.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46967
(cherry picked from commit 1fc766e3b41d0cdbd166ef95258434069a90ca52)
(cherry picked from commit 92cd5abb64dd70c305535c9504c6a2b73552147f)
(cherry picked from commit 8b41e693fc3956385d5771d60ee93e18001a5a0d)
This is a feature which allows one to splice two TCP sockets together
such that data which arrives on one socket is automatically pushed into
the send buffer of the spliced socket. This can be used to make TCP
proxying more efficient as it eliminates the need to copy data into and
out of userspace.
The interface is copied from OpenBSD, and this implementation aims to be
compatible. Splicing is enabled by setting the SO_SPLICE socket option.
When spliced, data that arrives on the receive buffer is automatically
forwarded to the other socket. In particular, splicing is a
unidirectional operation; to splice a socket pair in both directions,
SO_SPLICE needs to be applied to both sockets. More concretely, when
setting the option one passes the following struct:
struct splice {
int fd;
off_t max;
struct timveval idle;
};
where "fd" refers to the socket to which the first socket is to be
spliced, and two setsockopt(SO_SPLICE) calls are required to set up a
bi-directional splice.
select(), poll() and kevent() do not return when data arrives in the
receive buffer of a spliced socket, as such data is expected to be
removed automatically once space is available in the corresponding send
buffer. Userspace can perform I/O on spliced sockets, but it will be
unpredictably interleaved with splice I/O.
A splice can be configured to unsplice once a certain number of bytes
have been transmitted, or after a given time period. Once unspliced,
the socket behaves normally from userspace's perspective. The number of
bytes transmitted via the splice can be retrieved using
getsockopt(SO_SPLICE); this works after unsplicing as well, up until the
socket is closed or spliced again. Userspace can also manually trigger
unsplicing by splicing to -1.
Splicing work is handled by dedicated threads, similar to KTLS. A
worker thread is assigned at splice creation time. At some point it
would be nice to have a direct dispatch mode, wherein the thread which
places data into a receive buffer is also responsible for pushing it
into the sink, but this requires tighter integration with the protocol
stack in order to avoid reentrancy problems.
Currently, sowakeup() and related functions will signal the worker
thread assigned to a spliced socket. so_splice_xfer() does the hard
work of moving data between socket buffers.
Co-authored by: gallatin
Reviewed by: brooks (interface bits)
MFC after: 3 months
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D46411
(cherry picked from commit a1da7dc1cdad8c000622a7b23ff5994ccfe9cac6)
The upstream fix to make lld output for our EFI loaders reproducible
again was committed in 54521a2ff93a. Bump lld's LINKER_FREEBSD_VERSION
to be able to check this in the EFI loader Makefile.
MFC after: 3 days
(cherry picked from commit f97c7fdc59d252cc8611968ffac541d4b8342b8b)
The manual page says %m is replaced with “the string representation of
the error code stored in the errno variable at the beginning of the
call”. However, we don't actually save `errno` until fairly late in
`__vfprintf()`. Make sure it is saved before we do anything that
might perturb `errno`.
MFC after: 1 week
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D46718
(cherry picked from commit 74f1007fcc838501c74a633792c3f01833bf65e1)
Return errno rather than -1 on error. This allows pfctl to report much
more useful errors.
Reported by: Alexander Leidinger <Alexander@Leidinger.net>
MFC after: 1 week
(cherry picked from commit 93e96359c980ccf318fe089b30b863f7c910b622)
Checking the first nibble of the IPv6 address to be 0 and then
excluding two well known cases (v4-mapped, loopback) leaves us with
more cases where the first nibble could be 0, e.g., the RFC 6052,
2.1 Well-Known Prefix 64:ff9b::/96.
It is not practical to track them all and it is not clear what lead
to this special casing originally, so remove them.
While here also remove the IN6_IS_ADDR_LINKLOCAL() + NI_NUMERICHOST
case as link-local address resolution does exist.
We do leave the IN6_IS_ADDR_MULTICAST() case for now as I could
not find any references to any official reverse lookups for these.
Adding comments for more case (and some historic behaviour) in order
to make it easier to follow the logic.
PR: 279618
Fixes: 6cb9418289
Reviewed by: hrs
Differential Revision: https://reviews.freebsd.org/D45547
(cherry picked from commit c179937b986ec3959d89bfeb8eed0a6f58a28649)
Normalize on hard tabs.
I didn't catch this before pushing the previous commit.
No functional changes intended.
MFC after: 2 weeks
MFC with: 8ef8da882ff475e3da3bde57d97593a68f7d97b2
(cherry picked from commit 61b15e6dfc963a0c67dbaeae7f4590674976111f)
Make the system call honor `AT_SYMLINK_NOFOLLOW`.
Also enable this from `linux_faccessat2` where the issue arised the first time.
Update manual pages accordingly.
PR: 275295
Reported by: kenrap@kennethraplee.com
Approved by: kib@
Differential Revision: https://reviews.freebsd.org/D46267
(cherry picked from commit 5ab6ed93cd3680f8b69dd4d05823f4740a2bdef9)
Fix "singleton" function used by regcomp() to turn character set matches
into exact character matches if a character set has exactly one
element.
The underlying cset representation is complex; most critically it
records"small" characters (codepoint less than either 128
or 256 depending on locale) in a bit vector, and "wide" characters in
a secondary array.
Unfortunately the "singleton" function uses to identify singleton sets
treated a cset as a singleton if either the "small" or the "wide" sets
had exactly one element (it would then ignore the other set).
The easiest way to demonstrate this bug:
$ export LANG=C.UTF-8
$ echo 'a' | grep '[abà]'
It should match (and print "a") but instead it doesn't match because the
single accented character in the set is misinterpreted as a singleton.
PR: 281710
Reviewed by: kevans, yuripv
Obtained from: illumos
(cherry picked from commit 8f7ed58a15556bf567ff876e1999e4fe4d684e1d)
libgeom maintains a quasi-private mapping of /dev/devstat, which might
grow over time if new devices appear. When the mapping needs to be
expanded, the old mapping is passed as a hint, but this appears to be
unnecessary.
Simplify and improve things a bit:
- stop passing a hint when remapping,
- don't creat a mapping in geom_stats_open(), as geom_stats_resync() will
create it for us,
- check for errors from munmap().
Reviewed by: imp, asomers
Tested by: asomers
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D46294
(cherry picked from commit d06fe346eccf0919a29d43599548e49c0d6a7a17)
The index symbol doesn't belong in memcpy.S as it is already in
strchr.S where it belongs.
Sponsored by: Arm Ltd
(cherry picked from commit 024248c933c5741a21c17eda63092f330dd98337)
Add support for extra registers to the arm64 getcontextx. As no
registers are defined this just adds the extra register list and an end
context.
Reviewed by: kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44255
(cherry picked from commit 5202ca77aaf552310bcbaccba750ee9f0888d0d8)
This will be used as the base of a non-trivial implementation.
Reviewed by: kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44254
(cherry picked from commit fd6b1cc34e4175c1e223f42540debb74cfe3c3e6)
When trying to use a VLAN device (e.g. "em0.123") with a dot
the library fails to parse the interface correctly. The former
pattern is much too restrictive given that almost all characters
can be coerced into a device name via ifconfig.
Remove the particularly restrictive validation. Some characters
still cannot be used as an interface name as they are used as
delimiters in the syntax, but this allows to be able to use most
of them without an issue.
Submitted by: franco@opnsense.org
Differential Revision: https://reviews.freebsd.org/D42485
Reviewed by: vmaffione
