[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56e7f252-59a4-447c-b8ee-29e647c6bc3b@gmail.com>
Date: Sun, 11 Jan 2026 21:09:55 -0600
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com,
Alan Coopersmith <alan.coopersmith@...cle.com>
Subject: Re: Null Pointer Dereference in HarfBuzz
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
