[Snort-devel] Stream6 PAF callback function sharing (void **user) argument issue.

Josh Rosenbaum (jrosenba) jrosenba at ...3461...
Thu Nov 6 16:46:47 EST 2014

Hi Mitesh,

Yes, this is definitely a bug since, as you pointed out, the same pointer (== ps->user) is passed in to every callback.  However, it is also not as problematic as you would expect for two reasons.  First, before any PAF function callocs() memory, it checks wether the ps->data pointer is void.  Therefore, only one PAF callback will ever call calloc(), the ps->user pointer will never overwritten, and a memory leak cannot occur.  Second, the scenario you presented in which two PAF clients are simultaneously scanning a packet requires a specific configuration.  There is one realistic case where this can occur and at that time both PAF clients will read/write to the same memory.

Thank you for reporting this issue and I have created a bug in the system.


From: Mitesh Jadia <mitesh.jadia at ...2499...<mailto:mitesh.jadia at ...2499...>>
Date: Monday, November 3, 2014 at 7:09 AM
To: "Snort-devel at lists.sourceforge.net<mailto:Snort-devel at ...362....net>" <Snort-devel at lists.sourceforge.net<mailto:Snort-devel at ...2763...rge.net>>
Subject: [Snort-devel] Stream6 PAF callback function sharing (void **user) argument issue.


I read the code in Stream6/stream_paf.c
function s5_paf_callback

It calls each function registered with port for PAF.
            paf = s5_cb[i](ssn, &ps->user, data, len, flags, &ps->fpt);

callback function will calloc some data structure and put it's reference at &ps->user.
Now if in case more than one callback functions are being called for first packet in tcp session then following sequence will occur.

1)  1st callback calloc one data structure and stores it in  *user argument and returns PAF_SEARCH.

2) 2nd function again calloc other data structure and overwrites it at *user(which is common for StreamTracker). It also returns PAF_SEARCH.

I may be wrong in my analysis but I found that basically this is breaking functionality along with causing memory leak.

Mitesh Jadia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20141106/97ea6d8d/attachment.html>

More information about the Snort-devel mailing list