Let rtl_[u]stringbuffer_insert throw std::bad_alloc on overflow

Prior to a95c585433246813096e8890b7ed6ef4fe30c621 "Pump XInputStream into an
SvMemoryStream rather than an OStringBuffer", this change would have caused

> $ truncate -s 3G test.xml
> $ instdir/program/soffice test.xml

to open an effectively empty draw document (after apparently catching the
std::bad_alloc now thrown from within OrcusFormatDetect::detect; see that
commit's commit message for details) rather than crashing.  This works because
rtl_[u]stringbuffer_insert happen not to be decorated with SAL_THROW_EXTERN_C().
But even if they were (or when they are called from an external C program), it
wouldn't be worse to let the process terminate due to the unexpected C++
std::bad_alloc exception than to let it crash due to an overflown signed integer
computation and out-of-bounds memory write.

Change-Id: I21e353367e2b978e8893a2886ac875367a75abd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136352
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 4 insertions, 0 deletions

diff --git a/sal/rtl/strtmpl.hxx b/sal/rtl/strtmpl.hxx
index e1389ce6ad1b..eb9371219178 100644
--- a/sal/rtl/strtmpl.hxx
+++ b/sal/rtl/strtmpl.hxx
@@ -26,6 +26,7 @@
 #include <cstring>
 #include <cwchar>
 #include <limits>
+#include <new>
 #include <string_view>
 #include <type_traits>
 #include <utility>
@@ -1405,6 +1406,9 @@ void stringbuffer_insert(IMPL_RTL_STRINGDATA** ppThis, sal_Int32* capacity, sal_
     assert(len >= 0);
     if (len == 0)
         return;
+    if (len > std::numeric_limits<sal_Int32>::max() - (*ppThis)->length) {
+        throw std::bad_alloc();
+    }
 
     stringbuffer_ensureCapacity(ppThis, capacity, (*ppThis)->length + len);