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 b18dc269577194689af4387fb778d2611d9b7c9d..33bdb4108dc3b8145febea033c20ad65d0d60df6 100644 (file)
--- 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)
     {