Hi,

I'm having interesting uw-imapd core dump files from what I can
determine (with "p 'tcp_unix.c'::myClientHost" in gdb) are all
legit connections from my smartphone.

They all seem to be hanging themselves up here:

(gdb) bt
#0 0x00005647da0eb69c in ptext (txt=<optimized out>, st=0x5647f9072fb8) at imapd.c:3766
#1 0x00005647da0ecbf3 in pbodypartstring (msgno=96, id=<optimized out>, st=0x7ffd7112df80, bs=0x5647f9072fb8,
ta=0x5647f908f690) at imapd.c:3746
#2 0x00005647da0ecf4f in fetch_body_part_contents (i=96, args=<optimized out>) at imapd.c:2935
#3 0x00005647da0eefa8 in fetch_work (t=<optimized out>, t@entry=0x5647da0f7333 <cmdbuf+19> "(UID",
uid=uid@entry=1, f=f@entry=0x7ffd7112e070, fa=fa@entry=0x7ffd7112e3a0) at imapd.c:2849
#4 0x00005647da0ef9a1 in fetch (t=t@entry=0x5647da0f7333 <cmdbuf+19> "(UID", uid=uid@entry=1) at imapd.c:2613
#5 0x00005647da0e6258 in main (argc=<optimized out>, argv=<optimized out>) at imapd.c:603

The cause is:

(gdb) print *st
$25 = {data = 0x3, data1 = 14067757, size = 1279866,
chunk = 0x5647f9077d40 "(base64-encoded stuff)"..., chunksize = 65536, offset = 1279866,
curpos = 0x5647f9093001 <error: Cannot access memory at address 0x5647f9093001>,
cursize = 18446744073709440319, dtb = 0x7fa2390507a0 <fd_string>}

cursize is negative (-111297), and curpos is two bytes
past the end of chunk (checked), or rather the memory page
chunk resides in.

I suspect SNX() has been called at least once when cursize was 0,
as it pre-decrements, then checks, and there might be a missing check,

Also interesting:

(gdb) frame 1
(gdb) print *ta
$28 = {section = 0x5647f908f610 "2", lines = 0x0, first = 1179648, last = 393216, flags = 2, binary = 0}

Here, first is larger than last. AFAICT this may trigger:

3020 if (st.size <= ta->first) st.size = ta->first = 0;

Most of the remaining code does not seem to look at st.size (or ta)
but only at txt->data and the likes.

Perhaps this can get someone familiar with the code (Mark?) to have
an idea of how to fix this. I would prefer imapd to not crash with
a core dump but reject problematic commands.

Thanks in advance,
//mirabilos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 3 Jul 2025, Thorsten Glaser wrote:

Hi,

I'm having interesting uw-imapd core dump files from what I can
determine (with "p 'tcp_unix.c'::myClientHost" in gdb) are all
legit connections from my smartphone.

you seem to be using an old version of imapd.c. From the current bits
ptext is between lines 3878 and 3883, so it seems you are using an old
version. The advice in these cases is to upgrade your version to a newer version.

--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eduardo Chappa dixit:

you seem to be using an old version of imapd.c. From the current bits
ptext is between lines 3878 and 3883, so it seems you are using an old version.
The advice in these cases is to upgrade your version to a newer version.

AFAICT I have the latest known version, perhaps did the distribution
site change? Can you point me to the latest?

Thanks,
//mirabilos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 13 Jul 2025, Thorsten Glaser wrote:

Eduardo Chappa dixit:

you seem to be using an old version of imapd.c. From the current bits
ptext is between lines 3878 and 3883, so it seems you are using an old
version. The advice in these cases is to upgrade your version to a
newer version.

AFAICT I have the latest known version, perhaps did the distribution
site change? Can you point me to the latest?

Tough question to answer, since there is no official distribution of
imapd. This is what I can tell you.

The latest bits created by Mark Crispin are located at

https://github.com/jonabbey/panda-imap

I do not know if they have ever been updated. For example to update the
code based on changes in the openssl library API.

The bits for imapd in the source code of alpine have been updated for
changes in the openssl library API, but I have never updated the imapd
code, so it is probably the same as in github, but I have updated the underlying c-client library to work with Alpine, no testing of the imapd
code has ever been done, so if you go that way, use it at your own risk.

I hope this helps.

--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/7/25 03:11, Eduardo Chappa wrote:

On Sun, 13 Jul 2025, Thorsten Glaser wrote:

Eduardo Chappa dixit:

you seem to be using an old version of imapd.c. From the current bits
ptext is between lines 3878 and 3883, so it seems you are using an
old version. The advice in these cases is to upgrade your version to
a newer version.

AFAICT I have the latest known version, perhaps did the distribution
site change? Can you point me to the latest?

Tough question to answer, since there is no official distribution of
imapd. This is what I can tell you.

The latest bits created by Mark Crispin are located at

https://github.com/jonabbey/panda-imap

I do not know if they have ever been updated. For example to update the
code based on changes in the openssl library API.

The bits for imapd in the source code of alpine have been updated for
changes in the openssl library API, but I have never updated the imapd
code, so it is probably the same as in github, but I have updated the underlying c-client library to work with Alpine, no testing of the imapd
code has ever been done, so if you go that way, use it at your own risk.

I hope this helps.

Someone - Erik Kangas - did the OpenSSL 1.1.x changes to Panda-IMAP,
and they may have been checked in to that repository.

If they haven't, here's the email from the IMAP mailing list: ======================================================================
1. There is only 1 critical change. There are a lot of fatal compile
errors around use of "cert->name". Openssl no longer exposes the
contents of the X509 structure. The solution seems to be to replace
this with something like:

cert->name

replace with

X509_NAME_oneline(X509_get_subject_name(cert),NULL,0)


which extracts the name from the cert object and returns it as a newly allocated char*. This could be a very small memory leak; but for most
purposes each imapd and ipop3d only exist for the single connection --
so its probably not a concern, just a few bytes. You could fix by
adding a few more lines to create a buffer and have
X509_NAME_oneline save to your buffer, etc.

2. There are a couple deprecated functions that should be updated:

TLSv1_client_method

TLS_client_method

RSA_generate_key

RSA_generate_key_ex

That is it -- things seem to be compiling and tests (so far) show things
are working properly. There are still compile warnings here and there
(as there always have been with imapd) but they seem OK. I will still
be testing for some time before I push out. Also, linking to
openssl v1.1.1 also seems to have cleared up some issues with C-Client
using STARTTLS with TLS 1.2-only servers (we already have support for
DHE and ECDHE built in). ======================================================================

Cheers,
Gary B-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)