On 1/10/26 19:54, Alan Coopersmith wrote:
https://github.com/harfbuzz/harfbuzz/security/advisories/GHSA-xvjr-f2r9-c7ww
advises:
HarfBuzz Null Pointer Dereference Vulnerability Report
======================================================
[...]
2. Vulnerability Description and Impact
Description
-----------
A null pointer dereference vulnerability exists in the
SubtableUnicodesCache::create function located in
src/hb-ot-cmap-table.hh:1672-1673. The function fails to check if
hb_malloc returns NULL before using placement new to construct an
object at the returned pointer address.
When hb_malloc fails to allocate memory (which can occur in low-memory
conditions or when using custom allocators that simulate allocation
failures), it returns NULL. The code then attempts to call the
constructor on this null pointer using placement new syntax, resulting
in undefined behavior and a Segmentation Fault.
Impact
------
DoS can be triggered.
3. Scenario
The function prototype is as follows:
// src/hb-ot-cmap-table.hh:1669-1675
static SubtableUnicodesCache* create (hb_blob_ptr_t<cmap> source_table)
{
SubtableUnicodesCache* cache =
(SubtableUnicodesCache*) hb_malloc
(sizeof(SubtableUnicodesCache));
new (cache) SubtableUnicodesCache (source_table);
return cache;
}
[...]
Although all operands are pointer types, there is no null check for
the return
value of hb_malloc, causing placement new to be executed on a null
pointer.
[...]
5. Result
Segmentation Fault occurs.
[...]
Analysis
Error Type: SEGV (Segmentation Violation)
Access Address: 0x000000000000 (null pointer)
Access Type: WRITE (write access)
Occurrence Location: hb-ot-cmap-table.hh:1692 (inside constructor)
Root Cause Location: hb-ot-cmap-table.hh:1673 (missing null check)
[...]
Severity: Moderate 5.3 / 10
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVE ID: CVE-2026-22693
The fix is listed as:
https://github.com/harfbuzz/harfbuzz/commit/1265ff8d990284f04d8768f35b0e20ae5f60daae
which was merged yesterday, weeks after the 12.3.0 release, despite
the CVE record
claiming "This issue has been patched in version 12.3.0."
Aside from the dubious patch, this is a good example of a legitimate bug
but bogus CVE: how exactly does an attacker trigger this without either
having *already* completed a DoS attack (consuming all memory) or
achieved arbitrary code execution (altering the allocator to return NULL
even though memory is available)?
In short, this is a crash bug, but not a security issue. This is
different from (for example) a parser bug that results in NULL being
dereferenced if crafted input is processed.
Are we now using CVE IDs as some kind of global bug tracker?
-- Jacob
