On 3/24/2011 5:36 PM, Frederik Deweerdt wrote:
On Thu, Mar 24, 2011 at 04:51:58PM -0400, Kevin A. McGrail wrote:
On 3/24/2011 4:30 PM, Frederik Deweerdt wrote:
Hi Kevin,
On Thu, Mar 24, 2011 at 03:47:25PM -0400, Kevin A. McGrail wrote:
If it were me and this race condition occurred, shouldn't there also
be a log call of some sort inside the m == NULL loop?
How could we output something with m->priv->flags unavailable? Would
stderr be OK?
Regards,
Frederik
Hi Frederik,
I would definitely not use stderr at least but perhaps the call to
message dump should pass flags from message_process so that flags
var can be used instead of the message flags. Your thoughts?
That's fine with me, it's pretty low risk because the code in libspamc.c
is immune to the crash anyway.
The NULL deref may only happen in hypothetical out-of-tree users.
The only drawback I see is that it changes the external API. Here's an
updated patch.
As far as I know, spamc is not considered an API but a client that
accepts messages using a specific protocol. We aren't changing the
protocol, just internal calls that implement the protocol. Can you
expand on this statement?
Can you open a bug at https://issues.apache.org/SpamAssassin/?
Also, do you have any emails or scenarios that test this race condition
because I don't know what you mean by out of tree user?
Regards,
KAM
