[Bug malloc/14483] New: obstack uses int for allocation sizes

[Bug malloc/14483] New: obstack uses int for allocation sizes

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14483

             Bug #: 14483
           Summary: obstack uses int for allocation sizes
           Product: glibc
           Version: 2.16
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: jsm28@gcc.gnu.org
    Classification: Unclassified


The obstack code uses int throughout as a type to store and return sizes of
memory allocations.  It should use size_t to avoid arbitrary limits on the size
of objects (or incorrect returns in the case of obstack_memory_used).

I don't know offhand if fixing this will require new symbol versions for
obstack functions and a change to _GNU_OBSTACK_INTERFACE_VERSION.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14483

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-09 16:52:00 UTC ---
The obstack interface was last incompatibly changed in 2006 when Paul Eggert's
alignment changes were merged.  _GNU_OBSTACK_INTERFACE_VERSION should be
abandoned completely.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neleai at seznam dot cz
           Severity|normal                      |enhancement

--- Comment #2 from Ondrej Bilka <neleai at seznam dot cz> ---
Returning a stack sie as size_t could be feasible. However extending arguments
from ints is nonsense, obstack is used for quick allocation of lot of small
objects. You can have only few large objects until you run out of memory, Also
returning huge chunks of memory to system looks better than keeping them in
obstack.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |amodra at gmail dot com
           Assignee|unassigned at sourceware dot org   |amodra at gmail dot com

--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Using int for sizes in the current obstack code is also a security breach, a
buffer overflow on steroids.  A default buffer of around 4k is seen as
sufficiently large to write a 2G+ object..  This is true for both 32-bit and
64-bit targets.

See https://sourceware.org/bugzilla/show_bug.cgi?id=17133

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Alan Modra from comment #3)
> Using int for sizes in the current obstack code is also a security breach, a
> buffer overflow on steroids.  A default buffer of around 4k is seen as
> sufficiently large to write a 2G+ object..  This is true for both 32-bit and
> 64-bit targets.
> 
> See https://sourceware.org/bugzilla/show_bug.cgi?id=17133

I think this is a bug in the caller, not in obstack.  But it's an easy mistake
to make, and I consider the use of int for memory region sizes to be bad
practice which should be avoided.  Unfortunately, it's difficult to change
legacy APIs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://sourceware.org/ml/l
                   |                            |ibc-alpha/2014-10/msg00683.
                   |                            |html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/14483] obstack uses int for allocation sizes

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14483

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|amodra at gmail dot com            |

-- 
You are receiving this mail because:
You are on the CC list for the bug.