From: Kevin McCarthy <kevin@8t8.us>
Date: Mon, 22 May 2017 01:45:08 +0000 (-0700)
Subject: Small imap fetch fixes. (see #3942)
X-Git-Tag: neomutt-20170707^2^2~39
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=cefc030cb3c1606896030c12fc194be914dfbed7;p=neomutt

Small imap fetch fixes. (see #3942)

Add an integer overflow test, pulled from mx_alloc_memory(), since the
count comes from a potentially hostile server.

After reviewing the RFC a bit, it turns out the server is not supposed
to send EXPUNGE responses during a FETCH.  Change the comment, but
keep the conservative code.
---

diff --git a/imap/message.c b/imap/message.c
index b18dc2695..33bdb4108 100644
--- a/imap/message.c
+++ b/imap/message.c
@@ -79,6 +79,13 @@ static void imap_alloc_msn_index (IMAP_DATA *idata, unsigned int msn_count)
   /* Add a little padding, like mx_allloc_memory() */
   new_size = msn_count + 25;
 
+  if (new_size * sizeof (HEADER *) < idata->msn_index_size * sizeof (HEADER *))
+  {
+    mutt_error _("Integer overflow -- can't allocate memory.");
+    sleep (1);
+    mutt_exit (1);
+  }
+
   if (!idata->msn_index)
     idata->msn_index = safe_calloc (new_size, sizeof (HEADER *));
   else
@@ -394,9 +401,9 @@ int imap_read_headers (IMAP_DATA* idata, unsigned int msn_begin, unsigned int ms
 
     /* In case we get new mail while fetching the headers.
      *
-     * Note: it is possible to handle EXPUNGE responses while pulling
-     * down the headers.  Therefore, we need to use the current state
-     * of max_msn, not fetch_msn_end to set the start range.
+     * Note: The RFC says we shouldn't get any EXPUNGE responses in the
+     * middle of a FETCH.  But just to be cautious, use the current state
+     * of max_msn, not fetch_msn_end to set the next start range.
      */
     if (idata->reopen & IMAP_NEWMAIL_PENDING)
     {