[Snort-devel] Re: Bug in sfxhash.c::sfxhash_add()?
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:
> 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,
More information about the Snort-devel