On Tue, 11 Nov 2003 23:26:11 +0100
Jan Oravec <jan.oravec@xxxxxxx> wrote:
> > The bus error you reported from running traceroute6 on the sparc64
> > system is not that useful, can you use gdb or some other tool to
> > figure out where inside of tcpdump6 the bus error is occuring? Is is
> > happening in the tcpdump6 program itself? It is due to a failed system
> > call?
> I am running 64-bit-only userspace and there is no gdb/strace for sparc64
> yet :(.
Yes there is a gdb, here is a prebuilt 64-bit gdb for you. It is even
statically linked so there are no shared library dependencies. It can
debug 32-bit processes as well:
> But I think I have found the problem:
> icmpv6_send() can get skb where skb->nh.raw < skb->data, thus computed plen
> (see icmp.c:382) is negative. When passed as unsigned int to __skb_pull, it
> underflows and is interpreted as 0x100000000-something_small. In __skb_pull
> we then increase skb->data by that number; because skb->data is 64-bit while
> plen is 32-bit, we get pointer which is 0x100000000 higher than needed. On
> 32-bit platform that does not cause any troubles because it overflows again.
> I do not know whether icmpv6_send() was meant to receive skb with ->data
> pulled no more than nh.raw; in that case I suggest the following patch
> (against test9-bk16):
Great analysis, thanks a lot.
I will look at your patch proposals.