SECURITY: refuse too small store allocations

Negative sizes are definitely bad.
Optimistically, I'm saying that zero is bad too.  But perhaps we have something
doing that, expecting to be able to grow.  In which case we'll have to amend
this.

(cherry picked from commit 1c9afcec0043e2fb72607b2addb0613763705549)
(cherry picked from commit 6f5d7e5af8eff688c36f81334e4f063689561963)

1 files changed, 11 insertions, 0 deletions

diff --git a/src/src/store.c b/src/src/store.c
index 22615ea08..b5115fa13 100644
--- a/src/src/store.c
+++ b/src/src/store.c
@@ -268,6 +268,17 @@ store_get_3(int size, BOOL tainted, const char *func, int linenumber)
 {
 int pool = tainted ? store_pool + POOL_TAINT_BASE : store_pool;
 
+/* Ensure we've been asked to allocate memory.
+A negative size is a sign of a security problem.
+A zero size is also suspect (but we might have to allow it if we find our API
+expects it in some places). */
+if (size < 1)
+  {
+  log_write(0, LOG_MAIN|LOG_PANIC_DIE,
+            "bad memory allocation requested (%d bytes) at %s %d",
+            size, func, linenumber);
+  }
+
 /* Round up the size to a multiple of the alignment. Although this looks a
 messy statement, because "alignment" is a constant expression, the compiler can
 do a reasonable job of optimizing, especially if the value of "alignment" is a