<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/lib/libc/include, branch main</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>lib/libsys, lib/libc: export pdwait</title>
<updated>2026-01-25T15:54:08+00:00</updated>
<author>
<name>Konstantin Belousov</name>
<email>kib@FreeBSD.org</email>
</author>
<published>2026-01-08T03:49:33+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=2d555ec85a716e016be587b2a1606ca69267f870'/>
<id>2d555ec85a716e016be587b2a1606ca69267f870</id>
<content type='text'>
Make pdwait(2) cancellable, same as all other wait*(2) syscalls wrappers.

Reviewed by:	asomers, markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D54592
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make pdwait(2) cancellable, same as all other wait*(2) syscalls wrappers.

Reviewed by:	asomers, markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D54592
</pre>
</div>
</content>
</entry>
<entry>
<title>get*ent: be consistant about _ALIGN(p) - p</title>
<updated>2025-12-10T10:57:34+00:00</updated>
<author>
<name>Brooks Davis</name>
<email>brooks@FreeBSD.org</email>
</author>
<published>2025-12-10T10:57:34+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=ac79e2e025e03b7038e3abc886e34a03f5ec2934'/>
<id>ac79e2e025e03b7038e3abc886e34a03f5ec2934</id>
<content type='text'>
Add an nscache specific inline function to calculate the misalignment
rather than adding and subtracting _ALIGN(p) and p which can take the
buffer far out of bound (undefined behavior in C and unsupported on
CHERI).

Reviewed by:	kib
Effort:		CHERI upstreaming
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D53945
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add an nscache specific inline function to calculate the misalignment
rather than adding and subtracting _ALIGN(p) and p which can take the
buffer far out of bound (undefined behavior in C and unsupported on
CHERI).

Reviewed by:	kib
Effort:		CHERI upstreaming
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D53945
</pre>
</div>
</content>
</entry>
<entry>
<title>libc/resolv: get rid of MD5</title>
<updated>2025-10-04T08:50:02+00:00</updated>
<author>
<name>Robert Clausecker</name>
<email>fuz@FreeBSD.org</email>
</author>
<published>2025-09-29T13:53:14+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d518f64cef6db1d301377e78742b94ca96a881e3'/>
<id>d518f64cef6db1d301377e78742b94ca96a881e3</id>
<content type='text'>
MD5 is used by libc/resolv to generate a random sequence id from a
current time stamp.  Replace this convoluted mechanism with a call
to arc4random().  This permits us to entirely drop MD5 from libc,
simplifying the MD5 rework proposed in D45670.

Approved by:	markj
Reviewed by:	kevans, markj
See also:	D45670
Event:		EuroBSDcon 2025
Differential Revision:	https://reviews.freebsd.org/D52784
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MD5 is used by libc/resolv to generate a random sequence id from a
current time stamp.  Replace this convoluted mechanism with a call
to arc4random().  This permits us to entirely drop MD5 from libc,
simplifying the MD5 rework proposed in D45670.

Approved by:	markj
Reviewed by:	kevans, markj
See also:	D45670
Event:		EuroBSDcon 2025
Differential Revision:	https://reviews.freebsd.org/D52784
</pre>
</div>
</content>
</entry>
<entry>
<title>libc: compat.h: Remove a superfluous blank line at end</title>
<updated>2025-09-17T12:15:54+00:00</updated>
<author>
<name>Olivier Certner</name>
<email>olce@FreeBSD.org</email>
</author>
<published>2025-09-15T16:54:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=580d2d429598e6eb3549f9ea7490d10e19904f7c'/>
<id>580d2d429598e6eb3549f9ea7490d10e19904f7c</id>
<content type='text'>
No functional change (intended).

MFC after:      5 days
Sponsored by:   The FreeBSD Foundation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
No functional change (intended).

MFC after:      5 days
Sponsored by:   The FreeBSD Foundation
</pre>
</div>
</content>
</entry>
<entry>
<title>kern: fix setgroups(2) and getgroups(2) to match other platforms</title>
<updated>2025-08-15T04:06:09+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2025-08-15T04:06:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9da2fe96ff2ea227e4d5f03ef92b55aabeabb7fc'/>
<id>9da2fe96ff2ea227e4d5f03ef92b55aabeabb7fc</id>
<content type='text'>
On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only touching the
supplementary groups of the process.  This poses both portability and
security concerns in porting software to and from FreeBSD, as this
subtle difference is a landmine waiting to happen.  Bugs have been
discovered even in FreeBSD-local sources, since this behavior is
somewhat unintuitive (see, e.g., fix 48fd05999b0f for chroot(8)).

Now that the egid is tracked outside of cr_groups in our ucred, convert
the syscalls to deal with only supplementary groups.  Some remaining
stragglers in base that had baked in assumptions about these syscalls
are fixed in the process to avoid heartburn in conversion.

For relnotes: application developers should audit their use of both
setgroups(2) and getgroups(2) for signs that they had assumed the
previous FreeBSD behavior of using the first element for the egid.  Any
calls to setgroups() to clear groups that used a single array of the
now or soon-to-be egid can be converted to setgroups(0, NULL) calls to
clear the supplementary groups entirely on all FreeBSD versions.

Co-authored-by:	olce (but bugs are likely mine)
Relnotes:	yes (see last paragraph)
Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D51648
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only touching the
supplementary groups of the process.  This poses both portability and
security concerns in porting software to and from FreeBSD, as this
subtle difference is a landmine waiting to happen.  Bugs have been
discovered even in FreeBSD-local sources, since this behavior is
somewhat unintuitive (see, e.g., fix 48fd05999b0f for chroot(8)).

Now that the egid is tracked outside of cr_groups in our ucred, convert
the syscalls to deal with only supplementary groups.  Some remaining
stragglers in base that had baked in assumptions about these syscalls
are fixed in the process to avoid heartburn in conversion.

For relnotes: application developers should audit their use of both
setgroups(2) and getgroups(2) for signs that they had assumed the
previous FreeBSD behavior of using the first element for the egid.  Any
calls to setgroups() to clear groups that used a single array of the
now or soon-to-be egid can be converted to setgroups(0, NULL) calls to
clear the supplementary groups entirely on all FreeBSD versions.

Co-authored-by:	olce (but bugs are likely mine)
Relnotes:	yes (see last paragraph)
Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D51648
</pre>
</div>
</content>
</entry>
<entry>
<title>libc,libthr: Remove __pthread_distribute_static_tls</title>
<updated>2025-07-10T19:00:28+00:00</updated>
<author>
<name>Jessica Clarke</name>
<email>jrtc27@FreeBSD.org</email>
</author>
<published>2025-07-10T19:00:28+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=2c444fdb0c75fbc73a0ac78d0ecbaef4e1e8baf8'/>
<id>2c444fdb0c75fbc73a0ac78d0ecbaef4e1e8baf8</id>
<content type='text'>
This private API is no longer used by rtld-elf so can be removed.

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D50921
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This private API is no longer used by rtld-elf so can be removed.

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D50921
</pre>
</div>
</content>
</entry>
<entry>
<title>libc: Allow more complex expressions for CALL_BLOCK first argument</title>
<updated>2025-06-03T14:19:04+00:00</updated>
<author>
<name>Jessica Clarke</name>
<email>jrtc27@FreeBSD.org</email>
</author>
<published>2025-06-03T14:19:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=680f1a39ee4b6cd2fb4dcf3de195bd58626b9525'/>
<id>680f1a39ee4b6cd2fb4dcf3de195bd58626b9525</id>
<content type='text'>
For the case where the compiler supports blocks we only allow the first
expression to have an operator if it has as high precedence as a
function call, which for blocks effectively means member access and
subscripting only, not even a dereference nor a cast. Parenthesise this,
as is the case for the missing compiler support case, so that it's more
general.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For the case where the compiler supports blocks we only allow the first
expression to have an operator if it has as high precedence as a
function call, which for blocks effectively means member access and
subscripting only, not even a dereference nor a cast. Parenthesise this,
as is the case for the missing compiler support case, so that it's more
general.
</pre>
</div>
</content>
</entry>
<entry>
<title>Provide user interface to retrieve reported extended errors</title>
<updated>2025-05-31T19:52:42+00:00</updated>
<author>
<name>Konstantin Belousov</name>
<email>kib@FreeBSD.org</email>
</author>
<published>2025-05-23T05:03:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a56fe703c2065069cf756bbafcb3dc35c25f5343'/>
<id>a56fe703c2065069cf756bbafcb3dc35c25f5343</id>
<content type='text'>
Reviewed by:	brooks
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D50483
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reviewed by:	brooks
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D50483
</pre>
</div>
</content>
</entry>
<entry>
<title>libc: treat execvpe as a week symbol</title>
<updated>2025-04-22T18:12:26+00:00</updated>
<author>
<name>SHENGYI HONG</name>
<email>aokblast@FreeBSD.org</email>
</author>
<published>2025-04-02T20:35:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d8e841a9aa1f8c4ce50d98b01f1ba1376cdd9705'/>
<id>d8e841a9aa1f8c4ce50d98b01f1ba1376cdd9705</id>
<content type='text'>
Some program intercepts the execvpe call in runtime. At the same time, the
implementation of posix_spwan use execvpe. If execvpe is intercepted and
then calls posix_spawn when intercepted. It wil create a infinite loop
because the intercepted execvpe will spawn a posix_spwan call and will be
intercepted again.

See https://github.com/rizsotto/Bear/issues/557 for reference.

Reviewed by:	brooks, kib, emaste
Sponsored by:	FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49733
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some program intercepts the execvpe call in runtime. At the same time, the
implementation of posix_spwan use execvpe. If execvpe is intercepted and
then calls posix_spawn when intercepted. It wil create a infinite loop
because the intercepted execvpe will spawn a posix_spwan call and will be
intercepted again.

See https://github.com/rizsotto/Bear/issues/557 for reference.

Reviewed by:	brooks, kib, emaste
Sponsored by:	FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49733
</pre>
</div>
</content>
</entry>
<entry>
<title>libc, libthr: coordinate stubs for pthread_{suspend,resume}_all_np</title>
<updated>2024-11-14T02:48:05+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2024-11-14T02:48:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=83aafcdc88928c99e80b04ead23a156e235f9af4'/>
<id>83aafcdc88928c99e80b04ead23a156e235f9af4</id>
<content type='text'>
If libthr isn't linked into the process, then we don't have any pthreads
to worry about and our stubs can just return success -- there are none
to suspend/resume.

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D47350
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If libthr isn't linked into the process, then we don't have any pthreads
to worry about and our stubs can just return success -- there are none
to suspend/resume.

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D47350
</pre>
</div>
</content>
</entry>
</feed>
