It is specifically mentioned in the manual page. Note it has no functional
change in reality because DH_set0_pqg() cannot fail when both p and g are
not NULL.
[RISCV] Lower llvm.trap and llvm.debugtrap
Summary:
Until this commit, these have lowered to a call to abort().
`llvm.trap()` now lowers to `unimp`, which should trap on all systems.
`llvm.debugtrap()` now lowers to `ebreak`, which is exactly what this
instruction is for.
Reviewers: asb, luismarques
Reviewed By: asb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69390
This fixes miscompilation resulting in linking failures with
INVARIANTS disabled.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D23857
ftp(1) from vendor/tnftp always tried the following for
every TCP connection:
1. Get the current buffer length of SO_SNDBUF and SO_RCVBUF
by getsockopt(2).
2. Invoke setsockopt(2) to set them to the same values
after checking if they are in a range between 8 KiB to 8 MiB.
This behavior broke dynamic buffer sizing enabled by
default (net.inet.tcp.{recv,send}buf_auto sysctls) and
led to a very poor transfer rate. The fetch(1) utility
does not have this problem.
This change prevents SO_SNDBUF and SO_RCVBUF from configuring
when the buffer auto-sizing is enabled unless the buffer sizes are
explicitly specified.
PR: 240827
Spotted by: Yuichiro NAITO
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D23732
OpenSSL 1.1 API patch for sendmail had a bug which
prevented sm_RSA_generate_key() function from working.
This function is used to generate a temporary RSA key
for a shared memory region used for TLS processing.
Note that 12.0 and 12.1-RELEASE include this bug.
This affects only if SM_CONF_SHM compile-time
option (enabled by default) and SharedMemoryKey
run-time option (not enabled by default) in a .cf file are
specified. The latter corresponds to confSHARED_MEMORY_KEY in
a .mc file.
PR: 242861
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D23734
files. This allows for loading, during the same invocation of ippool, of
multiple sources of input using multiple tools to concurrently maintain the
files such as fail2ban, macro preprocessors, and manually.
MFC after: 1 week
Among the changes from before:
- Add support for extended colors on widechar version
- Enable ncurses extended functions
- Enable version 2 of the extended mouse support
- Enable SCREEN extensions
Modification that differs from upstream:
- _nc_delink_entries used to be exposed and was turn static,
turn it back as dynamic to not break abi
- Adapt our old termcap.c to modern ncurses
MFC after: 3 weeks
The hack in question is intended to workaround seemingly bogus #line markers
in cpp output. As far as I can tell, llvm cpp doesn't do this by default, so
there's no reason to add -P.
In our /bin/sh, the main incantation should be placed in a sub-shell in
order to properly pipe the output to fgrep.
The main motivation for this change is admittedly to stop emitting the noise
about clang not being gcc in make -s buildworld
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22952
Presumably a bool definition is obtained via header contamination on
FreeBSD-CURRENT. Found while trying to upstream FreeBSD addr2line
changes - the FreeBSD 11.2 CI build failed there.
Reported by: Cirrus-CI, upstream ELF Tool Chain
MFC with: r357844
Sponsored by: The FreeBSD Foundation
Update libarchive to 3.4.2
Relevant vendor changes:
PR #1289: atomic extraction support (bsdtar -x --safe-writes)
PR #1308: big endian fix for UTF16 support in LHA reader
PR #1326: reject RAR5 files that declare invalid header flags
Issue #987: fix support 7z archive entries with Delta filter
Issue #1317: fix compression output buffer handling in XAR writer
Issue #1319: fix uname or gname longer than 32 characters in pax writer
Issue #1325: fix use after free when archiving hardlinks in ISO9660 or XAR
Use localtime_r() and gmtime_r() instead of localtime() and gmtime()
X-MFC-With: r356212,r356365,r356416
MFC after: 1 week
Libarchive 3.4.2
Relevant vendor changes:
PR #1289: atomic extraction support (bsdtar -x --safe-writes)
PR #1308: big endian fix for UTF16 support in LHA reader
PR #1326: reject RAR5 files that declare invalid header flags
Issue #987: fix support 7z archive entries with Delta filter
Issue #1317: fix compression output buffer handling in XAR writer
Issue #1319: fix uname or gname longer than 32 characters in pax writer
Issue #1325: fix use after free when archiving hardlinks in ISO9660 or XAR
Use localtime_r() and gmtime_r() instead of localtime() and gmtime()
The version that ended upstream was ultimately slightly different than the
version committed here; notably, statvfs() is used but it's redefined
appropriately to statfs() on FreeBSD since we don't provide the fstypename
for the former interface.
The revokex test does not work when the scratch directory is created on NFS.
Given the nature of NFS, it likely can never work without looking like a
security hole since O_SEARCH would rely on the server knowing that the
directory did have +x at the time of open and that it's OK for it to have
been revoked based on POSIX specification for O_SEARCH.
This does mean that O_SEARCH is only partially functional on NFS in general,
but I suspect the execute bit getting revoked in the process is likely not
common.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23573
The RCSID data was wrong, so this is effectively a record-only merge
with correction of said data. No further changes should be needed in this
area, as we've now upstreamed our local changes to this specific test.
In FreeBSD's O_SEARCH implementation, O_SEARCH in conjunction with O_RDWR or
O_WRONLY is explicitly rejected. In this case, O_RDWR was not necessary
anyways as the file will get created with or without it.
This was submitted upstream as misc/54940 and committed in rev 1.8 of the
file.
Coverity correctly reports this as a resource leak. It's an admittedly minor
one, but plug it anyways.
This has been submitted upstream as misc/54939.
CID: 978288
The caller of dump_object() is responsible for opening the file, let it
be responsible for closing too.
CID: 1411588
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The callers only check whether the returned pointer is non-NULL, so this
was harmless in practice, but change the return value to guard against
the issue.
CID: 1411597
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
We should really create the output file in the same directory as the
destination file so that rename() works. This will be done in a future
change as part of some work to run in capability mode.
CID: 1262523
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The code clearly meant to resize the buffer in the case where a section
was backed by multiple data descriptors.
In practice this shouldn't have been a problem since libelf would return
a single data descriptor for each section in a newly opened file.
CID: 1262522
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
All callers pass a non-NULL pointer, and otherwise it was possible to
leak memory if the abbrev was not added to a CU.
CID: 1193365
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
All callers of _dwarf_add_expr() and _dwarf_expr_into_block() pass a
non-NULL expr pointer, and these functions assume that expr is non-NULL
anyway.
CID: 1193305, 1193306
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
sqlite3-3.30.1 (3300100), as it causes svnlite segfaults on PowerPC,
resulting in corruption.
Reported by: Mark Millard <marklmi at yahoo.com>
Francis Little <oggy at farscape.co.uk>
Previously, addr2line would sequentially search all CUs for each input
address. For some uses, notably syzkaller's code coverage map generator,
this was extremely slow. Add a CU cache into which entries are added
following a successful lookup, and search the cache before falling back
to a scan. When translating a large number of addresses this yields
slightly better performance than GNU addr2line.
Garbage-collect an unused hash table which appears to have been intended
for the same purpose. A hash table doesn't seem particularly suitable
since each CU spans a range of addresses.
Submitted by: Tiger Gao <tig@freebsdfoundation.org>
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23418
O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping
permissions checks on the directory itself after the initial open(). This is
close to the semantics we've historically applied for O_EXEC on a directory,
which is UB according to POSIX. Conveniently, O_SEARCH on a file is also
explicitly undefined behavior according to POSIX, so O_EXEC would be a fine
choice. The spec goes on to state that O_SEARCH and O_EXEC need not be
distinct values, but they're not defined to be the same value.
This was pointed out as an incompatibility with other systems that had made
its way into libarchive, which had assumed that O_EXEC was an alias for
O_SEARCH.
This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC
respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a
directory is checked in vn_open_vnode already, so for completeness we add a
NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not
re-check that when descending in namei.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23247
This construction used some relatively slow design involving SHA2; even if
it were fed real entropy (unclear; external to the design), it did not
handle fork in a safe way, and it was difficult to audit for correctness.
So just rip it out and use the very simple and known-correct arc4random(3)
interface in its place.
In apr_vformatter, the variable buf was declared inside a limited scope
region, but a pointer to it is leaked outside of that region and used
later. This is undefined behavior. Fix by moving the buf variable to
function scope.
Reported by: Coverity
CID: 1192541
Fix the following -Werror warning from clang 10.0.0 in binutils:
contrib/binutils/bfd/peicode.h:1356:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (efi)
^
contrib/binutils/bfd/peicode.h:1353:8: note: previous statement is here
if (pe_arch (bfd_target_efi_arch (*target_ptr)) != arch)
^
contrib/binutils/bfd/peicode.h:1370:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (!efi)
^
contrib/binutils/bfd/peicode.h:1367:8: note: previous statement is here
if (pe_arch (bfd_target_pei_arch (*target_ptr)) != arch)
^
MFC after: 3 days
contrib/binutils/bfd/peicode.h:1356:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (efi)
^
contrib/binutils/bfd/peicode.h:1353:8: note: previous statement is here
if (pe_arch (bfd_target_efi_arch (*target_ptr)) != arch)
^
contrib/binutils/bfd/peicode.h:1370:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (!efi)
^
contrib/binutils/bfd/peicode.h:1367:8: note: previous statement is here
if (pe_arch (bfd_target_pei_arch (*target_ptr)) != arch)
^
MFC after: 3 days
The current code clearly intended for these to be octal based on the values
used, but the octal prefix was forgotten. Add it now for correctness, but
note that we don't currently execute these tests.
This has been submitted upstream as misc/54902, so I've omitted the standard
FreeBSD markers that we tend to put into netbsd-tests for upstream-candidate
identification.
Reviewed by: ngie
MFC after: 3 days
