Re: Null Pointer Dereference in HarfBuzz

[Jacob Bachmeyer <jcb62281 () gmail com>]

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