On Thu, Mar 24, 2011 at 06:16:20PM -0400, Kevin A. McGrail wrote: > 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? In my mind libspamc is an API that anyone willing to implement a spamc client could use. > > Can you open a bug at https://issues.apache.org/SpamAssassin/? In process, I'll post the bug # back. > > 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? There's no chance that the NULL deref happens with spamc: it alwas passes struct message from the stack.
It's just that a client using libspamc might crash using message_dump() Regards, Frederik
