__sfvwrite() advances the pointer before calling fflush. If fflush()
fails, it is not enough to roll back inside it, because we cannot know
how much was advanced by the caller.
Reported by: Peter <pmc@citylink.dinoex.sub.org>
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Fixes: 86a16ada1e
(cherry picked from commit bafaa70b6f)
time() is now implemented using clock_gettime(2) instead of
gettimeofday(2).
Reviewed by: debdrup
Fixes: 358ed16f75 Use clock_gettime(CLOCK_SECOND)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34438
(cherry picked from commit 413045a52c)
Summary:
Use initial-exec, like other architectures.
While here, switch MACHINE_ARCH in lib/libc/Makefile to LIBC_ARCH and consistently use powerpc.
Subscribers: imp, #contributor_reviews_base
Differential Revision: https://reviews.freebsd.org/D34315
Reviewed by: luporl
MFC after: 2 weeks
(cherry picked from commit 884ba43116)
Testing of a new feature revealed that calling sysctl() to retrieve
the value of the user.localbase variable passing too low a buffer size
could leave the result buffer unchanged.
The behavior in the normal case of a sufficiently large buffer was
correct.
All known callers pass a sufficiently large buffer and have thus not
been affected by this issue. If a non-default value had been assigned
to this variable, the result was as documented, too.
Fix the function to fill the buffer with a partial result, if the
passed in buffer size is too low to hold the full result.
(cherry picked from commit e11ad014d1)
libc: add helper furnction to set sysctl() user.* variables
Testing had revealed that trying to retrieve the user.localbase
variable into to small a buffer would return the correct error code,
but would not fill the available buffer space with a partial result.
A partial result is of no use, but this is still a violation of the
documented behavior, which has been fixed in the previous commit to
this function.
I just checked the code for "user.cs_path" and found that it had the
same issue.
Instead of fixing the logic for each user.* sysctl string variable
individually, this commit adds a helper function set_user_str() that
implements the semantics specified in the sysctl() man page.
It is currently only used for "user.cs_path" and "user.localbase",
but it will offer a significant simplification when further such
variables will be added (as I intend to do).
(cherry picked from commit 9535d9f104)
sysctlbyname(): restore access to user variables
The optimization of sysctlbyname() in commit d05b53e0ba had the
side-effect of not going through the fix-up for the user.* variables
in the previously called sysctl() function.
This lead to 0 or an empty strings being returned by sysctlbyname()
for all user.* variables.
An alternate implementation would store the user variables in the
kernel during system start-up. That would allow to remove the fix-up
code in the C library that is currently required to provide the actual
values.
This update restores the previous code path for the user.* variables
and keeps the performance optimization intact for all other variables.
(cherry picked from commit af7d105379)
A case of undefined behavior in __fread() has been detected by UBSAN
and reported by Mark Millard:
/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying
zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior in
/usr/main-src/lib/libc/stdio/fread.c:133:10
While being benign (the NULL pointer is later passed to memcpy() with
a length argument of 0), this issue causes in the order of 600 Kyua
test cases to fail on systems running a world built with WITH_UBSAN
and WITH_ASAN.
The undefined behavior can be prevented by skipping operations that
have no effect for r == 0. Mark Millard has suggested to only skip
this code segment if fp->_p == NULL, but I have verified that for the
case of r == 0 no further argument checking is performed on the
addresses passed to memcpy() and thus no bugs are hidden from the
sanitizers due to the simpler condition chosen.
(cherry picked from commit 10af8e45a8)
Mark Milliard has detected a case of undefined behavior with the LLVM
UBSAN. The mandoc program called qsort with a==NULL and n==0, which is
allowed by the POSIX standard. The qsort() in FreeBSD did not attempt
to perform any accesses using the passed pointer for n==0, but it did
add an offset to the pointer value, which is undefined behavior in
case of a NULL pointer. This operation has no adverse effects on any
achitecture supported by FreeBSD, but could be caught in more strict
environments.
After some discussion in the freebsd-current mail list, it was
concluded that the case of a==NULL and n!=0 should still be caught by
UBSAN (or cause a program abort due to an illegal access) in order to
not hide errors in programs incorrectly invoking qsort().
Only the the case of a==NULL and n==0 should be fixed to not perform
the undefined operation on a NULL pointer.
This commit makes qsort() exit before reaching the point of
potentially undefined behvior for the case n==0, but does not test
the value of a, since the result will not depend on whether this
pointer is NULL or an actual pointer to an array if n==0.
The issue found by Mark Milliard in the whatis command has been
reported to the upstream (OpenBSD) and has already been patched
there.
(cherry picked from commit d106f982a5)
Require the newly opened file descriptor to be good, instead of
re-requiring the one that was required three lines earlier.
Thankfully, opening /dev/null is really unlikely to fail.
Reported by: Coverity
MFC after: 1 week
Sponsored by: Dell EMC Isilon
(cherry picked from commit a8fea07c30)
The manpage has contained the following verbiage on the matter for just
under 31 years:
"At least one argument must be present in the array"
Previous to this version, it had been prefaced with the weakening phrase
"By convention."
Carry through and document it the rest of the way. Allowing argc == 0
has been a source of security issues in the past, and it's hard to
imagine a valid use-case for allowing it. Toss back EINVAL if we ended
up not copying in any args for *execve().
The manpage change can be considered "Obtained from: OpenBSD"
(cherry picked from commit 773fa8cd13)
(cherry picked from commit c9afc7680f)
Checking there are still bytes left must be done before dereferencing
the pointer, not the other way round. This is harmless on traditional
architectures since the result will immediately be thrown away, and all
callers are in separate translation units so there is no potential for
optimising based on this out-of-bounds read. However, on CHERI, pointers
are bounded, and so this will trap if fed a string that does not have a
NUL within the first len bytes.
Found by: CHERI
Reviewed by: brooks
(cherry picked from commit 6d5297569e)
These are the updated version of the older Cortex Strings Library we
previously used. The Arm Optimized Routines also support CPU features
that are currently in development on FreeBSD, e.g. Branch Target
Identification (BTI). Rather than add BTI support to the old code it's
easier to just use the maintained version.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32774
(cherry picked from commit 2e8ff4d1d5)
