Re: [fetchmail-users] BUG: Null pointer dereference in sink.c:265

[Matthias A. <mat...@gm...>]

Am Samstag, den 28.07.2007, 21:19 -0700 schrieb Earl Chew: 
> I've found a problem with fetchmail core dumping via a null
> pointer dereference at sink.c:265 triggered by close_warning_by_mail()
> passing a null pointer for msg.

Is it looks to me, this fetchmail crash would have been triggered by
fetchmail's attempting to send a warning about failed authorization. The
crash then happens when the SMTP server rejects fetchmail's warning
message.

Can you confirm that from the MTA's logs perhaps?

> I'm running Fedora FC6 fetchmail-6.3.6-2 using fetchmail-6.3.6-2.fc6.src.rpm.
> I had a quick look at http://mknod.org/svn/fetchmail/trunk/ (rev 5117) and see the
> following call stack still exists:

It's been in existance since what we today call rev 2216 (committed 1998-11-27,
then released as fetchmail 4.6.8).

> #0  send_bouncemail (ctl=0x968a5b0, msg=0x0, userclass=1,
>     message=0x807854e "General SMTP/ESMTP error.\r\n", nerrors=1,
>     errors=0xbfe7f998) at sink.c:265
> #1  0x0805b77a in handle_smtp_report (ctl=0x968a5b0, msg=0x0) at sink.c:543
> #2  0x0805bbf3 in close_sink (ctl=0x968a5b0, msg=0x0, forward=1 '\001')
>     at sink.c:1386
> #3  0x0805c091 in close_warning_by_mail (ctl=0x968a5b0, msg=0x0) at sink.c:1582
> #4  0x08057a2a in do_session (ctl=0x968a5b0, proto=0x807f9a0, maxfetch=0)
>     at  driver.c:1214
> #5  0x08066ad9 in doPOP3 (ctl=0x0) at pop3.c:1409
> #6  0x0804eaaf in query_host (ctl=0x968a5b0) at fetchmail.c:1470
> #7  0x0804f5d3 in main (argc=Cannot access memory at address 0x0
> ) at fetchmail.c:739
> 
> I don't know whether the appropriate fix is to change:
> 
> 
>      /* don't bounce in reply to undeliverable bounces */
> -    if (!msg->return_path[0] ||
> +    if (!msg || !msg->return_path[0] ||
>   strcmp(msg->return_path, "<>") == 0 ||
>   strcasecmp(msg->return_path, md1) == 0 ||
>   strncasecmp(msg->return_path, md2, strlen(md2)) == 0)

I think it is, because we do not want to get bounces back to warning
messages we send. These are automated messages, and as such should never
trigger non-delivery notices.

Thank you very much for the concise report. Rev 5119 should fix the
problem and will be released as fetchmail 6.3.9 in a few days (or weeks,
depending on my spare time).

Thanks again.

Best regards
Matthias Andree