Wireshark-bugs: [Wireshark-bugs] [Bug 7803] Invalid memory accesses when loading radius captures
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7803
--- Comment #2 from Guy Harris <guy@xxxxxxxxxxxx> 2012-10-06 13:39:27 PDT ---
add_attribute() in epan/radius_dict.l appears to be handling the case where
there's already an attribute with the code in question, i.e. where
a=g_hash_table_lookup(by_id, GUINT_TO_POINTER(code));
succeeds. It does not appear to handle it by removing the old entry and
inserting the new entry, nor does it appear to do so by making a deep copy of
the old entry, modifying it, and inserting it. Instead, it appears to modify
the entry and add it again to the hash table(s). Part of the modification is
freeing the old name and replacing it; the name is used as a key in the "by
name" hash table, so this frees the key out from under an entry.
I'm not sure "last entry with that code wins" is any better than "first entry
with that code wins". My inclination is to go with "first entry with that code
wins", and report errors when additional entries with the code in question are
found, so that it reports problems in the RADIUS dictionaries.
If having multiple entries with a given code represents a bug in the RADIUS
dictionaries, we should choose one of them and either remove, comment out, or
fix the others.
If it represents a case where multiple vendors have used the same code in
different fashions, or the same code has been used for different purposes over
time - see, for example, bug 6243 - we should probably go with my suggestions
in that bug, so that the user can control which entries they want to use.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
