https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3540
Bill Meier <wmeier@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #23 from Bill Meier <wmeier@xxxxxxxxxxx> 2009-11-18 11:16:48 PDT ---
Re:
nsg_creltime = (((guint64)fp->type##_AbsTimeHighHdr<<32) |
(fp->type##_AbsTimeLowHdr));\
It appears to me that fp ultimately points to an offset in a buffer into which
a portion of the capture file has been read.
(As Guy indicated above) (and unless I'm missing something) the above code
won't work on a big-endian machine (assuming that the time fields in the
capture file are little-endian).
There's a second issue in that if the fp pointer is not "aligned" then the code
will also not work on certain architectures which require fetches of ints to be
"aligned".
ISTR that something like letoh?() or pletoh?() must be used when fetching
little-endian integers (of whatever size) from a capture file derived buffer so
that the endianness and alignment issues are properly handled.
========
A cursory look through the netscaler code suggests that similar problems exist
elsewhere.
For example: [in nspm_signature_version()]
gchar *dp = nstrace_buf;
if (len == file_read(dp, 1, len, wth->fh)) {
for ( ; len > (gint32)(ns_min(sizeof(NSPR_SIGSTR_V10),
sizeof(NSPR_SIGSTR_V20))); dp++, len--)
{
#define sigv10p ((nspr_signature_v10_t*)dp)
if ((sigv10p->nsprRecordType == NSPR_SIGNATURE_V10) &&
(sigv10p->nsprRecordSize <= len) &&
((gint32)sizeof(NSPR_SIGSTR_V10) <= len) &&
(!nspm_signature_isv10(sigv10p->sig_Signature)))
return WTAP_FILE_NETSCALER_1_0;
nsprRecordType and nsprRecordSize appear to be guint16. I would suspect that if
these fields are little-endian that this code will not work correctly on a
big-endian machine.
========
I also note that the "signature" contains a field
guint8 sig_EndianType; /* Endian Type for the data */
I don't see this referenced anyplace. What is the meaning of this field? What
does "data" refer to ??
=========
So: if I'm not missing something, I expect netscaler.c needs a complete review
for issues of this type.
I'm reopening this bug until these issues are resolved ....
Bill
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
