From 117a375f8f5f0b98082e5fffffb7656318c87196 Mon Sep 17 00:00:00 2001 From: Kevin McCarthy Date: Sun, 21 May 2017 18:45:08 -0700 Subject: [PATCH] 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. --- imap/message.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/imap/message.c b/imap/message.c index b18dc269..33bdb410 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) { -- 2.40.0