|
|
Message-ID: <1ad23a34-402f-4ac7-8425-1def37154d1b@gmail.com>
Date: Tue, 13 Jan 2026 21:54:43 -0600
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Null Pointer Dereference in HarfBuzz
On 1/13/26 06:34, Vincent Lefevre wrote:
> On 2026-01-12 23:33:37 -0600, Jacob Bachmeyer wrote:
>> The issue reported here is a write to address zero causing SIGSEGV. I doubt
>> that compilers can optimize placement new to avoid writing through the given
>> pointer without introducing undefined behavior in correct programs, since
>> the contents of allocated-but-not-initialized memory are undefined.
> Perhaps in the case of HarfBuzz. But this is not necessarily the case
> everywhere. Consider the following code:
>
> ------------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
>
> __attribute__((noipa)) // imagine it in a separate TU
> int ptest (int *p)
> {
> return p != 0;
> }
>
> int main (void)
> {
> int *p = malloc (99999999999);
> int r = ptest (p);
> p[0] = 12345;
> free (p);
> printf ("%d\n", r);
> return 0;
> }
> ------------------------------------------------------------
>
> On my machine, with GCC and optimizations (e.g. -O), the output is 0
> while such a value could be regarded as impossible by the program
> Due to optimizations, one cannot rely on a crash if the memory could
> not be allocated. So a more complex program would continue with
> inconsistent information.
I am unsure about that: GCC may have been able to elide the write
because it could prove that the value would never be read, since p is
free()d immediately after the write. That is different from library
code that returns a newly-constructed object.
-- 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.