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)

2 files changed, 14 insertions, 1 deletions

diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index 0c7a8ad52..b6d5067ec 100644
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -184,8 +184,10 @@ PP/05 Fix security issue CVE-2020-PFPSN and guard against cmdline invoker
       providing a particularly obnoxious sender full name.
       Reported by Qualys.
 
-pp/06 Fix CVE-2020-28016 (PFPZA): Heap out-of-bounds write in parse_fix_phrase()
+PP/06 Fix CVE-2020-28016 (PFPZA): Heap out-of-bounds write in parse_fix_phrase()
 
+PP/07 Refuse to allocate too little memory, block negative/zero allocations.
+      Security guard.
 
 
 Exim version 4.94
diff --git a/src/src/store.c b/src/src/store.c
index 7d08c9804..90da012fb 100644
--- a/src/src/store.c
+++ b/src/src/store.c
@@ -233,6 +233,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