[Snort-devel] Re: Bug in sfxhash.c::sfxhash_add()?

mnorton@...2839... mnorton at ...402...
Mon Nov 14 13:56:02 EST 2005

  whent he sfxhash table is created the datasize is calculated in 
protscan at line 270 in ps_init and passed to sfxhash_new() a few lines 
later, but it is defiend as :

datasize = sizeof(PS_TRACKER) + (sizeof(PS_PROTO)*(proto_cnt - 1));

which is why it's greater than 72 bytes, however thats not what is 
allocated so clearly this could cause a seg fault, we'll look at it in 
more detail and come up with a fix.

Sandro Poppi wrote:
> Hi,
> I ran into an issue when debugging a segfault in my sfportscan patch I 
> introduced with snort-idmef but which I think may be already existing in 
> the function sfxhash_add() in sfxhash.c (or I did something misinterpret):
> snort-2.4.3 (unpatched) on linux x86 kernel-smp-2.6.14-1.1637_FC4
> default snort.conf as shipped
> In portscan.c::ps_tracker_get() sfxhash_add(g_hash, (void *)key, 
> &new_ht) is called in line 472 with new_ht of type PS_TRACKER which has 
> a size of 72 bytes.
> In sfxhash_add() the formerly PS_TRACKER* parameter is converted to 
> void* named "data". In the same function line 690 "data" is copied to a 
> newly created (or reused) hnode object using memcpy(hnode->data, data, 
> t->datasize) with t->datasize being 276 which is more than the original 
> 72 bytes of a PS_TRACKER which is odd but seems to be "tolerated" 
> (because of stack size of 4k e.g?).
> My patch creates more data (sizeof PS_TRACKER = 1264, t->datasize = 
> 5044) and in some cases segfaults at the memcpy().
> Is the behaviour "as designed" or maybe a real bug?
> Thank you for your time,
> Sandro

More information about the Snort-devel mailing list