Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Haoxin Tu]

Hi Martin and Paul,

Thanks for your detailed explanation. I have no further concerns now.

Have a great day ahead!

Best regards,
Haoxin

Paul Smith  于2024年1月21日周日 23:24写道：

> On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote:
> > May I know if you are planning to propose a fix for it? I checked the
> > implementations of other `make` versions a bit further, and as far as
> > I can tell, the issue exists from the older make-4.0.90 (2014-9-30)
> > to the newest version of make (make-4.4.0.91).
>
> That's incorrect.  As Martin explained, and I mentioned in my replies,
> this issue was resolved back in 2017 and the fix is available starting
> in GNU Make 4.3 and above.
>
> In that release, the OUT_OF_MEMORY() macro has been replaced with an
> out_of_memory() function call, and neither that function nor any
> function it calls will try to allocate memory and so it cannot have the
> same behavior as the older code.
>
> In the current release, out-of-memory failures write a static buffer to
> a file descriptor then exit, without returning or trying to allocate
> more memory.
>
> Here is the relevant code from the current GNU Make 4.4.1 release:
>
> https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c?h=4.4.1#n288
> https://git.savannah.gnu.org/cgit/make.git/tree/src/output.c?h=4.4.1#n532
> https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c?h=4.4.1#n426
>
>
> As an aside, all the versions of GNU Make that end in ".9x" such as the
> ones you refer to above, 4.0.90 and 4.4.0.91, are beta or release
> candidate releases.  They are not fit for production use.  Any release
> which is made available on the https://alpha.gnu.org/gnu/ site is a
> pre-release and should only be used for testing the release.
>
> You should only use releases with non-".9x" versions.  You can find
> these releases at the official site https://ftp.gnu.org/gnu/ and they
> are announced at https://savannah.gnu.org/projects/make/
>
> --
> Paul D. Smith Find some GNU make tips at:
> https://www.gnu.org   http://make.mad-scientist.net
> "Please remain calm...I may be mad, but I am a professional." --Mad
> Scientist
>

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Paul Smith]

On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote:
> May I know if you are planning to propose a fix for it? I checked the
> implementations of other `make` versions a bit further, and as far as
> I can tell, the issue exists from the older make-4.0.90 (2014-9-30)
> to the newest version of make (make-4.4.0.91).

That's incorrect.  As Martin explained, and I mentioned in my replies,
this issue was resolved back in 2017 and the fix is available starting
in GNU Make 4.3 and above.

In that release, the OUT_OF_MEMORY() macro has been replaced with an
out_of_memory() function call, and neither that function nor any
function it calls will try to allocate memory and so it cannot have the
same behavior as the older code.

In the current release, out-of-memory failures write a static buffer to
a file descriptor then exit, without returning or trying to allocate
more memory.

Here is the relevant code from the current GNU Make 4.4.1 release:

https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c?h=4.4.1#n288
https://git.savannah.gnu.org/cgit/make.git/tree/src/output.c?h=4.4.1#n532
https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c?h=4.4.1#n426


As an aside, all the versions of GNU Make that end in ".9x" such as the
ones you refer to above, 4.0.90 and 4.4.0.91, are beta or release
candidate releases.  They are not fit for production use.  Any release
which is made available on the https://alpha.gnu.org/gnu/ site is a
pre-release and should only be used for testing the release.

You should only use releases with non-".9x" versions.  You can find
these releases at the official site https://ftp.gnu.org/gnu/ and they
are announced at https://savannah.gnu.org/projects/make/

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Martin Dorey]

  *   the issue exists ... [in] the newest version

To show that, you'd need to show get_buffer being reentered during the xrealloc 
call.  That code is still as it was:

https://github.com/mirror/make/blob/master/src/output.c#L395

static char * get_buffer (size_t need) {
  if (need > fmtbuf.size) {
  fmtbuf.size += need * 2;
  fmtbuf.buffer = xrealloc (fmtbuf.buffer, fmtbuf.size);

But, if I understand it correctly, the contention is that the code that was 
calling get_buffer when malloc fails during xrealloc was removed in that old 
patch I sent:

https://git.savannah.gnu.org/cgit/make.git/commit/?id=68be4f74fce91b76e5915449268d6b5eb687aab9

It's obfuscated by some macro trickery but I think OUT_OF_MEM used to call 
fatal, which calls get_buffer.  Its replacement, out_of_memory, just writes an 
error message, without any localization, rather puzzlingly to stdout rather 
than stderr, then exits.  The function called fatal is no longer involved.

You could argue that the above code has a latent risk.  You could argue that it 
might be less liable to cause trouble under maintenance if an additional local 
variable were used to hold the new size until xrealloc has returned.  Isn’t 
that gilding a lily?  If it ends up looking like something that could be 
simplified, then a maintainer would benefit from a code-comment warning them 
that we were once bitten by reentry here, at which point the added complexity 
might cause more trouble than it's likely to save us from.


From: bug-make-bounces+martin.dorey=hds@gnu.org 
 on behalf of Haoxin Tu 

Sent: Saturday, January 20, 2024 20:03
To: Martin Dorey 
Cc: psm...@gnu.org ; bug-make@gnu.org 
Subject: Re: [bug #64551] Possible null pointer dereference on the function 
get_buffer

* EXTERNAL EMAIL *
Hi all,

May I know if you are planning to propose a fix for it? I checked the 
implementations of other `make` versions a bit further, and as far as I can 
tell, the issue exists from the older 
make-4.0.90<https://alpha.gnu.org/gnu/make/make-4.0.90.tar.gz> (2014-9-30) to 
the newest version of make 
(make-4.4.0.91<https://alpha.gnu.org/gnu/make/make-4.4.0.91.tar.gz>).

Please kindly let me know if I can help any further. Thank you all so much for 
your time and clarifications again!


Best regards,
Haoxin

Haoxin Tu mailto:haoxi...@gmail.com>> 于2024年1月21日周日 00:10写道：
Hi Paul and Martin,

->We know that OUT_OF_MEM() never returns.  So there's no way this
function can return 0.

I totally agree with you all that the function `xrealloc` itself can never 
return 0.

->It will, as Martin suggests, recurse infinitely (one assumes) because
fatal() calls xrealloc() again, and malloc() will return 0, so it will
call fatal(), which calls xrealloc() again, and malloc will return 0,
so it will call fatal(), etc. etc.--this is what I meant by my
imprecise comment "infinite loop" I should have said "infinite
recursion".

Yeah, I also agree with your explanation here for the normal scenario, but the 
potential error I reported here is the situation:
fatal() calls xrealloc() again, and malloc() will return 0, so it will
call fatal(), which DOES NOT calls xrealloc() again but directly dereferences 
the pointer, then leading to the error.


->There's a nice catch there - where, in that recursive failure, the writing of 
that terminator overflows a buffer that wasn't actually reallocated yet.

Yeah, hope I made my points clear now.

Thank you all so much again.

Best regards,
Haoxin


Martin Dorey 
mailto:martin.do...@hitachivantara.com>> 
于2024年1月21日周日 00:02写道：

  *   the link you provided seems old

Indeed, but that's because, as Paul noted, you're testing code that's even 
older.


  *   `fmtbuf.size`, defined in 
.<https://github.com/mirror/make/blob/4.2/output.c#L593>.., was increased after 
the previous innovation of `get_buffer`), and then the execution of 
`fmtbuf.buffer[need-1] = '\0';`

There's a nice catch there - where, in that recursive failure, the writing of 
that terminator overflows a buffer that wasn't actually reallocated yet.


From: Paul Smith mailto:psm...@gnu.org>>
Sent: Saturday, January 20, 2024 07:51
To: Haoxin Tu mailto:haoxi...@gmail.com>>; Martin Dorey 
mailto:martin.do...@hitachivantara.com>>
Cc: bug-make@gnu.org<mailto:bug-make@gnu.org> 
mailto:bug-make@gnu.org>>
Subject: Re: [bug #64551] Possible null pointer dereference on the function 
get_buffer

* EXTERNAL EMAIL *

On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote:
> But I don't understand why the second invocation of `xrealloc` can
> not return zero, I apologize for any imprecise information I provided
> in the previous emails.

Because of what I said in my original reply:

> the entire point of xrealloc is that it never returns 0.

Look at the implementation of xrealloc():

  void *result = malloc (

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Haoxin Tu]

Hi all,

May I know if you are planning to propose a fix for it? I checked the
implementations of other `make` versions a bit further, and as far as I can
tell, the issue exists from the older make-4.0.90
<https://alpha.gnu.org/gnu/make/make-4.0.90.tar.gz> (2014-9-30) to the
newest version of make (make-4.4.0.91
<https://alpha.gnu.org/gnu/make/make-4.4.0.91.tar.gz>).

Please kindly let me know if I can help any further. Thank you all so much
for your time and clarifications again!


Best regards,
Haoxin

Haoxin Tu  于2024年1月21日周日 00:10写道：

> Hi Paul and Martin,
>
> ->We know that OUT_OF_MEM() never returns.  So there's no way this
> function can return 0.
>
> I totally agree with you all that the function `xrealloc` itself can never
> return 0.
>
> ->It will, as Martin suggests, recurse infinitely (one assumes) because
> fatal() calls xrealloc() again, and malloc() will return 0, so it will
> call fatal(), which calls xrealloc() again, and malloc will return 0,
> so it will call fatal(), etc. etc.--this is what I meant by my
> imprecise comment "infinite loop" I should have said "infinite
> recursion".
>
> Yeah, I also agree with your explanation here for the normal scenario, but
> the potential error I reported here is the situation:
> fatal() calls xrealloc() again, and malloc() will return 0, so it will
> call fatal(), which DOES NOT calls xrealloc() again but directly
> dereferences the pointer, then leading to the error.
>
>
> ->There's a nice catch there - where, in that recursive failure, the
> writing of that terminator overflows a buffer that wasn't actually
> reallocated yet.
>
> Yeah, hope I made my points clear now.
>
> Thank you all so much again.
>
> Best regards,
> Haoxin
>
>
> Martin Dorey  于2024年1月21日周日 00:02写道：
>
>>
>>- the link you provided seems old
>>
>>
>> Indeed, but that's because, as Paul noted, you're testing code that's
>> even older.
>>
>>
>>- `fmtbuf.size`, defined in .
>><https://github.com/mirror/make/blob/4.2/output.c#L593>.., was
>>increased after the previous innovation of `get_buffer`), and then the
>>execution of `fmtbuf.buffer[need-1] = '\0';`
>>
>>
>> There's a nice catch there - where, in that recursive failure, the
>> writing of that terminator overflows a buffer that wasn't actually
>> reallocated yet.
>>
>> ------
>> *From:* Paul Smith 
>> *Sent:* Saturday, January 20, 2024 07:51
>> *To:* Haoxin Tu ; Martin Dorey <
>> martin.do...@hitachivantara.com>
>> *Cc:* bug-make@gnu.org 
>> *Subject:* Re: [bug #64551] Possible null pointer dereference on the
>> function get_buffer
>>
>> * EXTERNAL EMAIL *
>>
>> On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote:
>> > But I don't understand why the second invocation of `xrealloc` can
>> > not return zero, I apologize for any imprecise information I provided
>> > in the previous emails.
>>
>> Because of what I said in my original reply:
>>
>> > the entire point of xrealloc is that it never returns 0.
>>
>> Look at the implementation of xrealloc():
>>
>>   void *result = malloc (size ? size : 1);
>>   if (result == 0)
>> OUT_OF_MEM();
>>   return result;
>>
>> We know that OUT_OF_MEM() never returns.  So there's no way this
>> function can return 0.
>>
>> It will, as Martin suggests, recurse infinitely (one assumes) because
>> fatal() calls xrealloc() again, and malloc() will return 0, so it will
>> call fatal(), which calls xrealloc() again, and malloc will return 0,
>> so it will call fatal(), etc. etc.--this is what I meant by my
>> imprecise comment "infinite loop" I should have said "infinite
>> recursion".
>>
>> As a reminder this is moot: this code has been rewritten and even the
>> infinite recursion problem was removed from the code back in 2017.
>>
>> --
>> Paul D. Smith Find some GNU make tips at:
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2F=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848068646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2CgTubth7nezTPOU76hCwauMdV%2B8cz%2F9415iVpL%2FVe0%3D=0
>> <https://www.gnu.org/>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmake.mad-scientist.net%2F=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848074885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0jGEsG8MYYh26rgSn2n8dPl1eydBrKFvkzD0UqnvbuY%3D=0
>> <http://make.mad-scientist.net/>
>> "Please remain calm...I may be mad, but I am a professional." --Mad
>> Scientist
>>
>

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Haoxin Tu]

Hi Paul and Martin,

->We know that OUT_OF_MEM() never returns.  So there's no way this
function can return 0.

I totally agree with you all that the function `xrealloc` itself can never
return 0.

->It will, as Martin suggests, recurse infinitely (one assumes) because
fatal() calls xrealloc() again, and malloc() will return 0, so it will
call fatal(), which calls xrealloc() again, and malloc will return 0,
so it will call fatal(), etc. etc.--this is what I meant by my
imprecise comment "infinite loop" I should have said "infinite
recursion".

Yeah, I also agree with your explanation here for the normal scenario, but
the potential error I reported here is the situation:
fatal() calls xrealloc() again, and malloc() will return 0, so it will
call fatal(), which DOES NOT calls xrealloc() again but directly
dereferences the pointer, then leading to the error.


->There's a nice catch there - where, in that recursive failure, the
writing of that terminator overflows a buffer that wasn't actually
reallocated yet.

Yeah, hope I made my points clear now.

Thank you all so much again.

Best regards,
Haoxin


Martin Dorey  于2024年1月21日周日 00:02写道：

>
>- the link you provided seems old
>
>
> Indeed, but that's because, as Paul noted, you're testing code that's even
> older.
>
>
>- `fmtbuf.size`, defined in .
><https://github.com/mirror/make/blob/4.2/output.c#L593>.., was
>increased after the previous innovation of `get_buffer`), and then the
>execution of `fmtbuf.buffer[need-1] = '\0';`
>
>
> There's a nice catch there - where, in that recursive failure, the writing
> of that terminator overflows a buffer that wasn't actually reallocated yet.
>
> --
> *From:* Paul Smith 
> *Sent:* Saturday, January 20, 2024 07:51
> *To:* Haoxin Tu ; Martin Dorey <
> martin.do...@hitachivantara.com>
> *Cc:* bug-make@gnu.org 
> *Subject:* Re: [bug #64551] Possible null pointer dereference on the
> function get_buffer
>
> * EXTERNAL EMAIL *
>
> On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote:
> > But I don't understand why the second invocation of `xrealloc` can
> > not return zero, I apologize for any imprecise information I provided
> > in the previous emails.
>
> Because of what I said in my original reply:
>
> > the entire point of xrealloc is that it never returns 0.
>
> Look at the implementation of xrealloc():
>
>   void *result = malloc (size ? size : 1);
>   if (result == 0)
> OUT_OF_MEM();
>   return result;
>
> We know that OUT_OF_MEM() never returns.  So there's no way this
> function can return 0.
>
> It will, as Martin suggests, recurse infinitely (one assumes) because
> fatal() calls xrealloc() again, and malloc() will return 0, so it will
> call fatal(), which calls xrealloc() again, and malloc will return 0,
> so it will call fatal(), etc. etc.--this is what I meant by my
> imprecise comment "infinite loop" I should have said "infinite
> recursion".
>
> As a reminder this is moot: this code has been rewritten and even the
> infinite recursion problem was removed from the code back in 2017.
>
> --
> Paul D. Smith Find some GNU make tips at:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2F=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848068646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2CgTubth7nezTPOU76hCwauMdV%2B8cz%2F9415iVpL%2FVe0%3D=0
> <https://www.gnu.org/>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmake.mad-scientist.net%2F=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848074885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0jGEsG8MYYh26rgSn2n8dPl1eydBrKFvkzD0UqnvbuY%3D=0
> <http://make.mad-scientist.net/>
> "Please remain calm...I may be mad, but I am a professional." --Mad
> Scientist
>

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Martin Dorey]

  *   the link you provided seems old

Indeed, but that's because, as Paul noted, you're testing code that's even 
older.


  *   `fmtbuf.size`, defined in 
.<https://github.com/mirror/make/blob/4.2/output.c#L593>.., was increased after 
the previous innovation of `get_buffer`), and then the execution of 
`fmtbuf.buffer[need-1] = '\0';`

There's a nice catch there - where, in that recursive failure, the writing of 
that terminator overflows a buffer that wasn't actually reallocated yet.


From: Paul Smith 
Sent: Saturday, January 20, 2024 07:51
To: Haoxin Tu ; Martin Dorey 

Cc: bug-make@gnu.org 
Subject: Re: [bug #64551] Possible null pointer dereference on the function 
get_buffer

* EXTERNAL EMAIL *

On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote:
> But I don't understand why the second invocation of `xrealloc` can
> not return zero, I apologize for any imprecise information I provided
> in the previous emails.

Because of what I said in my original reply:

> the entire point of xrealloc is that it never returns 0.

Look at the implementation of xrealloc():

  void *result = malloc (size ? size : 1);
  if (result == 0)
OUT_OF_MEM();
  return result;

We know that OUT_OF_MEM() never returns.  So there's no way this
function can return 0.

It will, as Martin suggests, recurse infinitely (one assumes) because
fatal() calls xrealloc() again, and malloc() will return 0, so it will
call fatal(), which calls xrealloc() again, and malloc will return 0,
so it will call fatal(), etc. etc.--this is what I meant by my
imprecise comment "infinite loop" I should have said "infinite
recursion".

As a reminder this is moot: this code has been rewritten and even the
infinite recursion problem was removed from the code back in 2017.

--
Paul D. Smith Find some GNU make tips at:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2F=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848068646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2CgTubth7nezTPOU76hCwauMdV%2B8cz%2F9415iVpL%2FVe0%3D=0<https://www.gnu.org/>
   
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmake.mad-scientist.net%2F=05%7C02%7CMartin.Dorey%40hitachivantara.com%7C64b0e96f7b7a4d9cf0f308dc19cfa672%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638413626848074885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0jGEsG8MYYh26rgSn2n8dPl1eydBrKFvkzD0UqnvbuY%3D=0<http://make.mad-scientist.net/>
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Paul Smith]

On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote:
> But I don't understand why the second invocation of `xrealloc` can
> not return zero, I apologize for any imprecise information I provided
> in the previous emails.

Because of what I said in my original reply:

> the entire point of xrealloc is that it never returns 0.

Look at the implementation of xrealloc():

  void *result = malloc (size ? size : 1);
  if (result == 0)
OUT_OF_MEM();
  return result;

We know that OUT_OF_MEM() never returns.  So there's no way this
function can return 0.

It will, as Martin suggests, recurse infinitely (one assumes) because
fatal() calls xrealloc() again, and malloc() will return 0, so it will
call fatal(), which calls xrealloc() again, and malloc will return 0,
so it will call fatal(), etc. etc.--this is what I meant by my
imprecise comment "infinite loop" I should have said "infinite
recursion".

As a reminder this is moot: this code has been rewritten and even the
infinite recursion problem was removed from the code back in 2017.

-- 
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Haoxin Tu]

Hi Martin,

Thanks for your speedy reply and clarifications.

But I don't understand why the second invocation of `xrealloc` can not
return zero, I apologize for any imprecise information I provided in the
previous emails.

>From my understanding, once the second the `xrealloc` is invocated, there
is a possibility that the `result` (
https://github.com/mirror/make/blob/4.2/misc.c#L247) can return zero (from
either `realloc` or `malloc`, just like the first invocation of
`xrealloc`). Later, the `OUT_OF_MEM` function will be invocated again, and
then the function `get_buffer`. In the following execution inside the
function `get_buffer`, no `xrealloc` will be called as the condition `need
> fmtbuf.size` (https://github.com/mirror/make/blob/4.2/output.c#L599) is
false (the global static value `fmtbuf.size`, defined in
https://github.com/mirror/make/blob/4.2/output.c#L593, was increased after
the previous innovation of `get_buffer`), and then the execution of
`fmtbuf.buffer[need-1] = '\0';` (
https://github.com/mirror/make/blob/4.2/output.c#L605) leads to the null
pointer dereference. Btw, I am sorry I don't see the recursive execution in
this case (the link you provided seems old and I don't see such
implementation in the version of make-4.2).

Please kindly let me know if I misunderstand something. Thank you so much
for your time again!

Best regards,
Haoxin

Martin Dorey  于2024年1月20日周六 22:43写道：

>
>- once the second invocation of `xrealloc` ... returns zero
>
>
> But it doesn't, it just recurses, calls get_buffer again, again likely
> fails and recurses still further until the stack is blown.  Or it did until
> https://git.savannah.gnu.org/cgit/make.git/commit/?id=68be4f74fce91b76e5915449268d6b5eb687aab9
> .
>
> --
> *From:* bug-make-bounces+martin.dorey=hds@gnu.org
>  on behalf of Haoxin Tu <
> haoxi...@gmail.com>
> *Sent:* Saturday, January 20, 2024 06:17
> *To:* Paul D. Smith 
> *Cc:* Paul D. Smith ; bo...@kolpackov.net <
> bo...@kolpackov.net>; bug-make@gnu.org 
> *Subject:* Re: [bug #64551] Possible null pointer dereference on the
> function get_buffer
>
> * EXTERNAL EMAIL *
> Hi,
>
> Thank you so much for your time and reply.
>
> We understand that the entire point of `xrealloc` is never returning 0 to
> client users/developers who use this function. However, the issue we
> reported here happens when the `xrealloc` internally handles the returned 0
> from `realloc` or `malloc` functions.
>
> In general, the key point is that the function `OUT_OF_MEM()` (invoked
> when the `result` gets a 0 in the implementation of `xrealloc`) does not
> immediately terminate the program execution, and the function
> `OUT_OF_MEM()` will continue to allocate buffers via `xrealloc` for
> printing purposes in the following and then terminate. Specifically, the
> continuous execution of function `OUT_OF_MEM()` calls the `xrealloc` again
> through the `get_buffer` function (`OUT_OF_MEM()` is a macro definition
> that will call the function `fatal`, which finally invocates the function
> `get_buffer`). As we mentioned in the initial report, once the second
> invocation of `xrealloc` (i.e., the one called inside `OUT_OF_MEM()`)
> returns zero and calls `OUT_OF_MEM()` again, a null pointer dereference is
> occurred in `fmtbuf.buffer[need-1] = '\0';` in the function `get_buffer`.
>
> Please kindly check my explanation above and correct me if I am wrong.
> Thank you so much again and looking forward to hearing from you back again.
>
>
> Best regards,
> Haoxin
>
> Paul D. Smith  于2024年1月7日周日 01:49写道：
>
>> Update of bug#64551 (group make):
>>
>>   Status:None => Duplicate
>>
>>  Assigned to:None => psmith
>>
>>  Open/Closed:Open => Closed
>>
>>
>> ___
>>
>> Follow-up Comment #1:
>>
>> I don't see how the "second" xrealloc() would return 0; the entire point
>> of
>> xrealloc is that it never returns 0.
>>
>> However, I can see where the behavior of the code might lead to an
>> infinite
>> loop.
>>
>> This issue was already addressed in GNU Make 4.3 via bug #13651
>> The version you're testing (4.2) was released in 2016.
>>
>> It's certainly helpful to check for errors in tools like GNU Make but
>> please
>> check either the most recent published version or, even better, the
>> current
>> Git HEAD version.
>>
>> Thanks!
>>
>>
>> ___
>>
>> Reply to this item at:
>>
>>   <https://savannah.gnu.org/bugs/?64551>
>>
>> ___
>> Message sent via Savannah
>> https://savannah.gnu.org/
>>
>>

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Martin Dorey]

  *   once the second invocation of `xrealloc` ... returns zero

But it doesn't, it just recurses, calls get_buffer again, again likely fails 
and recurses still further until the stack is blown.  Or it did until 
https://git.savannah.gnu.org/cgit/make.git/commit/?id=68be4f74fce91b76e5915449268d6b5eb687aab9.


From: bug-make-bounces+martin.dorey=hds@gnu.org 
 on behalf of Haoxin Tu 

Sent: Saturday, January 20, 2024 06:17
To: Paul D. Smith 
Cc: Paul D. Smith ; bo...@kolpackov.net ; 
bug-make@gnu.org 
Subject: Re: [bug #64551] Possible null pointer dereference on the function 
get_buffer

* EXTERNAL EMAIL *
Hi,

Thank you so much for your time and reply.

We understand that the entire point of `xrealloc` is never returning 0 to 
client users/developers who use this function. However, the issue we reported 
here happens when the `xrealloc` internally handles the returned 0 from 
`realloc` or `malloc` functions.

In general, the key point is that the function `OUT_OF_MEM()` (invoked when the 
`result` gets a 0 in the implementation of `xrealloc`) does not immediately 
terminate the program execution, and the function `OUT_OF_MEM()` will continue 
to allocate buffers via `xrealloc` for printing purposes in the following and 
then terminate. Specifically, the continuous execution of function 
`OUT_OF_MEM()` calls the `xrealloc` again through the `get_buffer` function 
(`OUT_OF_MEM()` is a macro definition that will call the function `fatal`, 
which finally invocates the function `get_buffer`). As we mentioned in the 
initial report, once the second invocation of `xrealloc` (i.e., the one called 
inside `OUT_OF_MEM()`) returns zero and calls `OUT_OF_MEM()` again, a null 
pointer dereference is occurred in `fmtbuf.buffer[need-1] = '\0';` in the 
function `get_buffer`.

Please kindly check my explanation above and correct me if I am wrong. Thank 
you so much again and looking forward to hearing from you back again.


Best regards,
Haoxin

Paul D. Smith mailto:invalid.nore...@gnu.org>> 
于2024年1月7日周日 01:49写道：
Update of bug#64551 (group make):

  Status:None => Duplicate
 Assigned to:None => psmith
 Open/Closed:Open => Closed

___

Follow-up Comment #1:

I don't see how the "second" xrealloc() would return 0; the entire point of
xrealloc is that it never returns 0.

However, I can see where the behavior of the code might lead to an infinite
loop.

This issue was already addressed in GNU Make 4.3 via bug #13651
The version you're testing (4.2) was released in 2016.

It's certainly helpful to check for errors in tools like GNU Make but please
check either the most recent published version or, even better, the current
Git HEAD version.

Thanks!


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64551>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [bug #64551] Possible null pointer dereference on the function get_buffer

[Haoxin Tu]

Hi,

Thank you so much for your time and reply.

We understand that the entire point of `xrealloc` is never returning 0 to
client users/developers who use this function. However, the issue we
reported here happens when the `xrealloc` internally handles the returned 0
from `realloc` or `malloc` functions.

In general, the key point is that the function `OUT_OF_MEM()` (invoked when
the `result` gets a 0 in the implementation of `xrealloc`) does not
immediately terminate the program execution, and the function
`OUT_OF_MEM()` will continue to allocate buffers via `xrealloc` for
printing purposes in the following and then terminate. Specifically, the
continuous execution of function `OUT_OF_MEM()` calls the `xrealloc` again
through the `get_buffer` function (`OUT_OF_MEM()` is a macro definition
that will call the function `fatal`, which finally invocates the function
`get_buffer`). As we mentioned in the initial report, once the second
invocation of `xrealloc` (i.e., the one called inside `OUT_OF_MEM()`)
returns zero and calls `OUT_OF_MEM()` again, a null pointer dereference is
occurred in `fmtbuf.buffer[need-1] = '\0';` in the function `get_buffer`.

Please kindly check my explanation above and correct me if I am wrong.
Thank you so much again and looking forward to hearing from you back again.


Best regards,
Haoxin

Paul D. Smith  于2024年1月7日周日 01:49写道：

> Update of bug#64551 (group make):
>
>   Status:None => Duplicate
>
>  Assigned to:None => psmith
>
>  Open/Closed:Open => Closed
>
>
> ___
>
> Follow-up Comment #1:
>
> I don't see how the "second" xrealloc() would return 0; the entire point of
> xrealloc is that it never returns 0.
>
> However, I can see where the behavior of the code might lead to an infinite
> loop.
>
> This issue was already addressed in GNU Make 4.3 via bug #13651
> The version you're testing (4.2) was released in 2016.
>
> It's certainly helpful to check for errors in tools like GNU Make but
> please
> check either the most recent published version or, even better, the current
> Git HEAD version.
>
> Thanks!
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
> Message sent via Savannah
> https://savannah.gnu.org/
>
>