bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Haoxin Tu
Subject: Re: [bug #64551] Possible null pointer dereference on the function get_buffer
Date: Sun, 21 Jan 2024 00:10:47 +0800

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 <Martin.Dorey@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 ..., 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 <psmith@gnu.org>
Sent: Saturday, January 20, 2024 07:51
To: Haoxin Tu <haoxintu@gmail.com>; Martin Dorey <Martin.Dorey@hitachivantara.com>
Cc: bug-make@gnu.org <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 <psmith@gnu.org>            Find some GNU make tips at:
https://nam04.safelinks.protection.outlook.com/?url="">                       https://nam04.safelinks.protection.outlook.com/?url="">
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

reply via email to

[Prev in Thread] Current Thread [Next in Thread]