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 7907e6d3923494db3e3d92472c045589de966126..d11968d48cd8b2a4435631ab57c90b6c2963a9f7 100644 (file)
--- a/imap/message.c
+++ b/imap/message.c
@@ -384,6 +384,13 @@ static void imap_alloc_msn_index(struct ImapData *idata, unsigned int msn_count)
   /* Add a little padding, like mx_allloc_memory() */
   new_size = msn_count + 25;
 
+  if (new_size * sizeof(struct Header *) < idata->msn_index_size * sizeof(struct 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(struct Header *));
   else
@@ -701,9 +708,9 @@ int imap_read_headers(struct ImapData *idata, unsigned int msn_begin, unsigned i
 
     /* 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)
     {