Panic: file charset-iconv.c: line 83 (charset_to_utf8_try): assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
- Declares charset="UTF-7"
- Contains base64-encoded content that, when decoded, has bare '+' characters
- Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure.
Alex
Looks like attachments are stripped by this Mailman instance. I’ll send it to anybody that wants it; I made it an attachment to try to avoid crashing the server of everybody on this list.
Alex
On May 8, 2026, at 3:27 PM, Alex Rosenberg via dovecot <dovecot@dovecot.org> wrote:
Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
- Declares charset="UTF-7"
- Contains base64-encoded content that, when decoded, has bare '+' characters
- Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure.
Alex
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
"Alex" == Alex Rosenberg via dovecot <dovecot@dovecot.org> writes:
Looks like attachments are stripped by this Mailman instance. I’ll send it to anybody that wants it; I made it an attachment to try to avoid crashing the server of everybody on this list. Alex
Just send the patch inline, or maybe put it up somewhere where people can find it more easily? If you're including a test case (great! please do!) then I can understand the problem. But maybe there's a way to encode the test case so it will work inline, but then get tested properly.
And does this same issue hit under 2.4?
Thanks, John
On May 8, 2026, at 3:27 PM, Alex Rosenberg via dovecot <dovecot@dovecot.org> wrote:
Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
- Declares charset="UTF-7"
- Contains base64-encoded content that, when decoded, has bare '+' characters
- Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure.
Alex
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
This is just the test case, not a patch as yet. I don’t have a 2.4 installation at this time.
Alex
— cut here and base64 decode this tarball -- H4sIAJJa/mkAA+1WW3PaVhDO8/kVG7/EnlRECGyMUs9U3GUMmIsx8MIcSQdJWLdKh4vy67uSIBDsONM200473hlGo3N2v/32InZd27Nd6sxDFoS+sdJZmGOu8+6niiiKV8UiJE+U06coSUUR8pf5Uql4WSgVr0DMX6K8A/Hn0nhZVhGnIVIJfZ+/prexGHstL6fB/UekEfquDJxF/De2pW7gsJzuu2Tkv3A4XGlLpnMZOlnTQM1fM93noFs0jBgXbN331qCtTDi0E6n6HmceF0ZxwGRwVw63AxryT669ZcZn0PyVZ9AwvjkTUG7mXbbl93g/F8X8GemonbowZmFk+54M+ZxIiCA8VzxxwvHqU+BQ2/u853Zz9jBqCKWzg2ZIvWjBQqHu6b5he6YMGo3YVZGQ2cQSZ5Pbldqarelj35xK2/XUvXX0Zd2nj5eiWg2+GM2GOBuXN0ZLDXobsf09G6Iv1T9tpC87L9qQxKjWDwLN65szt7xuN7v+dKKa03hjpgatrjidDJy7aiXVMZpWPJt0fU3aPrWHlVKt75tqtVKgTScis6Hi64WBZTQfzPtqRaQt9CxZa63ZD9RW1K3aCiorpl4wAgMdqVUrYzN8MhkSSe4QbDmddB2i1upXGXpmdJyzWy9j1R4dQNEwmNmKP42V8v1Q8dq2/tUp2YPsw2nHUekYfDGsOFqr66hNx0VWS7UmltWqvr6Nj5llP7ILkd99672sNseRLj08M3iN+YFZ01gbzWtTK4zF3jFASzx2stSaZXvqjuOObbo7IsFePwNr3sazx0bYO0moWlO/k8/Oi/lEsIqtu2OLfjkcLvoZaPJMmZrZO+qJRtp3GVDiPNHZtxbRHhuBZlvpy3Ry6yX9NZUsS7eV39tuI54VpocWwbYxWuNYsyuuJl37ib7hRNvJOIonw41JMgAlVGv9CMPKd7F/7m1l26kpWNWgjGHevPxZCwL5t/8f/+8yqCu1Tj3Ht68Ov78nP5j/+VLh6/y/lPIlnP/SVUl6m///hLw4wnM6VFYLHI7QW7Nw4fgbfDdhcBjqN39FCBlZdgQ01C17zQA9cRzReADubqFgLrUdcFkUUZMBtygHHtqmiQsAamkZJ3/HidjefgP5ED0LIB33YOCtgTst2c/9SCbC3t3J0itD/Rv3G5tbO5hkDYFka4Hz/C/56yJoMW5HF4Q8KoOu2m3KSAQ8TCPi6WiO1DHQLJoUZp/mxmgItmewLS4cwDyqOcx4T1SOWo4DOl1FDIydLvfRpWfrKYJM4DRE+bogA40iFnLcjmCBzpghw3kU6g5bcPj1BqotZTCsj+YdZTK/r3drSHVeeWjMh+qsjuyTotYYFsFJ06JgenWeYOzpYl6zBOxcJzVbZ9sY6o+y0shH6UmDPVm59oVOQs5WLIElOxcz0hssCsaWGmo0ZPDh44cUgSIVLPu5Yz8xOKOhqcNHKJ5doOM7X6c83Qh3rubcn6/44nrOw/j8AhYrT09zgh3yPGnYhrjZoncEQLB9rFKukMuLcwnwrBEyVhnWII9HwqB+V1eGdSEoo6V/WG0hogvmxDLJ56C+5QlhhEzXZohi9OASKQcPu4pSw00qmhYf24Nl3UEKOehpWEL8HtJif9JDGlmE1HrQ7Y1g4YcbGhrH/RTSDQhAnQ2NI3hiLACbJ4HuPys0cd+/zc03eZM3+aH8Ad5MJggAEgAA — cut here —
On May 9, 2026, at 11:28 AM, John Stoffel <john@stoffel.org> wrote:
"Alex" == Alex Rosenberg via dovecot <dovecot@dovecot.org <mailto:dovecot@dovecot.org>> writes:
Looks like attachments are stripped by this Mailman instance. I’ll send it to anybody that wants it; I made it an attachment to try to avoid crashing the server of everybody on this list. Alex
Just send the patch inline, or maybe put it up somewhere where people can find it more easily? If you're including a test case (great! please do!) then I can understand the problem. But maybe there's a way to encode the test case so it will work inline, but then get tested properly.
And does this same issue hit under 2.4?
Thanks, John
On May 8, 2026, at 3:27 PM, Alex Rosenberg via dovecot <dovecot@dovecot.org> wrote:
Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
- Declares charset="UTF-7"
- Contains base64-encoded content that, when decoded, has bare '+' characters
- Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure.
Alex
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org <mailto:dovecot@dovecot.org> To unsubscribe send an email to dovecot-leave@dovecot.org <mailto:dovecot-leave@dovecot.org>
This is just the test case, not a patch as yet. I don't have a 2.4 installation at this time. Alex -- cut here and base64 decode this tarball -- H4sIAJJa/mkAA+1WW3PaVhDO8/kVG7/EnlRECGyMUs9U3GUMmIsx8MIcSQdJWLdKh4vy67uSIBDsONM200473hlGo3N2v/32InZd27Nd6sxDFoS+sdJZmGOu8+6niiiKV8UiJE+U06coSUUR8pf5Uql4WSgVr0DMX6K8A/Hn0nhZVhGnIVIJfZ+/prexGHstL6fB/UekEfquDJxF/De2pW7gsJzuu2Tkv3A4XGlLpnMZOlnTQM1fM93noFs0jBgXbN331qCtTDi0E6n6HmceF0ZxwGRwVw63AxryT669ZcZn0PyVZ9AwvjkTUG7mXbbl93g/F8X8GemonbowZmFk+54M+ZxIiCA8VzxxwvHqU+BQ2/u853Zz9jBqCKWzg2ZIvWjBQqHu6b5he6YMGo3YVZGQ2cQSZ5Pbldqarelj35xK2/XUvXX0Zd2nj5eiWg2+GM2GOBuXN0ZLDXobsf09G6Iv1T9tpC87L9qQxKjWDwLN65szt7xuN7v+dKKa03hjpgatrjidDJy7aiXVMZpWPJt0fU3aPrWHlVKt75tqtVKgTScis6Hi64WBZTQfzPtqRaQt9CxZa63ZD9RW1K3aCiorpl4wAgMdqVUrYzN8MhkSSe4QbDmddB2i1upXGXpmdJyzWy9j1R4dQNEwmNmKP42V8v1Q8dq2/tUp2YPsw2nHUekYfDGsOFqr66hNx0VWS7UmltWqvr6Nj5llP7ILkd99672sNseRLj08M3iN+YFZ01gbzWtTK4zF3jFASzx2stSaZXvqjuOObbo7IsFePwNr3sazx0bYO0moWlO/k8/Oi/lEsIqtu2OLfjkcLvoZaPJMmZrZO+qJRtp3GVDiPNHZtxbRHhuBZlvpy3Ry6yX9NZUsS7eV39tuI54VpocWwbYxWuNYsyuuJl37ib7hRNvJOIonw41JMgAlVGv9CMPKd7F/7m1l26kpWNWgjGHevPxZCwL5t/8f/+8yqCu1Tj3Ht68Ov78nP5j/+VLh6/y/lPIlnP/SVUl6m///hLw4wnM6VFYLHI7QW7Nw4fgbfDdhcBjqN39FCBlZdgQ01C17zQA9cRzReADubqFgLrUdcFkUUZMBtygHHtqmiQsAamkZJ3/HidjefgP5ED0LIB33YOCtgTst2c/9SCbC3t3J0itD/Rv3G5tbO5hkDYFka4Hz/C/56yJoMW5HF4Q8KoOu2m3KSAQ8TCPi6WiO1DHQLJoUZp/mxmgItmewLS4cwDyqOcx4T1SOWo4DOl1FDIydLvfRpWfrKYJM4DRE+bogA40iFnLcjmCBzpghw3kU6g5bcPj1BqotZTCsj+YdZTK/r3drSHVeeWjMh+qsjuyTotYYFsFJ06JgenWeYOzpYl6zBOxcJzVbZ9sY6o+y0shH6UmDPVm59oVOQs5WLIElOxcz0hssCsaWGmo0ZPDh44cUgSIVLPu5Yz8xOKOhqcNHKJ5doOM7X6c83Qh3rubcn6/44nrOw/j8AhYrT09zgh3yPGnYhrjZoncEQLB9rFKukMuLcwnwrBEyVhnWII9HwqB+V1eGdSEoo6V/WG0hogvmxDLJ56C+5QlhhEzXZohi9OASKQcPu4pSw00qmhYf24Nl3UEKOehpWEL8HtJif9JDGlmE1HrQ7Y1g4YcbGhrH/RTSDQhAnQ2NI3hiLACbJ4HuPys0cd+/zc03eZM3+aH8Ad5MJggAEgAA -- cut here --
On May 9, 2026, at 11:28AM, John Stoffel <john@stoffel.org> wrote:
"Alex" == Alex Rosenberg via dovecot <[1]dovecot@dovecot.org>
writes:
Looks like attachments are stripped by this Mailman instance. I'll
send it to anybody that wants it; I made it an attachment to try to
avoid crashing the server of everybody on this list. Alex
Just send the patch inline, or maybe put it up somewhere where people
can find it more easily? If you're including a test case (great!
please do!) then I can understand the problem. But maybe there's a
way to encode the test case so it will work inline, but then get
tested properly.
And does this same issue hit under 2.4?
Thanks,
John
On May 8, 2026, at 3:27PM, Alex Rosenberg via dovecot
<dovecot@dovecot.org> wrote:
Attached is an LLM-reduced reproduction of the crash in the title.
My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD
jail (13.5). I realize that this is an older release but there is no
FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email
to one of the LLVM compiler mailing lists. The original malformed
email had this header:
X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part
that:
1. Declares charset="UTF-7"
2. Contains base64-encoded content that, when decoded, has bare '+'
characters
3. Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending
buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the
assertion failure.
Alex
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________
dovecot mailing list -- [2]dovecot@dovecot.org
To unsubscribe send an email to [3]dovecot-leave@dovecot.orgReferences
Visible links
- mailto:dovecot@dovecot.org
- mailto:dovecot@dovecot.org
- mailto:dovecot-leave@dovecot.org
On 09/05/2026 00:27, Alex Rosenberg via dovecot wrote:
Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
- Declares charset="UTF-7"
- Contains base64-encoded content that, when decoded, has bare '+' characters
- Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure.
Alex
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi Alex
looks like the same code is present also in 2.4 so I guess this is not just an issue with older versions of Dovecot.
Basically there is an assumed limit of 10 for the maximum number of unprocessed bytes that iconv library function can return when it gives an EINVAL error. Logically this value could be larger, the upper bound for unprocessed bytes could even be the number of input bytes. In practice it seems it hasn't been an issue so far to have an upper bound of 10.
The Dovecot header file charset-utf8.h itself reports
/* Max number of bytes that iconv can require for a single character. UTF-8 takes max 6 bytes per character. Not sure about others, but I'd think 10 is more than enough for everyone.. */ #define CHARSET_MAX_PENDING_BUF_SIZE 10
It wasn't 100% clear to me why this limit needs to be imposed in charset_to_utf8_try (and also in iconv_charset_to_utf8) but I am guessing that it is there for a reason, to prevent buffer overflows elsewhere in the calling code. It would be interesting to know what value was returned in your case, by adding some debugging code just before the assert:
if (inleft > CHARSET_MAX_PENDING_BUF_SIZE) { i_warning("charset-iconv: pending buffer size %zu exceeds limit %d", inleft, CHARSET_MAX_PENDING_BUF_SIZE);
Ultimately, the simplest and safest fix, without refactoring calliing code, may just boil down to selecting a better limit, e.g.
#define CHARSET_MAX_PENDING_BUF_SIZE 20
John
On 9. May 2026, at 1.27, Alex Rosenberg via dovecot <dovecot@dovecot.org> wrote:
Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
- Declares charset="UTF-7"
- Contains base64-encoded content that, when decoded, has bare '+' characters
- Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure.
This should have been fixed in v2.4.3 with the commits:
https://github.com/dovecot/core/commit/110c19e44e95be6b6d2b09cf994ce5b502c8d... https://github.com/dovecot/core/commit/3dced982a4f7dbcc8c11f15f566f4b2b4ff5d... https://github.com/dovecot/core/commit/db2add1b4058fd489905ea833ea31ceb4d550...
On 9. May 2026, at 1.27, Alex Rosenberg via dovecot <dovecot@dovecot.org> wrote:
Attached is an LLM-reduced reproduction of the crash in the title. My
particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail
(13.5). I realize that this is an older release but there is no FreeBSD
port/pkg for dovecot 2.4.x yet.
The message in the attachment is reduced from an old (2017!) email to
one of the LLVM compiler mailing lists. The original malformed email had
this header:
X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25)
The bug occurs when dovecot's FTS indexer processes a MIME part that:
1. Declares charset="UTF-7"
2. Contains base64-encoded content that, when decoded, has bare '+'
characters
3. Causes UTF-7 decoder buffer overflow in charset-iconv.c:83
The base64 content decodes to C source code with expressions like:
- argc + 4
- state++
- state--
These '+' characters in UTF-7 context cause the decoder's pending buffer
to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion
failure.This should have been fixed in v2.4.3 with the commits: [1]https://github.com/dovecot/core/commit/110c19e44e95be6b6d2b09cf994ce5b502c8d... [2]https://github.com/dovecot/core/commit/3dced982a4f7dbcc8c11f15f566f4b2b4ff5d... [3]https://github.com/dovecot/core/commit/db2add1b4058fd489905ea833ea31ceb4d550...
References
Visible links
participants (4)
-
Alex Rosenberg
-
John Fawcett
-
John Stoffel
-
Timo Sirainen