Re: Null Pointer Dereference in HarfBuzz

[Jacob Bachmeyer <jcb62281 () gmail com>]

On 1/12/26 07:43, Greg KH wrote:
> On Mon, Jan 12, 2026 at 10:42:33AM +0100, Jan Engelhardt wrote:
> > On Monday 2026-01-12 04:09, Jacob Bachmeyer wrote:
> > > 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?
> > Isn't that how the Linux kernel works these days,
> > as per <https://docs.kernel.org/process/cve.html>:
> >
> > "almost any bug might be exploitable to compromise the security of
> > the kernel, but the possibility of exploitation is often not evident
> > when the bug is fixed"
> The kernel might be a bit "different" here, given that any type of bug
> that happens at the level of Linux can cause a system failure (i.e.
> vulnerability), while I don't know if harfbuzz is at that same level
> (i.e. does it claim to support any invalid input, like the kernel does?)

The bug only occurs if allocation returns a NULL pointer in a context 
that does not appear to depend on input at all; the attacker does not 
get to cause an attempt to allocate HUGE_VALUE here.

If an attacker can craft input such that millions of 
"SubtableUnicodesCache" objects are allocated when normal processing 
only allocates one, that would be a security issue leading to DoS, but 
that is not the bug reported here.

Such an issue would also *itself* be a vehicle for DoS by allocating all 
available memory.  This NULL pointer deference would make that 
hypothetical DoS harder to exploit by crashing the affected program as 
soon as memory pressure is extreme enough for an allocation to fail.


-- Jacob