public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/19351] New: operator new[] can return heap blocks which are too small
@ 2005-01-09 22:18 fw at deneb dot enyo dot de
  2005-01-09 22:25 ` [Bug c++/19351] " pinskia at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: fw at deneb dot enyo dot de @ 2005-01-09 22:18 UTC (permalink / raw)
  To: gcc-bugs

operator new[] sometimes returns pointers to heap blocks which are too small. 
When a new array is allocated, the C++ run-time has to calculate its size.  The
product may exceed the maximum value which can be stored in a machine register.
 This error is ignored, and the truncated value is used for the heap allocation.

This may lead to heap overflows and therefore security bugs.  (See
http://cert.uni-stuttgart.de/advisories/calloc.php for further references.)

The test case below uses a user-defined operator new[] to test for the presence
of this problem.  However, the problem itself occurs also with the default
operator new[], but it is probably harder to write a portable test case.

#include <testsuite_hooks.h>

struct foo
{
  char data[16];
  void* operator new[] (size_t size)
  {
    VERIFY(size != sizeof(foo));
    VERIFY (false);
    return malloc(size);
  }
};

int
main()
{
  size_t size = size_t (-1) / sizeof(foo) + 2;
  try
    {
      foo* f = new foo[size];
      VERIFY (f == 0);
      VERIFY (false);
    }
  catch(std::bad_alloc&)
    {
      return 0;
    }
}

-- 
           Summary: operator new[] can return heap blocks which are too
                    small
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fw at deneb dot enyo dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
@ 2005-01-09 22:25 ` pinskia at gcc dot gnu dot org
  2005-01-09 22:35 ` fw at deneb dot enyo dot de
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-09 22:25 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 22:25 -------
This is undefined behavor. 

Really there is nothing we can do, just think about this again, the programmer should catch this when 
they read in the length.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
  2005-01-09 22:25 ` [Bug c++/19351] " pinskia at gcc dot gnu dot org
@ 2005-01-09 22:35 ` fw at deneb dot enyo dot de
  2005-01-09 22:45 ` pinskia at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: fw at deneb dot enyo dot de @ 2005-01-09 22:35 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From fw at deneb dot enyo dot de  2005-01-09 22:35 -------
Why is this undefined behavior?  Would you quote chapter and verse, please?

GCC's behavior violates 5.3.4(10):

"A new-expression passes the amount of space requested to the allocation
function as the first argument of type std::size_t.  That argument shall be no
less than the size of the object being created; [...]"

In this case, the passed value is 16, which is much smaller than the size of the
array.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
  2005-01-09 22:25 ` [Bug c++/19351] " pinskia at gcc dot gnu dot org
  2005-01-09 22:35 ` fw at deneb dot enyo dot de
@ 2005-01-09 22:45 ` pinskia at gcc dot gnu dot org
  2005-01-09 22:47 ` pinskia at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-09 22:45 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 22:45 -------
But the C++ standard does not say anything about this case.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
                   ` (2 preceding siblings ...)
  2005-01-09 22:45 ` pinskia at gcc dot gnu dot org
@ 2005-01-09 22:47 ` pinskia at gcc dot gnu dot org
  2005-01-09 22:48 ` bangerth at dealii dot org
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-09 22:47 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 22:47 -------
I would get a clearification from the standards comittee if I were you.  multiplying a large unsigned 
number by 16 and getting an overflow is werid case but again, the developer should be checking the 
size for reality, if they don't it can cause other problems like a seg fault as malloc on linux does not 
return null when running out of memory.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
                   ` (3 preceding siblings ...)
  2005-01-09 22:47 ` pinskia at gcc dot gnu dot org
@ 2005-01-09 22:48 ` bangerth at dealii dot org
  2005-01-09 23:07 ` fw at deneb dot enyo dot de
  2005-01-09 23:12 ` pinskia at gcc dot gnu dot org
  6 siblings, 0 replies; 8+ messages in thread
From: bangerth at dealii dot org @ 2005-01-09 22:48 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From bangerth at dealii dot org  2005-01-09 22:48 -------
I also wonder what the semantics are that you are expecting? I mean,  
you try to allocate an array that is so large that you can't address  
the individual bytes using a size_t, in other words one that is larger   
than the address space the OS provides to your program. That clearly  
doesn't make any sense.  
  
That being said, I understand that the behavior of this is security  
relevant and that any attempt to allocate more memory than is available  
will necessarily have to fail. Thus, our present implementation isn't  
standards conforming, since it returns a reasonable pointer even in  
the case that the allocation should have failed. I would therefore agree  
that this is a problem, and given that memory allocation is an expensive  
operation, one overflow check isn't really time critical.  
  
Unfortunately, the situation is not restricted to libstdc++'s implementation  
of operator new[], since that operator only gets the total size of  
the memory to be allocation, not the size per element and the number of  
elements. Therefore, by the time we get into the implementation of this  
operator, it is already too late. In other words, the overflow check has  
to happen in compiler-generated code, not in the libstdc++ implementation.  
  
I would support the introduction of such code, if necessary guarded by  
some flag, or unconditionally, as a matter of quality of implemetation.  
  
W.  

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-09 22:48:34
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
                   ` (4 preceding siblings ...)
  2005-01-09 22:48 ` bangerth at dealii dot org
@ 2005-01-09 23:07 ` fw at deneb dot enyo dot de
  2005-01-09 23:12 ` pinskia at gcc dot gnu dot org
  6 siblings, 0 replies; 8+ messages in thread
From: fw at deneb dot enyo dot de @ 2005-01-09 23:07 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From fw at deneb dot enyo dot de  2005-01-09 23:07 -------
There's no multiplication in the source code.  The multiplication is an
implementation detail.  You can hardly use it to justify the semantics of the
operation.

I would expect that std::bad_alloc is thrown.  But I agree that the C++ standard
isn't very clear in this area.  The implementation must ensure that the
postcondition in 5.3.4(10) holds, but the standard doesn't provide a means to
signal failure.  I'm going to post a note to comp.std.c++ on this matter, but
hopefully this will be fixed in GCC as a quality of implementation issue.

The necessary overflow check is should be very cheap because the multiplication
is always by a constant.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/19351] operator new[] can return heap blocks which are too small
  2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
                   ` (5 preceding siblings ...)
  2005-01-09 23:07 ` fw at deneb dot enyo dot de
@ 2005-01-09 23:12 ` pinskia at gcc dot gnu dot org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-09 23:12 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 23:11 -------
(In reply to comment #6)
> There's no multiplication in the source code.  The multiplication is an
> implementation detail.  You can hardly use it to justify the semantics of the
> operation.

Actually the multiplication is not an implementation detail.
The standard says what opator new[] should be passed, just the multiplication is included.
sizeof(int[i]) (well if it was valid C++, it is valid C99) is defined as a multiplication so it is not an 
implemenation detail.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-01-09 23:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-09 22:18 [Bug c++/19351] New: operator new[] can return heap blocks which are too small fw at deneb dot enyo dot de
2005-01-09 22:25 ` [Bug c++/19351] " pinskia at gcc dot gnu dot org
2005-01-09 22:35 ` fw at deneb dot enyo dot de
2005-01-09 22:45 ` pinskia at gcc dot gnu dot org
2005-01-09 22:47 ` pinskia at gcc dot gnu dot org
2005-01-09 22:48 ` bangerth at dealii dot org
2005-01-09 23:07 ` fw at deneb dot enyo dot de
2005-01-09 23:12 ` pinskia at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).