netdev
[Top] [All Lists]

Re: [PATCH AND RFC_PATCH] 1. Leak corking option in ipv4 2. ipv6 opt pan

To: Krishna Kumar <kkumar@xxxxxxxxxx>
Subject: Re: [PATCH AND RFC_PATCH] 1. Leak corking option in ipv4 2. ipv6 opt panic
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 10 Mar 2004 14:47:58 -0800
Cc: netdev@xxxxxxxxxxx, krkumar@xxxxxxxxxx
In-reply-to: <Pine.LNX.4.44.0403091754440.6308-100000@linux-009047018241>
References: <Pine.LNX.4.44.0403091754440.6308-100000@linux-009047018241>
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 9 Mar 2004 18:05:48 -0800 (PST)
Krishna Kumar <kkumar@xxxxxxxxxx> wrote:

> Patch1 :
> --------
> I think every socket can leak memory when it allocates a cork.opt and
> calls ip_append_data()/ip_push_pending_frames(). This get released in
> ip_flush_pending_frames() which may not get called.

Looks correct, applied.

> Patch2 :
> ---------
> I am not sure about this possible bug which is the RFC part of the
> subject. In IPv6 ip6_append_data(), if it is possible to add extra ipv6
> options during multiple calls to append_data(), then the check for
> cork.opt could end up panicing the system because it is allocated
> for a smaller size of options. If this is a problem, then ipv4 might have
> a similar issue too. Note: Patch2 has a question embedded in it, I can
> send a better patch if you think the idea is right.

This is possible, but an APP trying to do this is buggy as I cannot
see any sane semantics for this.

I would rather we -EINVAL on such socket option changes if cork.opt is
non-NULL.  Could you whip up a patch for that?  Thanks.

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