Improve wording and also fix the constants' names.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46220
(cherry picked from commit 6e744de1a3dc5dde8d2ee51e97a1224a01bdfb21)
An overread condition in memccpy(dst, src, c, len) would occur if
src does not cross a 16 byte boundary and there is no instance of
c between *src and the next 16 byte boundary. This could cause a
read fault if src is just before the end of a page and the next page
is unmapped or unreadable.
The bug is a consequence of basing memccpy() on the strlcpy() code:
whereas strlcpy() assumes that src is a nul-terminated string and
hence a terminator is always present, c may not be present at all in
the source string. It was not caught earlier due to insufficient
unit test design.
As a part of the fix, the function is refactored such that the runt
case (buffer length from last alignment boundary between 1 and 32 B)
is handled separately. This reduces the number of conditional
branches on all code paths and simplifies the handling of early
matches in the non-runt case. Performance is improved slightly.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ sec/op │ sec/op vs base │
Short 66.76µ ± 0% 62.45µ ± 1% -6.44% (p=0.000 n=20)
Mid 7.938µ ± 0% 7.967µ ± 0% +0.36% (p=0.001 n=20)
Long 3.577µ ± 0% 3.577µ ± 0% ~ (p=0.429 n=20)
geomean 12.38µ 12.12µ -2.08%
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ B/s │ B/s vs base │
Short 1.744Gi ± 0% 1.864Gi ± 1% +6.89% (p=0.000 n=20)
Mid 14.67Gi ± 0% 14.61Gi ± 0% -0.36% (p=0.001 n=20)
Long 32.55Gi ± 0% 32.55Gi ± 0% ~ (p=0.429 n=20)
geomean 9.407Gi 9.606Gi +2.12%
Reported by: getz
Reviewed by: getz
Approved by: mjg (blanket, via IRC)
See also: D46051
MFC: stable/14
Event: GSoC 2024
Differential Revision: https://reviews.freebsd.org/D46052
We are not 100% compatible with 1.0.16, but implement some
functionality from that version that is required by certain ports.
PR: 277799
PR: 279555 (exp-run)
Event: Kitchener-Waterloo Hackathon 202406
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45514
(cherry picked from commit 5654b42142e1f689b26d405c90379b85f22349a0)
This is a fixed version of 888796ade284.
PR: 277783
Reported by: Victor Stinner
Reviewed by: emaste
MFC after: 1 week
(cherry picked from commit 888796ade2842486d3167067e8034254c38aadd3)
(cherry picked from commit e77ad954bb825983b4346b9cc646c9c910b1be24)
(cherry picked from commit 34f746cc7f8a8dd261027a8b392b76e70adc8438)
These ones were unambiguous cases where the Foundation was the only
listed copyright holder.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 5c2bc3db201a4fe8d7911cf816bea104d5dc2138)
Add the ability to pre-resolve architecture-specific EABI symbols and
use it on arm for selected EABI functions. These functions can be called
with rtld bind lock write-locked, so they should be resolved in forward.
Reported by: Mark Millard <marklmi@yahoo.com>, John F Carr <jfc@mit.edu>
Reviewed by: kib, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D46104
(cherry picked from commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0)
Use the Global Offset Table to find the location of main in crt1. With
lld the old code would point to main@plt, however ld.bfd fails to link
when main is in a shared library.
Fix this by using the GOT address to find main as it works with both
lld and bfd.
Reviewed by: jrtc27
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45259
(cherry picked from commit 53120fbb68952b7d620c2c0e1cf05c5017fc1b27)
See 8164d511d6a6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
for some background. Here we should really be testing MK_CLANG instead,
since that's what gates compilation of libclang_rt.
Fixes: 8164d511d6a6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
(cherry picked from commit da925fcebf397cc3bfc74b7aa9757efd6231aa00)
There is some exotic conditional logic here to avoid building a
particular test if a certain UBSAN library isn't present in the
toolchain sysroot. This causes build failures for me when doing an
"installworld WITHOUT_TOOLCHAIN=", which I do frequently during tests.
I believe the problem is that SYSROOT is unset during installworld, so
the build sees the host's copy of libclang_rt.ubsan_standalone.a and
then tries to install a binary that wasn't built during buildworld. Try
to make the check a bit less fragile.
Reviewed by: dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45035
(cherry picked from commit 8164d511d6a6053df82911e7d4ebb34fff3d765c)
The functions like gmtime(3) expect to cache a GMT time zone. Some
sandboxed programs (like last(1)) use the gmtime(3) function.
In case of last(1), this function fails to load a proper time zone
because it is called after entering the capability mode.
_open () at _open.S:4
0x00000008011bc5a8 in tzloadbody (name=0x8018b9580 "/usr/share/zoneinfo/Etc/UTC", sp=0x801870140,
tzload (name=<optimized out>, sp=0x801870140, doextend=true)
0x00000008011bb8ba in gmtload (sp=0x801870140) at /usr/src/contrib/tzcode/localtime.c:1456
gmtcheck () at /usr/src/contrib/tzcode/localtime.c:1581
0x000000080111f85a in _libc_once (once_control=0x80127c550, init_routine=0x0)
_once (once_control=0x80127c550, init_routine=0x0) at /usr/src/lib/libc/gen/_once_stub.c:63
0x00000008011bb9d0 in gmtime_r (timep=0x7fffffffe3a8, tmp=0x80127c568)
gmtime (timep=timep@entry=0x7fffffffe3a8) at /usr/src/contrib/tzcode/localtime.c:1865
0x0000000001024cd4 in printentry (bp=bp@entry=0x8018b4800, tt=tt@entry=0x80186a0a0)
0x00000000010245ae in doentry (bp=0x8018b4800)
0x00000000010243a7 in main (argc=1, argv=<optimized out>)
This time zone is not loaded by the tzset(3) function. Because of
that, extend the caph_cache_tzdata(3) function to also include the
GMT time zone. There is no other way to cache this data than
calling gmtime(3) once.
MFC after: 5 days
Reviewed by: emaste, markj
Differential Revision: https://reviews.freebsd.org/D45297
(cherry picked from commit e24ff5c99be080007ff9086398fbe3ef56cd94dc)
It seems that there are still some applications that use ftime(3)
(for example, science/siconos and sysutils/lcdproc). The issue
is that we don't build libcompat as a shared library anymore.
The easiest solution is to move it to libutil, until we
deprecate it for good.
This solution was proposed by kib@ in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257789.
PR: 257789
MFC after: 1 month
Reviewed by: kib (ages ago)
Differential Revision: https://reviews.freebsd.org/D39994
(cherry picked from commit bb421be6c1174fad837973acc5e4a7bade4489db)
The libarchive code uses sysconf(3) to determine the number of threads
when 0 has been given as the number of thread to use
MFC after: 3 days
(cherry picked from commit a25e0ba57ee17e75ab27fdc09ac3275a8215087e)
Before this commit, we only had the capability to check if a specific
capability was set (using cap_rights_is_set function). However, there
was no efficient method to determine if a cap_rights_t structure doesn't
contain any capability. The cap_rights_is_empty function addresses
this gap.
PR: 275330
Reported by: vini.ipsmaker@gmail.com
Reviewed by: emaste, markj
Differential Revision: https://reviews.freebsd.org/D42780
(cherry picked from commit a7100ae23aca07976926bd8d50223c45149f65d6)
Fix pam_xdg as pam_get_item can return NULL, this happens when pressing
control + C in xdm for example.
MFC after: 1 week
PR: 279268
(cherry picked from commit cca0ce62f367d03ed429bf99e41e6aca8cb7f2ac)
To fix WITHOUT_NIS build. Building yp_xdr.c is gated by MK_NIS.
PR: 279270
Reported by: peterj
Reported by: matteo
Reported by: Michael Dexter's Build Option Survey run
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45347
(cherry picked from commit 61639bb3fc5abe0bb7b096e643b51c30703ac432)
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45290
(cherry picked from commit 1ab62c8d067454b77bc9fb1c5aac75f263bb4143)
This is better than hardcoding device paths in mixer applications.
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45275
(cherry picked from commit 67c89b21b95601c01bafe5a0c518d320a39111c0)
mixer(8)'s -a option is used to print information about all mixer
devices in the system. To do this, it loops from 0 to
mixer_get_nmixers(), and tries to open "/dev/mixer%d". However, this
approach doesn't work when there are disabled/unregistered mixers in the
system, or when an audio device simply doesn't have a mixer.
mixer_get_nmixers() calls SNDCTL_SYSINFO and returns
oss_sysinfo->nummixers, whose value is the number of currently _enabled_
mixers only. Taking the bug report mentioned below (277615) as an
example, suppose a system with 8 mixer devices total, but 3 of them are
either disabled or non-existent, which means they will not show up under
/dev, meaning we have 5 enabled mixer devices, which is also what the
value of oss_sysinfo->nummixers will be. What mixer(8) will do is loop
from 0 to 5 (instead of 8), and start calling mixer_open() on
/dev/mixer0, up to /dev/mixer4, and as is expected, the first call will
fail right away, hence the error shown in the bug report.
To fix this, modify oss_sysinfo->nummixers to hold the value of the
maximum unit in the system, which, although not necessarily "correct",
is more intuitive for applications that will want to use this value to
loop through all mixer devices.
Additionally, notify applications that a device is
unavailable/unregistered instead of skipping it. The current
implementations of SNDCTL_AUDIOINFO, SNDCTL_MIXERINFO and
SNDCTL_CARDINFO break applications that expect to get information about
a device that is skipped. Related discussion can be found here:
https://reviews.freebsd.org/D45135#1029526
It has to be noted, that other applications, apart from mixer(8), suffer
from this.
PR: 277615
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45256
(cherry picked from commit 5d980fadf73df64a1e0eda40a93170ed76ce6f14)
access(), eaccess() and faccessat() will always dereference
symbolic links.
So add a note in the manual page, that lstat(2) should be
used in the case of symbolic links.
PR: 262895
Reviewed by: gbe, pauamma_gundo.com
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44890
(cherry picked from commit 421025a274fb5759b3ecc8bdb30b24db830b45ae)
This is required for GCC to build.
PR: 272759
Reported by: dgilbert@eicat.ca
Submitted by: jrtc27
Differential Revision: https://reviews.freebsd.org/D44333
(cherry picked from commit 1947a9383ec3a048e334022365aa199a6ae55289)
Release notes at
https://www.nlnetlabs.nl/news/2024/May/08/unbound-1.20.0-released/
Security: The DNSBomb vulnerability CVE-2024-33655
Merge commit 'c2a80056864d6eda0398fd127dc0ae515b39752b' into main
(cherry picked from commit 335c7cda12138f2aefa41fb739707612cc12a9be)
The array is 2 x 2 x 2, not 2 x 2 x 3.
Sponsored by: Rubicon Communications, LLC ("Netgate")
MFC after: 2 weeks
(cherry picked from commit a3f7176523e8611b259cefd7431c01e24f446db7)
Capsicum-sandboxed applications generally cannot use dlopen, as absolute
and cwd-relative paths cannot be accessed. Mention that fdlopen is
useful for sandboxed applications.
PR: 277169
Reviewed by: markj, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45108
(cherry picked from commit d84fd89ecd404ffbf629381d2dde14fd79b39402)
The CLOCK_* constants are "defined variable or preprocessor constants"
and so use .Dv.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45106
(cherry picked from commit 2d29d2ecebf8ea19221995b3ea2e3a7ac700bf81)
The WITH_LLVM_TARGET_ENABLE_SPARC option was removed a long time ago,
but some ifdefs were still laying around, so clean them up.
PR: 276104
MFC after: 3 days
(cherry picked from commit 6f444019009a55aac18d18054d154155fbf606c9)
