#1394 memory Leak in smtp.c

[Jitendar Kumar]

Some potential resource leaks found in lib/smtp.c . The attached patch fixes them.

Thanks

[Steve Holme]

Hi,

Thank you for your reports and patches for imap.c, pop3.c and smtp.c.

Have you managed to prove that the code leaks / do you have a test case or example that proves this?

I know the code path fairly well and don't believe it does but am willing to be proved wrong ;-)

Kind Regards

Steve

[Jitendar Kumar]

Hi,

The bugs were traced during static analysis of Curl code in imap.c, pop3.c and smtp.c.

eg : In file smtp.c : smtp_state_auth_cancel_resp()

snippet :

if(!result) {
/ Do we have any mechanisms left? /
if(mech) {
/ Retry SASL based authentication /
result = smtp_perform_auth(conn, mech, initresp, len, state1, state2);

  Curl_safefree(initresp);
}
else {
  failf(data, "Authentication cancelled");

  result = CURLE_LOGIN_DENIED;
}

}

The tool traced the bugs in case when "mech" is NULL
( case : "Authentication failed ").

In such scenario the "initresp" must be freed before return.

Similar scenario's in files imap.c, pop3.c and smtp.c.

Thanks and regards,
Jitendar Kumar

[Steve Holme]

Hi,

Just a quick response as I'm at work but if mech is NULL then initresp will also be NULL - as it doesn't make sense for smtp_calc_sasl_details() to return no authentication mechanism but return an initial response.

If this is not the case then there is a bug in the smtp_calc_sasl_details() function.

I don't know what tool you are using to analyse the code but could it is getting confused with the invariant here?

Kind Regards

Steve

[Jitendar Kumar]

Dear Steve,

Thanks for the valuable info.
Please close the 3 bugs.

Regards,
Jitendar