IMAP session hangs on 8k-long commands if COMPRESS=DEFLATE is enabled

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

IMAP session hangs on 8k-long commands if COMPRESS=DEFLATE is enabled

Dovecot mailing list
Hi there,

Dovecot 2.3.7 appears to hang when the client sends a long command after
enabling the IMAP COMPRESS extension [RFC 4978].  PoC script attached
along with the doveconf(1) output.

Without COMPRESS=DEFLATE, and with the default ‘imap_max_line_length’
value (64k) I'm able send commands up to 65539 bytes long (that's 3
bytes more than 2¹⁶, so maybe the leading tag and the trailing CRLF
aren't counted), after which Dovecot rightfully replies with tagged BAD
responses.

    $ COMPRESS=n /tmp/many-fetch.pl 65539
    […]
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [65539 bytes]
    S: x OK Fetch completed (0.005 + 0.001 + 0.004 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [65540 bytes]
    S: x BAD Error in IMAP command UID FETCH: IMAP command line too large (0.001 + 0.001 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [65541 bytes]
    S: x BAD Error in IMAP command UID FETCH: IMAP command line too large (0.001 + 0.001 secs).

With COMPRESS=DEFLATE however, the server never sends anything back when
the command size exceeds 8192 bytes:

    $ COMPRESS=y /tmp/many-fetch.pl 8192
    […]
    S: x OK [READ-ONLY] Examine completed (0.001 + 0.000 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [8191 bytes]
    S: x OK Fetch completed (0.001 + 0.000 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [8192 bytes]
    S: x OK Fetch completed (0.001 + 0.000 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [8193 bytes]
    [ _hangs until the server terminates the session for inactivity_ ]
    S: * BYE Disconnected for inactivity.

strace(1) show that Dovecot didn't send the response, even though the
server log indicates that it's able to fully read the command.

Interestingly, when setting ‘imap_max_line_length’ to 4096, the server
also hangs after receiving a command of size >4096 bytes (instead of
replying with a tagged BAD response).

    $ COMPRESS=y /tmp/many-fetch.pl 4096
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [4095 bytes]
    S: x OK Fetch completed (0.001 + 0.000 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [4096 bytes]
    S: x OK Fetch completed (0.001 + 0.000 secs).
    C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [4097 bytes]
    [ _hangs until the server terminates the session for inactivity_ ]

I'm also able to reproduce the buggy behavior against Dovecot versions
found in other Debian releases.  It's identical with 2.3.4 (Buster), the
server also hang past 8192 bytes.  2.2.27 (Stretch) and 2.2.13 (Jessie)
are able to send replies to 8k-long commands, but hang past 65536 bytes.
For all 3 releases, without COMPRESS=DEFLATE Dovecot doesn't hang and
rightfully sends tagged BAD responses to commands of size >65539 bytes.

So while the hanging behavior appears to be a long-standing bug, the
fact that's it's now hit at min($imap_max_line_length, 8192) instead of
$imap_max_line_length seems to be a regression from somewhere between
2.2.27 and 2.3.4.

Cheers,
--
Guilhem.

dovecot.conf (738 bytes) Download Attachment
many-fetch.pl (2K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IMAP session hangs on 8k-long commands if COMPRESS=DEFLATE is enabled

Dovecot mailing list


On 13/11/2019 00:22, Guilhem Moulin via dovecot wrote:

> Hi there,
>
> Dovecot 2.3.7 appears to hang when the client sends a long command after
> enabling the IMAP COMPRESS extension [RFC 4978].  PoC script attached
> along with the doveconf(1) output.
>
> Without COMPRESS=DEFLATE, and with the default ‘imap_max_line_length’
> value (64k) I'm able send commands up to 65539 bytes long (that's 3
> bytes more than 2¹⁶, so maybe the leading tag and the trailing CRLF
> aren't counted), after which Dovecot rightfully replies with tagged BAD
> responses.
>
>      $ COMPRESS=n /tmp/many-fetch.pl 65539
>      […]
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [65539 bytes]
>      S: x OK Fetch completed (0.005 + 0.001 + 0.004 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [65540 bytes]
>      S: x BAD Error in IMAP command UID FETCH: IMAP command line too large (0.001 + 0.001 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [65541 bytes]
>      S: x BAD Error in IMAP command UID FETCH: IMAP command line too large (0.001 + 0.001 secs).
>
> With COMPRESS=DEFLATE however, the server never sends anything back when
> the command size exceeds 8192 bytes:
>
>      $ COMPRESS=y /tmp/many-fetch.pl 8192
>      […]
>      S: x OK [READ-ONLY] Examine completed (0.001 + 0.000 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [8191 bytes]
>      S: x OK Fetch completed (0.001 + 0.000 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [8192 bytes]
>      S: x OK Fetch completed (0.001 + 0.000 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [8193 bytes]
>      [ _hangs until the server terminates the session for inactivity_ ]
>      S: * BYE Disconnected for inactivity.
>
> strace(1) show that Dovecot didn't send the response, even though the
> server log indicates that it's able to fully read the command.
>
> Interestingly, when setting ‘imap_max_line_length’ to 4096, the server
> also hangs after receiving a command of size >4096 bytes (instead of
> replying with a tagged BAD response).
>
>      $ COMPRESS=y /tmp/many-fetch.pl 4096
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [4095 bytes]
>      S: x OK Fetch completed (0.001 + 0.000 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [4096 bytes]
>      S: x OK Fetch completed (0.001 + 0.000 secs).
>      C: x UID FETCH 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,… [4097 bytes]
>      [ _hangs until the server terminates the session for inactivity_ ]
>
> I'm also able to reproduce the buggy behavior against Dovecot versions
> found in other Debian releases.  It's identical with 2.3.4 (Buster), the
> server also hang past 8192 bytes.  2.2.27 (Stretch) and 2.2.13 (Jessie)
> are able to send replies to 8k-long commands, but hang past 65536 bytes.
> For all 3 releases, without COMPRESS=DEFLATE Dovecot doesn't hang and
> rightfully sends tagged BAD responses to commands of size >65539 bytes.
>
> So while the hanging behavior appears to be a long-standing bug, the
> fact that's it's now hit at min($imap_max_line_length, 8192) instead of
> $imap_max_line_length seems to be a regression from somewhere between
> 2.2.27 and 2.3.4.

I was able to confirm this problem with the current master. Tracking
internally as DOP-1591.

Regards,

Stephan.