From ab627d300d0346d1f55b15687b56bdd8df3e2116 Mon Sep 17 00:00:00 2001
From: Stephan Bergmann <sbergman@redhat.com>
Date: Thu, 23 Jun 2022 22:36:49 +0200
Subject: 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>
---
 sal/rtl/strtmpl.hxx | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'sal')

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);
 
-- 
cgit