All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Jan Oravec <jan.oravec@6com.sk>
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re: IPv6/sparc64: icmp port unreachable corruption
Date: Tue, 11 Nov 2003 15:13:40 -0800	[thread overview]
Message-ID: <20031111151340.3d129bc7.davem@redhat.com> (raw)
In-Reply-To: <20031111222611.GA1239@wsx.ksp.sk>

On Tue, 11 Nov 2003 23:26:11 +0100
Jan Oravec <jan.oravec@6com.sk> 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:

	ftp://pizda.ninka.net/pub/for_jakub/gdb64

Enjoy.

> 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.

  reply	other threads:[~2003-11-11 23:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-09 12:28 IPv6/sparc64: icmp port unreachable corruption Jan Oravec
2003-11-09 13:25 ` Jan Oravec
2003-11-09 13:39   ` Jan Oravec
2003-11-09 14:37     ` Jan Oravec
2003-11-11  5:46 ` David S. Miller
2003-11-11  7:06   ` YOSHIFUJI Hideaki / 吉藤英明
2003-11-11 22:26   ` Jan Oravec
2003-11-11 23:13     ` David S. Miller [this message]
2003-11-12  0:41       ` Jan Oravec
2003-11-12  9:26       ` David S. Miller
2003-11-12 15:14         ` Jan Oravec
2003-11-12 22:40           ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031111151340.3d129bc7.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=jan.oravec@6com.sk \
    --cc=netdev@oss.sgi.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.