netdev
[Top] [All Lists]

Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory
From: David Stevens <dlstevens@xxxxxxxxxx>
Date: Fri, 15 Apr 2005 13:42:56 -0700
Cc: davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, netdev-bounce@xxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx
In-reply-to: <20050415004102.GA23462@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
netdev-bounce@xxxxxxxxxxx wrote on 04/14/2005 05:41:02 PM:

> On Thu, Apr 14, 2005 at 05:31:38PM -0700, David Stevens wrote:
> >
> > > In fact with your patch we can end up calling 
ip6_flush_pending_frames
> > > twice.  Granted that it is currently harmless but it isn't nice.
> >
> >         I don't see this. My original patch only calls
> > ip6_flush_pending_frames() once, since the original code already only

> You called ip6_flush_pending_frames() when rawv6_push_pending_frames
> returned an error.  However rawv6_push_pending_frames can return an
> error that was in turn returned by ip6_push_pending_frames.

> As you know ip6_push_pending_frames always frees the cork buffer so
> this is tantamount to calling ip6_flush_pending_frames twice.

        I missed that, as you know. :-) You're right, of course. Thanks!

> >         I saw that in the code, but I also saw a 2K single skb when 
the
> > MTU is 1500. A piece I looked at appeared to be allocating space for

        I tracked this down-- that particular test was running over
loopback, with its larger MTU. So, no prob. here that I know of here,
either.

        I've reviewed your patch and looks good to me. I've also
tested it with my test cases for IPV6_CHECKSUM and they work fine.
So, I'm good with your patch.

                                                        +-DLS


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