deadsimple BSD Security Advisories and Announcements

FreeBSD Errata Notice FreeBSD-EN-24:13.libc++

Hash: SHA512

FreeBSD-EN-24:13.libc++                                         Errata Notice
                                                          The FreeBSD Project

Topic:          Incorrect size passed to heap allocated std::string delete

Category:       contrib
Module:         libc++
Announced:      2024-06-19
Affects:        FreeBSD 14.1
Corrected:      2024-06-07 07:29:25 UTC (stable/14, 14.1-STABLE)
                2024-06-19 20:36:50 UTC (releng/14.1, 14.1-RELEASE-p1)
                2024-06-07 07:29:30 UTC (stable/13, 13.3-STABLE)

For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit

I.   Background

libc++ is an implementation of the C++ Standard Library, provided by the LLVM
project. It is used by C++ programs in the base system, and also by many C++
programs in the ports collection. 

II.  Problem Description

C++14 and later supports size-aware deletion of heap objects, when the compiler
is able to determine at compile time what the exact size of a particular object
is. For this purpose, there are specific variants of "operator delete" that take
an additional size_t argument. If such a variant is called, the size is passed
through to the underlying allocator, which can optionally utilize this size for
for more efficient deallocation.

A recent change in libc++'s implementation of std::string has introduced a
potential mismatch between the actual size allocated on the heap for the
contained string, and the size that is passed to "operator delete" when the
string is eventually destroyed.

III. Impact

The default allocator in FreeBSD does not leverage the size_t argument and is

When std::string objects of a known size are deleted, and the size passed
through to the deallocation function does not match the actual size on the heap,
the underlying allocator can potentially produce unexpected results. In case of
allocators that are used for heap debugging or profiling, such as with Google's
gperftools (aka tcmalloc) this can lead to runtime warnings about incorrect

IV.  Workaround

No workaround is available. Systems using the default memory allocator are
not affected.

V.   Solution

Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.

Perform one of the following:

1) To update your system via a binary patch:

Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms,
or the i386 platform on FreeBSD 13, can be updated via the freebsd-update(8)

# freebsd-update fetch
# freebsd-update install

No reboot is necessary, but programs compiled against the old version of the
<string> header should be rebuilt to fully fix the problem.

2) To update your system via a source code patch:

The following patches have been verified to apply to the applicable
FreeBSD release branches.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch
# fetch
# gpg --verify libc++.patch.asc

b) Apply the patch.  Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system using buildworld and installworld as
described in <URL:>.

No reboot is necessary, but programs compiled against the old version of the
<string> header should be rebuilt to fully fix the problem.

VI.  Correction details

This issue is corrected as of the corresponding Git commit hash in the
following stable and release branches:

Branch/path                             Hash                     Revision
- -------------------------------------------------------------------------
stable/14/                              55c5dad2f305    stable/14-n267917
releng/14.1/                            8e0e6b428cb8  releng/14.1-n267681
stable/13/                              ef4d145057c1    stable/13-n257958
- -------------------------------------------------------------------------

Run the following command to see which files were modified by a
particular commit:

# git show --stat <commit hash>

Or visit the following URL, replacing NNNNNN with the hash:


To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:

# git rev-list --count --first-parent HEAD

VII. References

<other info on the problem>


The latest revision of this advisory is available at