Bug#999804: crash after upgrade to 1.4.3

2021-12-03 Thread Antoine Beaupré 
On 2021-11-22 20:24:09, Olzvoi Bayasgalan wrote:
> Hi,
>
> Should we have blocked this version of isync's transition to testing due 
> to this issue? I know it's too late now, but the question seems valid in 
> general.

Maybe. A single crash like this might not warrant a RC severity, which
would have been required to block transition. I felt my setup was exotic
enough that it didn't warrant a blocker bug, but I hadn't realized there
was potentially a security issue there (silly me), otherwise I would
have handled this very differently anyways.

But yeah, maybe. :) Anyways now it should trickle down to testing soon
enough and this will be all moot.

a.

-- 
Celui qui sait jouir du peu qu'il a est toujours assez riche.
 - Démocrite

Bug#999804: crash after upgrade to 1.4.3

2021-11-22 Thread Olzvoi Bayasgalan 

Hi,

Should we have blocked this version of isync's transition to testing due 
to this issue? I know it's too late now, but the question seems valid in 
general.


- Olzvoi

Bug#999804: crash after upgrade to 1.4.3

2021-11-16 Thread Antoine Beaupre 
Package: isync
Version: 1.4.3-1
Severity: normal

Before the upgrade (1.3.0-2.2, on bullseye), I am able to run mbsync
without too many issues. After the upgrade, it completely crashes with
what looks like an assertion failure:

C: 0/1  B: 134/205  F: +0/0 *0/0 #0/0  N: +4/4 *0/0 #0/0
Warning: lost track of 676 pulled message(s)
C: 0/1  B: 134/205  F: +0/0 *0/0 #0/0  N: +4/681 *0/0 #0/0
Warning: message 1 from far side has incomplete header.
C: 0/1  B: 134/205  F: +0/0 *0/0 #0/0  N: +5/681 *0/0 #0/0corrupted size vs. 
prev_size while consolidating
Abandon (core dumped)

Here's the backtrace:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f529fa18537 in __GI_abort () at abort.c:79
#2  0x7f529fa71768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f529fb7fe2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f529fa78a5a in malloc_printerr (
str=str@entry=0x7f529fb82280 "corrupted size vs. prev_size while 
consolidating") at malloc.c:5347
#4  0x7f529fa7a12e in _int_free (av=0x7f529fbb1b80 , 
p=0x5613006c9860, have_lock=) at malloc.c:4332
#5  0x5612ff5f01a7 in copy_msg_convert (vars=0x561300587510, 
out_cr=, in_cr=) at ./src/sync.c:534
#6  msg_fetched (sts=, aux=0x561300587510) at ./src/sync.c:559
#7  0x5612ff5f9832 in done_imap_cmd (ctx=ctx@entry=0x7f52a0140010, 
cmd=cmd@entry=0x561300635b30, response=response@entry=0)
at ./src/drv_imap.c:326
#8  0x5612ff600bc2 in imap_socket_read (aux=0x7f52a0140010)
at ./src/drv_imap.c:1740
#9  0x5612ff5f72b7 in event_wait () at ./src/util.c:831
#10 main_loop () at ./src/util.c:903
#11 0x5612ff5ec38f in main (argc=, argv=)
at ./src/main.c:797

It could be this is a new assertion for something that was broken
already in a previous version. I'm dealing with corruption issues on
the IMAP server side, but it seems to me this should still not crash,
especially on hostile server data...

(I don't have a particular reason to believe this is a security issue,
but i guess that if this is caused by a malicious message, it might be
a mild DOS condition..)

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages isync depends on:
ii  libc6   2.31-13+deb11u2
ii  libdb5.35.3.28+dfsg1-0.8
ii  libsasl2-2  2.1.27+dfsg-2.1
ii  libssl1.1   1.1.1k-1+deb11u1
ii  zlib1g  1:1.2.11.dfsg-2

isync recommends no packages.

Versions of packages isync suggests:
ii  mutt  2.0.5-4.1

-- no debconf information