On Sun, 22 Feb 2004, Guy Harris wrote:
> On Mon, Feb 23, 2004 at 10:38:05AM +1100, Shaun wrote:
> > This bites libpcap because when it attempts to read off the end of the
> > real end of the interfaces it finds an interface with an empty name and
> > fails to retrieve the flags for the interface, terminating the interface
> > finding procedure. The fix I commited to our internal licpcap is to
> > 'break' out of the loop if we find an interface with a null name, does
> > anyone object to this approach for the mainline?
>
> "Null" presumably meaning either an empty name?
Yep, an empty name (the name buffer is an array in the struct itself as
you know).
> That's unlikely to appear in a valid list, so that's probably OK. There
> should probably be a big "XXX - Linux's support for IA-32 binaries is
> broken in the following fashion..." comment for it.
Ok, I'm attaching the patch to this email.
> (Presumably this bug has been reported to the appropriate kernel folks,
> right?)
Nope, and I'd rather not have to if you're not going to force me.
Cheers,
Shaun
diff -U 4 -r libpcap-2004.02.22/fad-gifc.c libpcap/fad-gifc.c
--- libpcap-2004.02.22/fad-gifc.c Sun Nov 16 10:23:58 2003
+++ libpcap/fad-gifc.c Mon Feb 23 11:07:34 2004
@@ -323,8 +323,22 @@
else
ifnext = (struct ifreq *)((char *)ifrp + n);
/*
+ * XXX - The 32 bit compatibility layer for Linux on IA64
+ * is slightly broken. It correctly converts the structures
+ * to and from kernel land from 64 bit to 32 bit but
+ * doesn't update ifc.ifc_len, leaving it larger than the
+ * amount really used. This means we read off the end
+ * of the buffer and encounter an interface with an
+ * "empty" name. Since this is highly unlikely to ever
+ * occur in a valid case we can just finish looing for
+ * interfaces then
+ */
+ if (!(*ifrp->ifr_name))
+ break;
+
+ /*
* Get the flags for this interface, and skip it if it's
* not up.
*/
strncpy(ifrflags.ifr_name, ifrp->ifr_name,
