[exim-cvs] SECURITY: refuse too small store allocations

Inizio della pagina
Delete this message
Reply to this message
Autore: Exim Git Commits Mailing List
Data:  
To: exim-cvs
Oggetto: [exim-cvs] SECURITY: refuse too small store allocations
Gitweb: https://git.exim.org/exim.git/commitdiff/15282ddb92382fb203e61d7a66f37aa2fbdebb82
Commit:     15282ddb92382fb203e61d7a66f37aa2fbdebb82
Parent:     bafc62583bc4ded96e3a66d2fb98c9d7afaa8768
Author:     Phil Pennock <phil+git@???>
AuthorDate: Thu Oct 29 20:49:49 2020 -0400
Committer:  Heiko Schlittermann (HS12-RIPE) <hs@???>
CommitDate: Thu May 27 21:30:27 2021 +0200


    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)
---
 doc/doc-txt/ChangeLog |  4 +++-
 src/src/store.c       | 11 +++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)


diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index 95b95e7..5a9c8f2 100644
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -273,8 +273,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 22615ea..b5115fa 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