[Bug libstdc++/47921] New: pbump will overflow when input n is larger than 2G-1

[Bug libstdc++/47921] New: pbump will overflow when input n is larger than 2G-1

[RobertPython at 163 dot com]

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

           Summary: pbump will overflow when input n is larger than 2G-1
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: RobertPython@163.com
            Target: x86_64-redhat-linux
             Build: gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)


in function int basic_streambuf::pbump(int n), n is a int which is easily
overflow in 64bit environment, especially when it is called in overflow
function.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[RobertPython at 163 dot com]

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

--- Comment #1 from Robert Python <RobertPython at 163 dot com> 2011-02-28 10:51:30 UTC ---
try below program in a 64bit environment with about 8G memory:

#include <string>
#include <strstream>
#include <iostream>

#define N 100000000
#define SIZE 40

using namespace std;

int main()
{
        const char msg[SIZE] = "aaaaaaaaaaaaaaaaaaaaaaaaaaa";
        strstreambuf *new_data = new strstreambuf();
        for (int i = 0; i < N; ++i)
        {
                new_data->freeze(false);
                new_data->sputn(msg, SIZE);
        }

        delete new_data;
        return 0;
}

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID
           Severity|critical                    |normal

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-02-28 11:13:55 UTC ---
Yes, but there is nothing we can do as libstdc++ project, this is the ISO
Standard: see 27.5.2.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-02-28 12:36:28 UTC ---
We can't change the signature of pbump, but that doesn't mean we have to call
it with values that cause overflow. Could we add a safe_pbump(streamsize n)
which calls pbump in a loop so it doesn't call it with a value outside the
range of an int?

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-02-28 12:43:41 UTC ---
something like this (untested)

--- include/std/streambuf.orig  2011-02-28 12:40:44.559350898 +0000
+++ include/std/streambuf       2011-02-28 12:32:20.445685621 +0000
@@ -38,6 +38,7 @@

 #include <bits/c++config.h>
 #include <iosfwd>
+#include <limits>
 #include <bits/localefwd.h>
 #include <bits/ios_base.h>
 #include <bits/cpp_type_traits.h>
--- include/bits/streambuf.tcc.orig     2011-02-28 12:40:35.554301020 +0000
+++ include/bits/streambuf.tcc  2011-02-28 12:42:30.761788519 +0000
@@ -91,6 +91,11 @@
              traits_type::copy(this->pptr(), __s, __len);
              __ret += __len;
              __s += __len;
+             while (__len > std::numeric_limits<int>::max())
+               {
+                 this->pbump(std::numeric_limits<int>::max());
+                 __len -= std::numeric_limits<int>::max();
+               }
              this->pbump(__len);
            }

--- src/strstream.cc.orig       2011-02-28 12:40:25.373244770 +0000
+++ src/strstream.cc    2011-02-28 12:42:10.945712166 +0000
@@ -161,6 +161,11 @@
              }

            setp(buf, buf + new_size);
+           while (old_size > INT_MAX)
+           {
+             this->pbump(INT_MAX);
+             old_size -= INT_MAX;
+           }
            pbump(old_size);

            if (reposition_get)

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot
                   |                            |com

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-02-28 13:01:16 UTC ---
This is a different issue. Anyway, concentrating on basic_streambuf<>::xsputn
(I don't think we should fiddle that late with the deprecated strstream), note
that __len is smaller than __buf_len, and typically __buf_len ~= 8192. Thus I
would consider the problem rather minor. Anyway, I'm in favor of something like
your first hunk, with a comment before about streamsize == ptrdiff_t, and using
__gnu_cxx::__numeric_traits<int>::__max instead (thus avoiding bringing in the
whole <limits>).

Probably we used to be not careful enough in xsputn because streamsize is (was)
normally 32 bits on 32-bit machines (being ptrdiff_t).

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2011.02.28 13:09:00
         Resolution|INVALID                     |
         AssignedTo|unassigned at gcc dot       |paolo.carlini at oracle dot
                   |gnu.org                     |com
     Ever Confirmed|0                           |1

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-02-28 13:09:00 UTC ---
Ok, let me handle this, we have another couple unsafe on 64-bit uses in
sstream.tcc. Note, in general we can't rely on additional member functions
being available in basic_streambuf, can be specialized.

[Bug libstdc++/47921] pbump will overflow when input n is larger than 2G-1

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-02-28 14:11:39 UTC ---
Actually, fixing strstream too is easy, because it derives from
basic_streambuf<char>, which can be assumed to have __safe_pbump