[Top] [All Lists]

Re: skb_checksum_help

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: skb_checksum_help
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Sun, 23 Jan 2005 20:27:15 -0800
Cc: tgraf@xxxxxxx, kaber@xxxxxxxxx, david@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <E1Cst4o-0007bD-00@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20050124005348.GL23931@xxxxxxxxxxxxxx> <E1Cst4o-0007bD-00@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 24 Jan 2005 12:31:34 +1100
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> Something is screwed up here.  If the packet really went
> through forwarding, then skb->ip_summed should be CHECKSUM_NONE.
> This is done as the first thing in ip_forward().
> So if you're seeing CHECKSUM_HW at the end of the pipe,
> then somebody must've changed it.  CHECKSUM_HW should
> only be seen in dev_queue_xmit for locally generated
> traffic.

Yes.  This backtrace is very strange.  Let me take this
chance to get on my podium and re-express my distaste
for x86's inaccurate backtraces.  They make debugging so
difficult.  It's time for some dwarf2 unwind table support
the kernel x86 backtracer and a way to enable it during the

My current guess is that this is some successful exploit
of some as-yet-unknown issue in netfilter's fragmentation
handling.  But that's just a guess.  If some code underruns
skb->data somehow while unfragging/refragging, that's a sure
fire way to corrupt things such as the skb->ip_summed field.

All the theoretical attack has to do is find some way to
copy a "1" into the byte at skb->ip_summed, as that's the
value of CHECKSUM_HW.

It would be nice to just log a full tcpdump trace for that
UDP port on the incoming interface on that machine.  This
will allow us to see the exact traffic pattern.

<Prev in Thread] Current Thread [Next in Thread>