Hi,

I would like to report an issue which is 100% reproducible with a specific mail available in the reproducer attached to Red Hat's bugzilla (https://bugzilla.redhat.com/attachment.cgi?id=1726535):

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Return-Path: <XXXXXXXXX@XXXXXXX.XXX.XX>
X-Original-To: XXXXXXXXX@XXXXXXX.XXX.XX
Delivered-To: XXXXXXXXXXXXXXXX@XXXXXX.XX.XXX.XX
Received: from XXXXXXXXXXXXXXXXX.XXXXX.XX.XX (unknown [XX.XX.XXX.XXX])
	by XXXXXX.XX.XXX.XX (Postfix) with ESMTP id XXXXXXXXXXX
	for <XXXXXXXXX@XXXXXXX.XXX.XX>; Thu, 15 Oct 2020 23:11:45 +0200 (CEST)
Date: Thu, 15 Oct 2020 23:11:42 +0200
Subject: zoom
Message-ID: <XXXXXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXXXX@XXXXX.XXXXXXX.XXX>
From: "XXXXXXXXX@XXXXXXX.XXX.XX" <XXXXXXXXX@XXXXXXX.XXX.XX>
To: XXXXXXXXX@XXXXXXX.XXX.XX
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64


-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The email seems completely valid to me, but I'm no email expert.

When performing a "FETCH <ID> (BINARY.SIZE[1] BINARY.PEEK[1])" operation, imap crashes with following backtrace:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
(gdb) bt
[...]
#5  0x00007ffff7707a25 in i_panic (
    format=format@entry=0x7ffff7b7b460 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:523
#6  0x00007ffff7ab5de7 in blocks_count_lines (full_input=0x5555557f1230, ctx=0x7fffffffdb80)
    at index-mail-binary.c:357
#7  index_mail_read_binary_to_cache (_mail=0x5555557e3b48, part=0x5555557e4678, include_hdr=<optimized out>, 
    reason=<optimized out>, binary_r=0x7fffffffdc16, converted_r=0x7fffffffdc17) at index-mail-binary.c:395
#8  0x00007ffff7b39c8b in index_mail_get_binary_size (lines_r=0x7fffffffdcc4, size_r=0x7fffffffdd20, 
    include_hdr=false, part=0x5555557e4678, _mail=0x5555557e3b48) at index-mail-binary.c:497
#9  index_mail_get_binary_stream (_mail=0x5555557e3b48, part=0x5555557e4678, include_hdr=<optimized out>, 
    size_r=0x7fffffffdd20, lines_r=0x7fffffffdcc4, binary_r=<optimized out>, stream_r=0x0) at index-mail-binary.c:557
#10 0x00007ffff7abd204 in mail_get_binary_size (mail=mail@entry=0x5555557e3b48, part=0x5555557e4678, 
    include_hdr=<optimized out>, size_r=size_r@entry=0x7fffffffdd20, lines_r=lines_r@entry=0x7fffffffdcc4)
    at mail.c:342
#11 0x00007ffff7b7add8 in imap_msgpart_size (mail=0x5555557e3b48, msgpart=0x5555557e0748, 
    size_r=size_r@entry=0x7fffffffdd20) at imap-msgpart.c:755
#12 0x000055555557917c in fetch_binary_size (ctx=0x5555557c97b0, mail=<optimized out>, body=0x5555557dfa20)
    at imap-fetch-body.c:212
#13 0x00005555555777e2 in imap_fetch_more_int (ctx=0x5555557c97b0, cancel=false) at imap-fetch.c:562
#14 0x00005555555788ed in imap_fetch_more (ctx=0x5555557c97b0, cmd=cmd@entry=0x5555557c95d8) at imap-fetch.c:617
#15 0x00005555555694b1 in cmd_fetch (cmd=0x5555557c95d8) at cmd-fetch.c:337
[...]
#28 0x0000555555566405 in main (argc=<optimized out>, argv=<optimized out>) at main.c:523

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This happens on latest dovecot.

Best regards,

Renaud METRICH