TCMalloc: restrict maximum size of memory ranges

base/security_unittest.cc

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include <limits>
+
+#include "base/memory/scoped_ptr.h"
+#include "testing/gtest/include/gtest/gtest.h"
+
+namespace {
+
+// TODO(jln): list instead the known cases that fail (ASAN etc), so that
+// we can positively check that we support the cases we care about.
+#if !defined(NO_TCMALLOC) && !defined(ADDRESS_SANITIZER)
+  #define MAYBE_MemoryAllocationRestrictions AllocationRestrictions
+#else
+  #define MAYBE_MemoryAllocationRestrictions DISABLED_AllocationRestrictions
+#endif
+
+// Check that we can not allocate a continuous space that cannot be indexed
+// via an int. This is used to mitigate vulnerabilities in libraries that use
+// int instead of size_t.
+// See crbug.com/169327.
+TEST(SecurityTest, MAYBE_MemoryAllocationRestrictions) {
+  scoped_ptr<char, base::FreeDeleter>
+      ptr(static_cast<char*>(malloc((std::numeric_limits<int>::max)())));

[Chris Evans, 2013/01/11 19:51:51]

Isn't it jusr std::numeric_limits<int>::max() ?
Too many parens! Confusing :P

[jln (very slow on Chromium), 2013/01/11 20:02:04]

That's because of Windows. Windows defines a macro called max() which breaks
compilation.

+  ASSERT_TRUE(ptr == NULL);

[Chris Evans, 2013/01/11 19:17:28]

The behaviour of tcmalloc within Chromium is to abort on an allocation failure.
It's an important security guarantee.

Does this test imply that this CL changes that invariant?

[jln (very slow on Chromium), 2013/01/11 20:02:04]

No, as discussed on the thread (I suspect this comment was re-sent
inadvertently.

+  // TODO(jln): a lot more tests here.
+}
+
+}  // namespace