SECURITY: refuse too small store allocations
authorPhil Pennock <phil+git@pennock-tech.com>
Fri, 30 Oct 2020 00:49:49 +0000 (20:49 -0400)
committerHeiko Schlittermann (HS12-RIPE) <hs@schlittermann.de>
Tue, 27 Apr 2021 22:40:21 +0000 (00:40 +0200)
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)

doc/doc-txt/ChangeLog
src/src/store.c

index 0c7a8ad528212b45b4d6a2044821cb8c3c16a269..b6d5067ec19610af3c0b4875048c7cdfbb4af962 100644 (file)
@@ -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
index 7d08c9804fb350a1a8780c5cb07aa8f412334734..90da012fb1f7f62066db693e750d0106dd6c231f 100644 (file)
@@ -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