Pull request #79 submitted. https://github.com/jabberd2/jabberd2/pull/79
On 8/28/14, 10:51, "Shawn Debnath" <sh...@debnath.net> wrote: >Hey there, > >Turns out that when inserting items in xhash, the code stores a pointer to >the key passed in by the user in the xhash node and uses that later to >compare in _get. The problem is that it breaks scenarios where the user >may >use a temp buffer to build the key, then insert or put it in the xhash >and then free the buffer memory. Assumption here is that xhash code >would allocate necessary buffer to store internal data and not rely on >user supplied memory to maintain it=A9=F6s internal data structures. > >In the example above, the put succeeds, user frees the memory, so its >Pointing to garbage and a later a call to _get can't find the entry >because the keys mismatch, i.e., a user supplied valid string key and >NULL memory that the xhash node points to. > >Any ideas if there was a particular reason this was designed this way? I >imagine, in most of the cases the key is inside the object being stored >so it works out. However, as you can see, the xhash implementation >can¹t be fully exploited/used. > >It would be trivial, I would imagine, to make a copy of the key and >store that instead of just the pointer to user supplied memory. On >removal in zap_internal, the memory would be freed. > >Thoughts? Concerns? Let me know :) > >Shawn > > >
