Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1894418

Summary: imap crashes in libdovecot-storage with assert "(block_count == 0 || block_idx+1 == block_count)"
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: dovecotAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: high Docs Contact:
Priority: high    
Version: 8.2CC: djez
Target Milestone: rcKeywords: Triaged
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: dovecot-2.3.8-6.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1974281 (view as bug list) Environment:
Last Closed: 2021-05-18 15:54:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1974281    
Attachments:
Description Flags
Reproducer
none
Reproducer none

Description Renaud Métrich 2020-11-04 08:47:17 UTC 
Created attachment 1726492 [details]
Reproducer

Description of problem:

A customer faces regular crashes of imap process when a mail is accessed.
From first look, the mail looks valid to me.

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff6e2eb25 in __GI_abort () at abort.c:79
#2  0x00007ffff7707d73 in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) at failures.c:459
#3  fatal_handler_real (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at failures.c:471
#4  0x00007ffff77aa877 in default_fatal_handler (ctx=<optimized out>, format=<optimized out>, args=<optimized out>)
    at failures.c:479
#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
#16 0x0000555555575c98 in command_exec (cmd=cmd@entry=0x5555557c95d8) at imap-commands.c:201
#17 0x0000555555573fd2 in client_command_input (cmd=<optimized out>) at imap-client.c:1169
#18 0x0000555555574076 in client_command_input (cmd=<optimized out>) at imap-client.c:1232
#19 0x0000555555574425 in client_handle_next_command (remove_io_r=<synthetic pointer>, client=0x5555557c8b88)
    at imap-client.c:1274
#20 client_handle_input (client=0x5555557c8b88) at imap-client.c:1288
#21 client_handle_input (client=0x5555557c8b88) at imap-client.c:1277
#22 0x0000555555574962 in client_input (client=0x5555557c8b88) at imap-client.c:1334
#23 0x00007ffff77c1fa3 in io_loop_call_io (io=0x5555557c94b0) at ioloop.c:718
#24 0x00007ffff77c3655 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x5555557a0830) at ioloop-epoll.c:222
#25 0x00007ffff77c2050 in io_loop_handler_run (ioloop=0x5555557a0830) at ioloop.c:770
#26 0x00007ffff77c21b8 in io_loop_run (ioloop=0x5555557a0830) at ioloop.c:743
#27 0x00007ffff7739d97 in master_service_run (service=0x5555557a06c0, 
    callback=callback@entry=0x555555581c40 <client_connected>) at master-service.c:782
#28 0x0000555555566405 in main (argc=<optimized out>, argv=<optimized out>) at main.c:523



Version-Release number of selected component (if applicable):

dovecot-2.3.8-2.el8_2.2.x86_64 but also Upstream one


How reproducible:

Always with the reproducer attached.

Steps to Reproduce:
1. Create a "dummy" user with uid 1001

  # useradd -u 1001 dummy

2. Extract the reproducer

  # tar xf repro_XXX.tar -C /

3. Start dovecot

  # systemctl start dovecot

4. Execute imap process for dummy user and send commands below

  # /usr/libexec/dovecot/imap -u dummy
  [...]
  1. select "Trash"
  2. UID FETCH 11934 (BINARY.SIZE[1] BINARY.PEEK[1])


Actual results:

  Crash

Expected results:

  No crash

Additional info:

The failing mail looks valid to me from first look, see /home/dummy/Maildir/.Trash/cur/1602834888.M712234P2451275.XXXXXXX.XXX.XXX.XXX.XX\,S\=633\,W\=649\:2\,S below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Return-Path: <XXXXXXXXX.XX>
X-Original-To: XXXXXXXXX.XX
Delivered-To: XXXXXXXXXXXXXXXX.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.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.XXX>
From: "XXXXXXXXX.XX" <XXXXXXXXX.XX>
To: XXXXXXXXX.XX
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64


-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Comment 1 Renaud Métrich 2020-11-04 10:59:02 UTC 
The issue is somewhere here:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
361 static int
362 index_mail_read_binary_to_cache(struct mail *_mail,
363                                 const struct message_part *part,
364                                 bool include_hdr, const char *reason,
365                                 bool *binary_r, bool *converted_r)
366 {
367         struct index_mail *mail = INDEX_MAIL(_mail);
368         struct mail_binary_cache *cache = &_mail->box->storage->binary_cache;
369         struct binary_ctx ctx;
370         struct istream *is;
371 
372         i_zero(&ctx);
373         ctx.mail = _mail;
374         t_array_init(&ctx.blocks, 8);
375 
376         mail_storage_free_binary_cache(_mail->box->storage);
377         if (mail_get_stream_because(_mail, NULL, NULL, reason, &ctx.input) < 0)
378                 return -1;
379 
380         if (add_binary_part(&ctx, part, include_hdr) < 0) {
381                 binary_streams_free(&ctx);
382                 return -1;
383         }
384 
385         if (array_count(&ctx.blocks) != 0) {
386                 is = i_streams_merge(blocks_get_streams(&ctx),
387                                                IO_BLOCK_SIZE,
388                                                fd_callback, _mail);
389         } else {
390                 is = i_stream_create_from_data("", 0);
391         }
392         i_stream_set_name(is, t_strdup_printf(
393                 "<binary stream of mailbox %s UID %u>",
394                 _mail->box->vname, _mail->uid));
395         if (blocks_count_lines(&ctx, is) < 0) {
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

For some reason block_count is computed to 2 even though there is only 1.
Comment 2 Renaud Métrich 2020-11-04 12:04:21 UTC 
Created attachment 1726535 [details]
Reproducer
Comment 8 Michal Hlavinka 2020-11-16 14:00:42 UTC 
Thanks for verifying this.
Comment 14 errata-xmlrpc 2021-05-18 15:54:47 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: dovecot security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:1887